#284

Updated build which fixes this (2ab892a)

but I didn’t include this yet, because I think testing this may have been involved in getting my TXo in this odd state and I’m not sure if I’ve fixed the issue yet.

1 Like
#285

i have an ansible midi mode feature request:

when in allocation style 4 (fixed) it seems that ansible is always listening to all midi channels. i tried mapping note and cc values from separate midi channels on my device (op-z), but after the mapping is complete ansible responds to those values from every channel. ideally ansible would learn the midi channel along with the note/cc.

:slight_smile: thanks

#286

I have an ansible request for kria:
have a dim light added in Octave mode of steps that are active
I always wanna add Octaves to certain Notes I have selected
But I have to go back and forth between the two
to select the octaves to the corresponding notes
Thanks

5 Likes
#287

I like this idea but I think probably it should be off by default? Seems potentially confusing to have keys from another page lit up, especially when first trying to learn to use Kria. I’d like there to also be some visual indication that the note overlay is on aside from just the overlay itself. I frequently want to have a quick reference for something like this though. Another example would be that sometimes when programming notes, I want to see the notes I have programmed on a different track. As with most features, the hard part is figuring out a UI that avoids being intrusive and avoids conflicting with other stuff. Maybe should just be another toggle on the config page or something that enables the overlay?

One thing that would also need to get cleaned up first: I’m spotting a couple places where it looks like on the octave and duration pages, there are keys that are dimly lit when they shouldn’t be. I should do another round of ghost hunting in the refresh code before doing another Ansible release.

I can try to look into this some, but I confess I don’t use the midi features much and am not too familiar with the midi parts of the code.

Haven’t forgotten about this, just still puzzling over the UI. The shift key approach seems reasonable, not sure if this would maybe be preferable behavior to the compensate-shift action I adapted from WW Kria, but having the extra transpositions hidden behind a shift key seems like a potential source of confusion – have to try it out and see. Is having an increased transpose range for each scale note necessary to get in the right key? Or would this generally be used for the root note, and we maybe could have a separate place for showing a single extra transposition value? The scale page is quite busy already. A separate page for scales is an option, but I worry about this shaking up workflows and diverging from UIs of other Kria implementations. The clock and direction controls are perhaps a bit out of place though, that could free up some more space if another home for them could be found.

#288

No, I think it’s a bit unnecessary - the main thing is to be able to shift the root note up higher to get to higher keys as you say. A separate transpose would be great, I think. Thank you so much for thinking about this!

You’re right that it’s best to be careful before changing things too fundamentally! But maybe there could be an extra page with an alternative scale view?

I’d actually prefer a different way of doing scales that’s more in line with what Eurorack quantisers typically use, and I think is a lot more intuitive. Basically, you’d have a single row of 12 buttons, each of which represents a semitone in the octave. If the button is lit, then that note is “on” in the scale, if it’s not lit then it’s “off” in the scale. (You’d probably want to constrain it so that the root note was always “on”.) This allows the whole interface to be much more compact, and I think more simple. (You’d have a second row of 12 with one button lit to work as a key transpose.)

The slight difference between this approach for Ansible and a typical quantiser is that Ansible expects there to be 7 notes in a scale. A typical quantiser takes an input note (usually any arbitrary voltage) and snaps it to the nearest note that’s switched on, but Ansible instead directly indexes into a set of notes in its scale. Probably the simplest approach for ansible would be to just use the first 7 “on” notes in the scale, allowing the two representations to be interchangeable.

2 Likes
#290

Just Friends works perfectly. Arc is working also. Having Kria working with Ansible is a game changer for me. Even having Earthsea and Meadowphysics with JF is a bonus. Thankyou so much for you work on the updates.

One issue I am having - I couldn’t get the er301 to respond when switched to er301 mode - but this is maybe user error. I have the er301 system settings (Teletype) switched on. I tried all the ports but no joy.

UPDATE : OK er301 is working with SC.CV on ports 1, 2, 3 and 4 - the issue i had was Orcas Heart multipass on the same i2c bus wasn’t switched off. However the issue i have now is i still cannot get SC.TR to work. Im getting a sustained 1 time trigger on SC.TR Port 6 if that’s any help.

2 Likes
#291

Hey @csboling. Thought I would do some testing on the current beta c88f558.

When I press the preset key, I only see 3 lights in the i2c column now, rather than 4. I assume the 3rd is now for ER-301 rather than 2nd TXo?

With the 3rd button lit I get voltage on the ER-301’s SC.CV units ports 1-4 as expected, but I don’t get triggers on the SC.TR ports 1-4. So basically same finding as @mlogger (except I notice nothing special about SC.TR port 6.)

Having the current position tracking on the probability page - super helpful btw!

1 Like
#292

Thank you both for the reports! It seems also that TXo was not working in gate/CV mode for basically the same reason. I’ve fixed this in the new build in the top post (34e62a2) – this should also fix ER301 because SC.TR and TO.TR use exactly the same message format.

This is correct, I was trying to rethink and simplify the UI, and wanted to save room for other devices – for multiples of the same device it may make sense to go horizontally. If you were making use of multiple TXos led by Ansible I can think about how best to implement this.

3 Likes
#293

Wow, that was quick. Thank you!

Now testing 34e62a2.

ER-301 is working as expected now. The only thing I noticed is that slew doesn’t seem to have any effect on ER-301. Not sure if that’s expected.

TXo seems to be working (including slew). The only thing I notice is that after engaging i2c to TXo from Ansible, communication from Teletype to TXo seems very hit and miss. Often it seems to require a cold boot (ensuring that Ansible in the same case does not boot with TXo i2c enabled) before it will communicate again at all. One time though, even with TXo->Ansible i2c engaged, I got it to respond to some things like TO.OSC.WAVE and TO.ENV.DEC while Ansible was playing it. But only once.

So not sure what is expected there.

1 Like
#294

I haven’t implemented this because the SC.CV.SLEW command means something different on the ER301 (set the number of milliseconds for the output to slew through its full range) than slew on Teletype and TXo’s CV outputs (slew/glide time is proportional to the distance between notes). I wanted to keep this behavior consistent with how CV slewing works with Ansible’s CV outputs but can implement something here, not having used an ER301 I didn’t feel confident in coming up with a generally useful implementation.

Hm, well, multi-leader operation is still kinda uncharted territory and every setup is a bit different, but I do this routinely without issue. Might be good to make sure you are updated to the latest firmware for everything, I think the Teletype build in the top post of this thread includes a patch to retry i2c transmission a few times if the bus is busy.

1 Like
#295

Ah, yes, the constant rate vs. constant time slew thing. I wonder if Brian at O|D would be open to implementing something on the SC.CV unit that allowed for the latter. I will ask him. If not, I can try to suggest some reasonable slew values that would sound good even if not consistent with Ansible’s CV out slew times.

I’ll try the latest Teletype beta and see if that helps restore Teletype->TXo communication. I was doing a lot of commands like: TO.CV 1 V 5, which wasn’t setting TXo CV 1 to a flat 5V. And now I’m wondering, when you engage the Ansible->TXo i2c switch, it must be sending some preliminary set up commands to TXo, like setting the max voltage for oscillations, enabling the envelopes, etc. When you disengage this switch does it not “undo” those setups? If not, that would probably explain why the command above wasn’t working. That CV channel was probably still oscillating and had an envelope applied.

Update: Brian at O|D says an enhancement for constant time slew is on the list but doesn’t have an ETA right now. Not sure - maybe it’s better to just leave out the ER-301 slew until then? That way it wouldn’t be a change in the way it works later.

#296

Wow, totally right. Thought I had this working but at the very least it was not resetting all tracks. Hopefully better in the updated 16ce626 build. Lots of little state tracking details to overlook.

2 Likes
#297

I can only imagine! I’m pretty stoked about this TXo control via ansible. It really makes TXo more accessible as a grab-and-go voice without having to think too hard about it.

So do these most recent ansible and teletype builds actually have the spark for multi-leader i2c in them? I.e. listen before transmitting, wait a short time and retry if the bus is busy?

To help me give a little better feedback, how is this state management supposed to work? For example, let’s say I’m using TXo in i2c mode via ansible, and I use teletype and set OSC.WAVE to 200. If I disengage the TXo i2c switch on ansible and then set OSC.WAVE to 300 and then re-engage the switch, should WAVE switch back to 200 or stay at 300?

Or put another way, when the TXo i2c switch is engaged, is ansible also listening for TXo CV messages and remembering them?

1 Like
#298

There is not really any listening. When transmitting it just waits for the bus to be free. It used to be that this line would wait forever so if there was too much bus contention the leader could lock up. Now it limits to 10000 tries and if the bus is still busy, the transmission gets silently discarded.

All that Ansible does when you disable TXo as a follower or switch from envelopes oscillator mode to CV/gate mode is:

  • turn off envelopes with a TO.ENV.ACT message
  • stop oscillation by setting TO.OSC frequency to zero
  • set TO.CV to zero. I should maybe also clear TO.CV.OFF since this gets adjusted by the follower-wide octave shift settings.

These are the only settings used other than the note on/off type messages. Ansible doesn’t know anything about the WAVE setting, this just gets remembered by TXo.

No. As far as I know very few if any I2C hardware implementations have support for simultaneously acting as a leader and a follower – or at least it’s an unusual use case with little existing example code. When the I2C peripheral is set to leader mode I believe the peripheral no longer has an address set and incoming I2C messages get ignored. IIRC crow does something fancy where it only switches to leader mode for long enough to send a message and then goes back to listening.

2 Likes
#299

After reading your explanations and loading teletype bc4c877 and ansible 16ce626, everything seems to be working really well. I had a super fun jam with TXo as a 4 voice synth, adjusting various TXo parameters from teletype while ansible was busy sequencing it. No lockups, and TXo now seems to disengage fully from ansible control after turning off the switch. Brilliant! I really like using TXo this way. It makes it so easy to use it as a 4x voice.

Does having the base octave for TXo one lower than it is now put it into LFO range? I was using one voice as a bass line and it felt like it should be able to go one lower, and that the highest octave was out of the range I’d be likely to want to use.

I also tested KR.DUR and the two new scale programming features and they seem to be working as expected. These are really nice adds, and the one where you hold the current scale value and select another temporary one is a sweet performance tool.

—now i digress—
I had kind of half-baked idea for kria. This may be kind of far fetched but I thought I’d throw it out there anyway. You never know…

There’s that 4th alt parameter that doesn’t exist yet (nothing attached to the 2nd press of the duration button). What if that was a clock pulse counter? The default could be 1, in which case it would behave like it does now (non-breaking). If you increased one of the steps in one of the columns to 2, then all of the parameters for that step would wait 2 clock pulses before advancing. 3 would linger for 3 clock pulses, etc. I guess there would be room for 1-7 pulses, or possibly there could be a general multiplier/scaler on the top row much like the duration param has now. I guess it would be like a per-step clock divider…

If this could work, I think you could possibly get more mileage out of a single pattern. For example, if I have a pattern now that I want mostly to be quarter notes, but I have 2 eighth notes I want to include, then the time division has to be 8th notes and I’ll get 2 measures from the pattern. If a feature like this could work, then the clock pulse counter/linger param for the quarter notes could be set to 2 and the eigth notes set to 1, and I’d be able to get more than 2 measures. For patterns that included things like half or whole notes, could possibly get a lot more measures.

I’m sort of thinking of this idea with all of the syncs on, but I guess if it follows the overarching kria design pattern it would also be able to have its own loop start and length, time division, and probabilities, which could make things really bonkers.

Edit: one more small thing I noticed. I don’t think this was introduced in any recent change. The docs say about storing a pattern

Hold a pattern key to store the current pattern into it; it will pulse when the pattern is stored.

I am expecting the light to go off/on momentarily to give me a visual confirmation that the store op is complete. That doesn’t seem to happen. If I store in something other than the current pattern, it will switch to that pattern. But if I store in the same pattern, there’s no indicator when that’s complete.

2 Likes
#300

Woah, what’s all this about?! Txo sequenced from ansible over i2c while changing wave shapes via Teletype? I really need to check out the latest builds as this sounds amazing.

1 Like
#301

You can change TXo’s envelope parameters too, and possibly other things I haven’t tried yet. It’s ace!

2 Likes
#302

Tuning mode now (89d4eb7) lets you adjust the tuning table three different ways, keys left to right are:

  • apply a per-track constant offset, programmed by tuning the lowest note slot for each track
  • linear fit DAC lookup table values between the values programmed for each octave
  • save tuning table as-is

and I moved the reset tuning key 1 space to the left to compensate. Still quite a busy page but hopefully this makes the most common use case a lot easier: dial in the offsets for each track, long-press the 3rd key from the right on the third row from the bottom, done.

Also realized that calibrated tuning / DAC values should not be sent to I2C followers since this would result in the followers being out of tune when compensating for the DAC offsets.

4 Likes
#303

Thanks for all of your effort on this @csboling. I love the convenience of integrating ansible with the ER-301 without the patch cables.

Wondering if you have any plans to implement the 8 trigger mode of meadowphysics?

2 Likes
#304

Neat idea, will have to think about this. Guess it would be 8 ER-301 triggers, or 8 TXo triggers across 2 TXos, or 4 triggers + 4 ENV.TRIGs on one TXo. . . Not sure about Just Friends, maybe each trigger is just a JF.NOTE?

3 Likes