(Teletype) IN cv read latency?


nope. let’s try it. spi is fast-- even with an inefficient script (ie, multiple reads in the same script)

perhaps it makes sense to no re-query spi if a read comes within the same 1ms or so

good point. might get some timing jitter with script execution.



This is great news, thanks !



@bpcmusic - tagged to see if he can answer this question.

1 Like


agreed this is a good candidate for a new scheduler. but that will be a pretty major update, i think we should fix this before we get there.

agreed, and should be trivial to implement. i’ll play with this in the next couple of days.

we already have this problem if you use audio rate triggers… really what we need is a good scheduler that supports different priorities for different tasks.



Thanks all for the attention! This particular use case is near and dear to me as one of the primary use cases I have for the TT is creating a ‘improvisational sequencer’ that can capture played notes.

If anyone has changes they’d like me to try, I’m game.
My wife and I have a 4mo old, so my own latency is higher than normal at the moment, but I’ll turn around feedback as quickly as I can.



Hmm. It will be different as the TXi communicates over the i2c bus.

I have a similar architecture as the TT in some regard as that there is one thread that reads the inputs and prepares the output and a second thread that responds to i2c commands. As this is literally the only thing the Teensy is doing, I read as fast as possible and store the value.1 When an i2c read comes in, it identifies the value that is requested and returns it immediately (no read or conversion needs to be performed). This was done in order to keep the execution time of the read as fast as possible … which, as i2c reads are inline on the TT, will help keep the TT’s timing as tight as possible.

I’ll run the script when I get home tonight and report back. You have me very curious. :wink:

Funny you all would be talking about input resolution. I published a firmware update yesterday that I’d been fiddling with for the last several days working to increase the responsiveness and accuracy of the read operations by adjusting the analog smoothing algorithm. You can learn more on my update post here:

1 In looking at the read code, it looks like I have it set to 500 microseconds - or half a millisecond. That seems very fast. Clearly it isn’t overflowing as I have run TXi tests for days, but I think that I want to validate that it really is doing 8 analog reads, smoothing, mapping/scaling, and quantization that quickly.



The behavior of the expanders is similar to Teletype without them.
But all in all a little bit worse, because after playing for a while Teletype crashes compete


I use Monome Earthsea POS on TI CV 1, and EDGE to trigger script 1 in Teletype.



Yikes. Does it actually crash? There was a tremendous amount of work that @tehn, @sam, and @scanner_darkly (among many others) did to increase performance and stability of the i2c communications on the Teletype.

I’ve pounded the heck out of it and have found it to be super-stable.



which version of the firmware are you running? do you use i2c backpack or are they connected directly to teletype?



issue for IN latency added: https://github.com/monome/teletype/issues/132



Teletype Firmware is 2.1.0, I use my own DIY backpack
It is reproducible



Would you consider trying 2.0 and 2.0.1 and seeing if they have the same issue?

edit actually if you could answer @bpcmusic’s question underneath before trying…



Powered backpack or the one that is more of a breakout for the ii connectors (and doesn’t reach over and plug into the europower jack)? Also, how many devices do you have on that bus?

Sorry for all the questions!!

1 Like


I use an unpowered backpack
devices are:

  • meadowphysics
  • earthsea
  • ansible
  • TXi
  • TXo

Here is a small clip (issue is at ~ 1min 50 sec) https://www.dropbox.com/s/00bv0vewkxq6unx/Teletype%20Crash.mov?dl=0



would you be able to try only leaving TXi and TXo plugged in and see if you still experience the issue?



2.2 will feature optional profiling so that we can answer questions like this better.



it feels more unstable



only with the expanders on the i2c bus i am not able to reproduce it

1 Like



I have found that with four or more devices on an bus without a powered adapter you will get hangs on reads very consistently and, less frequently, writes as well (especially at high speed). Honestly, three devices is pushing it.

You need one of these, my friend:

or DIY:

It is SMD with some pretty tiny resistors, but a pretty easy DIY project if you are into giving it a try. :slight_smile:



this needs to be added to the docs in big letters somewhere.