#353

Using the beta build from July 18th on the Kria Presets pages I have 5 lit buttons in the 6th column. The pattern is one at bottom, one off above that, and then four dimmed buttons. These are not on the right 8x8 side of the grid but on the left. If I press them, I cannot turn them off. The bottom one just flashes bright when I press it while the 4 above it can be toggled bright or dim but not off.

#354

this sounds like the i2c leader mode settings.

Currently, the only interface for turning on leader mode uses a grid. In any grid application, go to the preset page by pressing the button next to the USB port. Follower device toggles are arranged vertically, just left of center.

2 Likes
Monome ansible kria in depth overview and tutorial
#355

Hello,

I have a serious issue with Ansible since I have Disting Ex on my i2c bus.
Sequencing with Kria work but when I change the app, my i2c crash and nothing respond to i2c (Txo, ER301, JF and Disting). I also try to send command from TT to Txo or Ansible in TT mode but nothing respond.
I have to power off, unplug Disting’s i2c cable, power on.
if I want to sequence the disting again I must go back to the Kria application (because the other apps cause the i2C to crash), then, again turn off, reconnect the i2c cable from the disting, then turn on again.

My configuration is (on my TT i2c bus) :

ER301, SS, Ansible x2, Txi, Txo, TT, Crow, Disting.

TT, Ansible and Disting have all the last beta firmware.
All the applications work perfect when the disting is not connected on the bus.

#356

Can you try and reproduce the issue with as few devices on the bus as possible?

#357

Ok yes, so I have test with, on the bus of TT, Ansible x1, Txo and Disting. It’s the same problem. When I skip to the other apps it crash all my i2C connections.
More précisions for debugging it.
Before power off I have to switch off Disting i2C. (It’s not necessary to unplug the cable)
Power off.
Then power on.

I have to switch off i2C Disting before to change app. Then switch ON and it’s work.

I2c also crash when I reset a blank preset (from the config menu when i2C Disting is active)
I also try an other i2C cable but nothing change.

#358

Hm, I added some code to change Ansible’s listening address to a reserved one (which should stop it from receiving i2c commands) when doing certain flash saves. This was added because certain circumstances resulted in wiping out all Ansible presets when enough incoming i2c happened during a save – I don’t understand exactly how this happens, but this seemed to fix the problem, discussion is here. Maybe Ansible does something to the i2c lines when this happens and Disting EX doesn’t deal with it well? Paging @scanner_darkly since I haven’t used a Disting EX and I’m not familiar with its i2c functionality. Am I understanding right that Ansible is in follower mode when this happens?

1 Like
#359

do you use multiple leaders at the same time? like sending from ansible to disting while sending from tt to txo or disting? this is not supported and will cause i2c issues.

try enabling/disabling the i2c pullups on the disting (it’s a switch on the PCB marked SW2). this might help. if it doesn’t, try only having ansible and disting connected and see if you still get the issue.

1 Like
#360

@csboling and @scanner_darkly thank you for your help.

As your suggestion, I have test with only Ansible and Disting and it’s work perfect. No issue any more.

The issue seems happened with the I2C bus.
On the bus I have test with and without pull-up and nothing change the issue is still here.
I don’t use multiple leader when the issue happen and try different cables…

#361

so if the 2 work okay with nothing else, it means the issue is with the bus. unfortunately, it’s a bit of a voodoo technique to get more complex i2c configurations working.

can you try with everything but the crow connected? also try enabling/disabling pull-ups on both crow and disting (so, 4 different configurations to try). it’s possible you’ll get the right value that will make the i2c bus more stable. also try daisy chaining cables and see if that helps.

#362

4 posts were merged into an existing topic: Expert Sleepers Disting EX

#363

thanks again, I found out it probably could be a sd card related problem. I’ll try another one and if it’s not going to fix I’ll ask to the ES guys :slight_smile:
cheers!

PS
what made me ask here in this thread is actually the fact that via cv ins everything works pretty flawlessly, the problem comes out when ansible sequences disting ex via i2c…

#364

it’s likely just the number of notes triggered. do you get noise if you trigger via cv ins with the same rate as kria? what happens if you use the same patch but use the ansible cv outs instead of i2c? in your test, does the noise happen once it runs out of voices?

1 Like
#365

thanks again for your time! I just tried again to trigger notes from ansible via CV and there’s some noise also this way actually, even if it’s way less than the i2c environment. I hear some noise if I swap sample folder on the go (which is normal due to files loading I guess), occasionally while the sequence is playing (every 30-ish seconds give or take) and if I change notes quickly on the sequence. this makes me think about a sd card/sample reading speed problem maybe. I’m going to try to flash a new card and see what happens. I read about other people having similar issues (besides i2c and ansible) and some of them solved just using a better/new micro sd. anyway, using i2c, this issue is constant and persists even using less notes, voices and shorter sample env time.

#366

let’s discuss in the disting thread - i’m 99% sure this is not ansible firmware related, and os is more likely to see it there. it’s possible there is still an issue with note allocation even with the latest fixes.

1 Like
#367

Hey everyone, is there a way to change which i2c channels the ansible outputs in leader mode? I have a 16n also on leader mode, and being able to separate them in terms of channels so I could use them both in to the ER-301 would be awesome.

#368

What do you mean by channels? Devices can transmit messages to specific other devices on the bus by using their address, but there’s really only one shared data channel (a single data line and a clock) that every device on the bus has to share. If the bus is busy already when a leader wants to send a message, it will have to wait for the existing communication to finish. In some cases this may work fine but in others it can lead to stuff like modules freezing until a power cycle. Depending on your usage you might be able to get away with both leaders sending at once, but the firmware isn’t really designed for this and it may not work or may give you weird behavior.

#369

By channel, which I took from this comment in the instructions online about turning the ansible in to a leader, is for example, Ansible defaults to sending signals to the ER-301 as SC.TR 1

“ER-301 can be sent gate and CV commands, with the 4 tracks corresponding to the first 4 SC channels.”

I would like to either set the Ansible to start at SC.CV and SC.TR 17, so that my 16n could be 1-16

I’m also aware that multiple leaders can cause problems for the follower. I’m hoping that if I spread out across multiple “channels” or however it might be labeled, I could send signals from the 16n, crow and ansible to the 301 in a way that wouldn’t cause a lockup or problem.

#370

Ah, this makes sense. There’s not currently an option to do this on Ansible and it would need a bit of a code structure change probably to add it. In the short term modifying the 16n firmware to use different ER301 channels might be easier, not sure.

#371

Cool, yeah, I was looking at the firmware. I’m a bit of a noob when it comes to the language structure of the 16n, but I’ve also asked there and hopefully someone will have some thoughts on how to do that.

Thanks!

#372

Not sure if i missed it or I can get it to work but does midi mode support i2c?
I’d love to play JF and my ER-301 with my midi gear.