Last night I ran into what seems to be a significant amount of latency reading the cv at the IN input.
I setup Pressure Points (and same behavior with Rene) so that the Gate on touch was patched to trigger in 1 on TT, and the CV output of Pressure Points/Rene was patched to IN on TT. The idea being, TT would echo (CV to VCO, TR1 to envelope+vca) and capture what I played. But, I’d always have to tap a stage twice before the correct CV amount was read. I simplified the script down to this for debugging:
#1
X IN
CV 1 X
TR.P 1
No obviously, not patched through the TT, I don’t hear any kind of delay between Gate/stage press and CV updating directly from PP/Rene. I started to play around with adding DEL.
#1
DEL Z: X IN
DEL Z: CV 1 X
DEL Z: TR.P 1
Through trial and error, slowly increasing the value of Z, I found that I needed a value of at least 80 for X to be accurate to the input voltage read from Pressure Points. 100 was the best, never having a case where the value wasn’t correct.
But 100ms seems like a crazy amount of latency to me. I wouldn’t expect the read/scan time of the IN jack to be that long, and I’m possitive it doesn’t take Pressure Points, a fully analog switch, that long to change it’s CV output from stage to stage.
100ms is a lot. so what happens is: when you execute IN it doesn’t actually read from ADC, it reads from an internal variable that gets updated every 61ms (same handler also reads the param knob, if i’m reading it correctly). so worst case scenario you would have at least 61ms latency in order to have an accurate read.
@tehn is there some technical reason we can’t just read from ADC whenever IN gets executed?
I had the same issue when I tried to create a quantized cv-sequence-recorder. Most of the values were delayed by one step. In fact, I’d say that for most use cases I can imagine, this sort of latency makes it relatively useless.
If it’s somehow problematic to read the ADC when IN gets executed, maybe there could be an extra script that gets executed every time the ADC is read? That would feel more deterministic than what is currently going on. Or would that be too much additional load if it executed every 60 ms (I think M doesn’t go lower than 75ms or so?)
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.
–
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
X TI.CV 1
TO.CV1 X
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.
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?
