@martinmestres - great to hear. I’m officially changing my tune to “three or more devices” for requiring powered bus boards.
@sam - I’ve been running my nutso test on 2.0 and it is rock solid down to an external trigger rate of M 11. This is polling the external params a hell of a lot due to the clock-divided triggers coming from the TXo to the first four trigger inputs to trigger reads of the four TXi pots.
On 2.0, even if I exceed the trigger rate (<=10ms), the UI is still completely responsive. The only thing is that the CV writes of the potentiometer values stop happening. I could still use the Teletype and modify my script to reduce the read rate.
To be fair, I saw a little gunk left around once on a screen refresh, but it was hardly problematic. I wasn’t able to cause it to happen again. This feels acceptable in such an extreme situation.
In my opinion, this is damn impressive. With two or fewer i2c devices or more with one of the powered bus board options, the Teletype is able to poll these external inputs at a blazingly fast rate. When exceeded, the TT is still stable and can be interacted with.
Given the processor in the TT and the i2c bus rate that it operates at, it feels almost miraculous. (A serious credit to all of the i2c work that has gone into the platform lately.)
For those wanting to push the envelope here, just know that there is a limit to the amounts of reads that you can do per second. This is the case for all microprocessor systems, it is usually hidden from you due to value caching and parameter smoothing. You can do the same in your Teletype scripts. (For example: read external values at a fixed rate using M and put them into variables that your scripts can use, turn on a tiny slew on a corresponding CV out to smooth out the steps, …)
