#14

A little more data, this CV fix really sped stuff up:

I moved stuff to script 1 and ran the tests off an external clock so I could get a handle on total real world latency.

TR.P has maybe 40us (yes, forty microseconds) of off-to-on latency. I’d need to fire up my Rigol scope to see the jitter, it’s too small for the O’Tool+.

CV state changes have c. (edit: double the times here, I thought I was still looking at 100us/div when it was 200us/div! Max observed latency is still a very good 1ms) 200us of latency + c. 500us of jitter after this update, which is very good when we take into account the very fast & clean transitions.

@csboling @scanner_darkly @tehn … nice work, thanks so much for all you do! Teletype keeps getting better and better :slight_smile:

4 Likes
#15

thanks for taking the measurements - it’s nice to see some concrete numbers!

2 Likes
#16

I’ve been tracking down a new issue: Teletype is dropping events randomly. At first I thought it was my imagination, but now I can replicate it pretty easily. The scene only requires this:

TR.P 1

… and a clock fed to the corresponding script. I am giving it a 150bpm train of 1ms pulses and not always getting a pulse on TR 1, as verified by observing scope traces. It gets much worse when I interact with the grid preview mode (without grid plugged in): holding down an arrow key to move around the grid buttons causes maybe 5% of TR.P calls to fall on the floor. Dropped TO.ENV.TRIG calls are where I first noticed the issue, so it’s not limited to just the onboard TR outputs.

This is not related to the above jitter issue: I tried various values for TR.TIME in the 50-100ms range, which is well over the threshold where pulses got jittered out of existence.

Edit: running the above firmware revision and have (2) TXo and (2) TXi connected via backpack.

#17

Is it related to the length of the incoming triggers? I have a vague recollection of another module (or several?) failing to catch short-duration triggers, and 1ms is pretty short.

1 Like
#18

Good call, I just tried it with various input pulse lengths from 5-10ms and did not observe any dropped TR.P calls with lengths of 8ms or more. I’ll keep testing, perhaps it’s related to the 10ms cycle time?

I was using 1ms pulses to get a narrow spike on the scope for an upcoming presentation on generative sequencing techniques–this is the first time I’ve had an issue (that I noticed, anyhow) with short pulses, however.

#19

I did a quick test and noticed dropped TR.Ps from a fast M script (M! < 20ms) when moving the cursor around the Grid pages.

I also noticed that sending a clock of certain speeds to trigger a TR.P from script 1 caused the length of Gates out of 1 to be (cyclically) variable. I wonder whether incoming triggers of certain speeds can cause dropped triggers - eg when they are spaced as a certain division/multiple of TR.TIME.

If that makes little sense, I’ll make a video later to illustrate.

1 Like
#20

This could be a regression in 3.1.0 since the handler now checks the pin state to decide whether or not to fire the script depending on your configured $.POL. If the input is low again by the time that check happens it might not fire the script.

2 Likes
#21

This would tally with my experience above.

#22

Check above for a discussion of this issue. :slight_smile:

#23

FYI, I have been working on a new scheduler core that uses custom timer adjustments with CPU cycle count feedback adjustment that does everything on a single timer. It would be millisecond accurate for all DEL, TR.P and METRO, and could guarantee execution priority and predictable timing, even with triggers (the trigger ISR flips a bit and the trigger is processed only when it wouldn’t interrupt the timing of M, DEL, etc).

CV slew update throttling is a current bugbear, insofar as producing predictable results in busy patches.

I had previously shelved the design as I read that timers were adjusted in a subsequent release and thought they might have been good enough for most applications.

If a millisecond-accurate Metro is still desirable, I could try to finish up work on it. It would have to be experimental for some time as it is a significant departure from the current scheduler.

Let me know.

7 Likes
#24

20 characters of :heart_eyes::heart_eyes::heart_eyes::heart_eyes::heart_eyes:

Edit: I am also signing up for detailed testing with my recently upgraded Rigol scope.

1 Like
#25

Asking here since someone here likely knows the answer:

Where in the H - E - double chopsticks is INIT_SCRIPT set!!! ??? No luck with grepping around at all …

#26

Strangely, it is in turtle.h, accompanied by a comment on the misplacedness of this enum: https://github.com/monome/teletype/blob/38668cacaf64d696023430250339c936df6b2653/src/turtle.h#L43

1 Like
#27

Hah, I was looking right at it but only saw the single line that grep matched–I was looking for a #define!

Adding A, B, and C scripts (and making them callable with $/SCRIPT) was pretty easy once I found that. Thanks so much!!

1 Like
#28

You may have already found this, but while you’re modding firmware it should be straightforward to change the behavior of P.RM and P.POP to do what you want.

1 Like
#29

Thanks! I just spent a few minutes getting USB disk mode to save the new scripts, though reading them back in is proving to be a little fussy.

After that I think I’ll stick to the mainline code for the time being, it’s not that fun to be off in the wilderness when so many smart people are adding cool stuff. :slight_smile:

#30

What’s the current status on this @sliderule (or other TT devs) ? I’m starting to want to use TT for more master trigger / clock divider duties, and would like it to thwack tightly.

#31

I would love to try any improved TT firmware, I’m still bitten occasionally, and trying various work-arounds…

#32

If you need really tight timing, I don’t think Teletype’s metro is going to work as a master clock. The inherent jitter isn’t too bad according to some tests: about +/- 1ms. But activity like scrolling around in pattern mode and interacting with the grid sim/preview screen introduces hiccups that will cause havoc with things like clocked delays. I use external clocks: TXo is very stable.

Teletype’s responsiveness to trigger inputs and overall speed is quite good! I’d put it up against a 4ms RCD, which I measured at ~130us latency with about 50us of jitter.

@a773, what kinds of workarounds are you having to use?

#33

My issues are related to i2c triggers being transmitted on later M cycles. I believe this post came just after my post (hence the title), I’m replying here because in my naive book, everything that improves timing might affect/improve/fix my problem…

Haven’t been able to make it work reliably, currently I’m testing clocking $1 from an external source and triggering $2-7 from $1, no conclusion yet. Other workarounds include abandoning completely or partially i2c and resorting to cables (major bummer)…

The problem takes a while (about an hour) to build, making it hard to troubleshoot.