Ansible Development and Beta Firmware Discussion

Found a bug… seems that when setting a track to random (on the scale selection page), the last step in the loop never gets selected. I made a triad on the notes page, looped it (3 steps) and set the track to random and only the first two notes are ever chosen. I increased the loop to 4 steps and then I heard my 3rd note (but never the note for the 4th step).


Whoops, nice catch. Build in top post (f9d22e3), PR.

1 Like

cool… so what’s the procedure for saving your presets before updating? Not mentioned here (currently): the drive needs to be FAT formatted.

I tried to run Ansible as a leader with only Just Friends on the i2c bus as a follower, but was unsuccessful using them together in this configuration. Ansible locked up as soon as it reaches a trigger in Kria. Once I was able to recover Ansible with a power cycle, however it was still unresponsive three other time I power cycled and had to reflash the firmware to get it functional again.

I confirmed I was able to send commands via i2c with Ansible -> Teletype -> Just Friends after I failed to get Ansible working as a leader.

Meaning no other modules were connected to the bus? Ansible is not wired to pull up the I2C lines, so I would kind of expect this to freeze – the lines are always low, so the bus always looks busy. A backpack, TXb, or Teletype, or just a dirt simple DIY bus board like this one needs to be part of the I2C network to supply power to the bus, but so far it’s seemed totally fine to me to have multiple leaders (Teletype and Ansible) sharing the bus.

1 Like

Ahhh of course, forgot about the backpack deal… & I thought I was doing it right to remove all other variables :upside_down_face:

Thank you for all of the Ansible love! It is awesome, awesome, awesome. And yet somehow, it still continues to be awesome in spite of that.

I took the latest beta for a quick spin. Testing with ER-301 as a follower - did 3 tracks. Couple of things I noticed (may well be user error at this point).

The global octave shifts in the follower config - the ER-301 seemed to still be transposed up a bit even though I had the leftmost button selected. Choosing a button further to the right shifted it up by add’l octaves, but I could never get it down to it’s base frequency.

There seemed to be a little bit of weirdness on the duration page. Really long durations seemed to somehow fire double triggers? Not sure if this is i2c related. Will try to test it with a patch cable.

To the right of the mutes on the follower configuration - I have no idea what to make of it. I was scared to touch it. :slight_smile:

Again, thanks so much for the time and effort on this. Great additions to an already excellent firmware. I’m sure I’ll find uses for all the new features.


Thanks so much for beta testing!

Oops, this calculation was wrong. Fixed in the top post (664a192), along with playhead highlighting on the probability view from the Kria feature request thread.

Super weird, did you get a chance to test this out without Ansible involved? And do you recall if anything else was going on with I2C?

Yeah, mainly I wanted there to be a way to reassign follower addresses if you have a bunch of stuff on the bus, and while I was at it thought you should be able to send other stuff (say, TO.OSC.WAVE i x messages instead of the default TO.CV i x). It’s probably a little too easy to bump it and break stuff as-is, if I ever get started on writing a preset customization browser app I would probably just put some decent interface for it there. Also using an entire column of a 128 as bit toggles for a whole byte just delights me, though I’m realizing while typing this that I2C addresses are only 7 bits.

1 Like

Yay! Thanks so much. That was fast! :slight_smile:

Awesome, thank you very much! The playhead highlighting will be a great feature.

I just had another go, and I think I see what’s happening. The duration page is doing what’s expected with CV - producing a longer gate as you pull down the vertical slider corresponding to that step, or increase the horizontal master slider at the top for all notes.

Over i2c to the ER-301 SC.TR units, I think it is calculating the gate length correctly. But instead of actually increasing the gate length, it appears to be sending a short trigger at gate on, and another short trigger at gate off. When the gate length is very short, they are likely so close together that it’s not really noticeable (don’t hear a separate note as long as there’s an EG). As you increase the gate length, a trigger at the beginning and end of what was intended to be one continuous gate results in hearing it fire twice (two short notes where one long one is expected.)

Hopefully that makes sense. In front end teletype op speak, I guess setting the duration would be the same as sending SC.TR.TIME x y. I don’t know what that looks like in i2c code. But it doesn’t seem to be doing that, maybe?

Note this testing is still on the beta version prior to 664a192; I haven’t grabbed that one yet.

Oh, gosh, jeepers, heck, this is exactly right – I was sending SC.TR.P messages instead of SC.TR to set the gate state. Should be fixed in 78d49d8. Are the slew controls working okay with the Kria glide settings?

1 Like

That was fast! Thanks! :slight_smile:

I’m going to give a longer answer than yes or no.

They are working. The slew doesn’t sound identical to what would be produced on the CV out. This is the same thing that happens with Teletype CV vs i2c to SC.CV unit. The actual slew time between notes is (typically) less with the i2c variant. It’s fresh in my mind right now because it’s a recent topic on the O|D forum.

Per Brian of O|D: “The slew time on the ER-301 determines how long it takes to make a full-scale change (0 to 1, or in volts, 0V to 10V)”

So I think both Teletype and Ansible are doing constant time portamento over CV. When the slew rate is set on the ER-301 Unit with SC.CV.SLEW, I think it is setting a constant rate portamento. So the smaller the distance between the current and previous note, the less the perceived slew amount.

I just tested and while adding slew with i2c is working, it does not sound the same as if you are driving pitch with a patch cable. Same is true of Teletype.

1 Like

Oh interesting! SC.CV.SLEW just passes through the value passed to it onto the I2C bus, which in analogy with CV.SLEW I would guess is supposed to set slew time in milliseconds between the current CV output and the target CV value when setting CV i x. I’m not sure how this would translate to the way ER-301 is processing these commands, since I think it would have to rescale the slew value with every CV change to get the same behavior as from CV.SLEW. I’ll have to snoop around some of the discussion on the O|D forum, sadly I have no experience with the ER-301 beyond eyeing them covetously.

fwiw, i concur:

(when you set a new value, an update step size is calculated based on the current value, such that the new value will be reached in the time specified by the “slew” parameter.)

so the word “slew” is potentially misleading since it would tend to imply a fixed slope. (of course we use it in an even more misleading way on aleph and norns, referring to 1-pole smoothing… oh well)


Suddenly I feel the need for a CV.PORTAMENTO Teletype alias.


My two cents - there are use cases for both flavors of portamento, but constant time portamento would probably be preferable to constant rate portamento in kria, if it’s possible, because:

  • it mirrors what happens when you control pitch with CV, so it is kind of what you’d expect
  • for small semitone intervals, even the max glide/slew setting doesn’t produce a very satisfying amount of portamento - in fact you might not even hear it
  • you don’t really have the flexibility to change it without altering the firmware

For Teletype, I think you can have the best of both worlds because you could script the constant time flavor. I haven’t tested this but something like:

// assume X is desired portamento time in msec
// assume current tracker contains notes in semitones N
SC.CV.SLEW * X / 120 ABS - J K 
SC.CV 1 N K; SC.TR.P 1

The caveat here though is I’m not sure the max value you can send to SC.CV.SLEW is. If it’s 32768 then the largest portamento time you could get transitioning by 1 semitone would be 273 msec, which might be less than your target time X.

I hope that one finds its way into your case. I have a feeling you’d quite enjoy it!

what would the correct terminology be rather than slew? about to make the same mistake in crow, so best correct it earlier

I still would love to have a slew setting that is bound to the clock speed. The last time I tried it with the new firmware I felt a bit disappointed that the range is somehow moving between, short, quite short and very short.

How about a percentage of step length?

I really like the current way Teletype is implemented and I don’t see much use for the constant rate portamento as implemented on the 301.

Other than slew, quite a few places refer to it as slide or glide. I personally think slew is just a good.