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

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…

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

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.

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

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.

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.

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.

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.

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!

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.

It should work in the latest beta, if you’re willing to try it out that would be great!

1 Like

Oh great! I’ll give a try soon.
Hopefully it works with my op-z plugged into Ansible.

I posted about this over in the Polyend Tracker thread, but I imagine its worth me sharing here, too!

Ansible’s MIDI mode doesn’t seem to work with the Tracker. The Tracker locks up Ansible when I plug it in, with TR2 lit and Ansible not responding to any MIDI input. I have to power cycle to get Ansible responding again (to a grid, or other USB MIDI device).

My Ansible works great in MIDI mode with all my other USB midi gear!

The Tracker draws 500 mA of power over USB with a peak of up to 1200 mA when powering on. Could it be that this is a bit much for Ansible?

It could well be, but I’m using a power splitter USB cable so the Tracker is being powered direct, not by Ansible.

The same happens either direct through Ansible, or via my splitter.

Ah, that’s too bad. Then it might be a bug. Have you considered reproting it on the Tacker GitHub so that they can have a look into it and others can share their experiences with other USB Midi and USB power splitters?

im no help as i only use it with my grid plugged in directly but posting your power splitter might help as maybe its not the correct one as that seams to be a confusing cable.

It’s definitely the correct cable, and it works perfectly well with all other hardware (i.e. my grid, my OP-1, my Pyramid).

Without access to a Tracker to test with it is really difficult to diagnose what might be going wrong. I briefly looked through the specifications and manual looking for clues but without hardware to test against I’m at a loss. My only guesses at this point are:

  • The dual role (OTG) mode of the Tracker’s USB port could be causing problems.
  • If the Tracker presents multiple USB endpoints that could also be a problem.
  • On rush current consumption when connected could be causing a brown out (but in this case it sounds like some external power in being used)
1 Like