#1

i often find myself cranking M up to 10ms and rapidly polling various TT inputs. never had any problems in the past - but with the discovery that doing this via i2c can cause lock-ups i’m starting to worry that i may get myself into a mid-performance crash by relying on this practice. just want to see if i’m pushing TT beyond the intended design.

examples:

i often poll IN at 10ms to track earthsea values.

or i’ll poll PARAM at 10ms to have responsive control over various functions.

another idea is to rapidly poll one trigger input state and update TR.TOG - basically a simple gate status reader.

A user's guide to the wonderful world of teletype ⌨
Teletype display glitch
#2

As TT is an event driven system, it might be best to try and poll the inputs only when you’re generating output. What are the outputs you’re generating, and how are they triggered?

#3

yeah i guess brute forcing it to be “real-time” is moving against the design.

i was polling IN rapidly because i’ve found that when i’m sending earthsea position + edge to TT, IN reads the cv after the output trig is generated, shifting all played notes 1 step back. i suppose i could delay my trig out, but i want it to be as responsive as possible.

the reason i poll PARAM so quickly is because i like to map it to octaves and be able to update the octave value mid-event. a cool effect, but not something i do all the time.

i’d like to poll one of the script input hi/low states rapidly so that i can translate earthsea gate times thru the TT ecosystem in realtime. the reason being that i’ve been using TT as a master hub for 4 voices and i like to be able to switch scripts to reroute earthsea to different voices without re-patching.

#4

my main suggestion is to simply use it and report back with how it’s going. rapid polling shouldn’t be a problem in general-- it’s just the the i2c transactions introduce some cycle time that can eventually eat up the entire cpu.

so, be methodical. if you start to see crashes or weird behavior, try slowing down the polling, see if that fixes it.

if there’s something very specific you’re trying to do, it could be addressed potentially as a new feature, or a bug fix. for example, the ES really should be corrected to output CV just prior to TR when slew is 0.

#5

thanks for your insights. yeah so far no problems. i first tried rapidly polling PARAM over a year ago and haven’t ever had any problems.

i appreciate your suggestion to correct ES behavior. that would be wonderful.

that just leaves real-time gate length reading… i haven’t tried rapidly polling STATE yet. will experiment this evening and share my results.