there was a timing issue reported on orthogonal devices forum. basically, when using metro script to output a pulse to er-301 and using it to clock a delay there was noticeable warble when switching modes on teletype.
this is likely due to the fact that teletype stores the latest mode to flash, so that it starts on the same page when booted up. so when you switch modes it introduces a delay while it writes to flash.
i did some measurements to confirm the issue. a simple scene with metro outputting a pulse on one of the gate outputs at 100ms rate was used. each measurement was based on a sample of 1000 pulses.
without switching modes:
min: 99.06 max: 100.3 average: 99.85 stdev: 45μs
switching modes [very roughly] every second:
min: 99.60 max 102.7 average: 100.6 stdev: 172μs
i then commented out saving to flash.
to confirm nothing else was changed i repeated the test without switching modes first:
min: 99.06 max: 100.3 average: 99.84 stdev: 56μs
min: 99.06 max: 101.5 average: 99.84 stdev: 83μs
since it also needs to update the screen and there might be additional setup needed for each mode i also tried switching between scripts:
min 99.06 max 100.3 average: 99.85 stdev: 48μs
so, saving the last mode to flash definitely has an effect. the question is - is it significant to be fixed? personally i don’t think anybody expects teletype to be super precise with timing, but if it does affect its use in a musical context then improving it should definitely be considered, especially if there is an easy fix for it. saving the last mode seems like a nice to have, not a must have. the only practical application for it i can think of is where you use teletype with one scene and don’t even plug keyboard or grid into it, and you want to see a specific screen. but that’s such an edge use case. with keyboard/grid it’s very easy to switch to the screen you want, and it does not affect teletype operation otherwise when you boot it up.
an alternative to the current implementation could be saving the last mode when you save a scene.