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.

2 Likes

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.

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

3 Likes

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.

6 Likes

it feels more unstable

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

1 Like

Bingo.

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:

2 Likes

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

6 Likes

@bpcmusic thank you very much, i’ll give it a try .
Regarding SMD, everything bigger than 0402 huge :slight_smile:

Best
Marcus

1 Like

Ok; for the TXi - here is what I found.

I set up a slightly different script. I was setting a random value on the TXo CV output and reading it at a TXi CV input. I printed the values to positions in the current pattern. I used the first potentiometer on the TXi to adjust the delay. The script looks like this:

I
P.N 0
M 400
TI.PRM.MAP 1 0 200

M
A RAND V 10
D TI.PRM 1
P 0 A
P 2 D
TO.CV.SET 1 A
DEL D: P 1 TI.IN 1

Here is what I learned (on the latest v.017 TXi firmware):

  • If there is no delay command prior to the read - it isn’t reading fast enough to return the appropriate value. (That is, take out the DEL D prior to the last line of the metro script.)

  • If there is a delay command prior to the read, even if the delay is zero (0), it reads the output CV appropriately.

So - the appropriate read delay is somewhere between zero and whatever the delay is before something of delay 0 is executed.

I’ve been running it for 2+ hours and it hasn’t missed a beat, btw.

2 Likes

here is a test build (based on the latest official 2.1 version):

teletype.zip (102.9 KB)
teletype.hex (350.8 KB)

pull request: https://github.com/monome/teletype/pull/134

video demo:

there are 2 sounds, one is driven directly from pressure points, the other one from teletype - this one is delayed by 200ms to make it easier to hear. the script is simple:

CV A IN
DEL 200: TR.P 4

first i test without any delay on the first line, you can hear it still doesn’t always get it right. but adding just 1ms delay seems to be sufficient.

6 Likes

@scanner_darkly thanks for the update, it works very well

1 Like

Awesome, thanks so much for this!!!
I will do my best to get it fired up tonight.

1 Like