#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
#305

Sounds like a reasonable approach.

#306

This would be awesome with just friends and the 301.

#307

Would love to sequence JustFriends with an Ansible in midi mode. Is it possible to poll Ansible CV directly without using a specific app op? Something generic like ANS.CV 1 or something?

#308

One difficulty with this is that each Ansible app listens on a different I2C address. This has some nice advantages – you can use I2C with two Ansibles running different apps at the same time, Meadowphysics and Earthsea ops can be used as-is with Ansible versions of these apps or with trilogy modules – but means that you can’t really have all-call commands. I have implemented a couple of ops (ANS.*) which work no matter what app Ansible is running, the way this works is that Teletype sends a message to every possible Ansible address (eight different addresses!) and every app handles this message in its I2C handler. A bit messy and I’ve been concerned about the timing / bus stability impact it might have to do this for something that would be called more often like polling the CV value.

You should be able to do this with Ansible leader mode I believe, though I have personally done relatively little midi testing. You do need to use a grid to configure leader mode. (Actually… this probably can be done with ANS.APP and ANS.G with just Ansible and Teletype.)

1 Like
#309

Thanks @csboling your explanation cleared up a few things I was wondering about how ansible listened to teletype. I have a grid, but not sure in the docs where it explains how to make an ansible a leader, also wondering if I need to detach the i2c to teletype or if I could leave it on the same bus as the teletype but just not call anything from to jf to avoid cross talk.

I2c multiplex chip?
#310

Configuration for leader mode is described in this post, this was only recently merged to Ansible and I haven’t added it to the monome docs yet since it’s not officially released yet. You can definitely have both leaders on the same bus, frankly I frequently send messages from both Ansible and Teletype to the same follower quite often. Though this does run the risk of one or more modules crashing and needing a reset, I have not had much of an issue with this for a little while.

3 Likes