20 Dec
2002
20 Dec
'02
12:25 p.m.
It seems like the transport framework would want to
have an entire "transport state" calculated for each frame. Why not include a
copy of this record in the process() function parameters? This makes it available in the
process loop without a function call and makes it thread-safe, right?
hrrm, yes - the sample synchronicty between host and repeated playback of a
sniop of time. Ugg
Tell me more about the plan for SEEKing (i.e.
retarting playback in mid-sequence). As already discussed, this is a big pain if
you've got a droning pad sound that only has a note-on every 8 measures.
But not impossible. If a plugin supports SEEK, it will have a SEEK control.
The sequencer should notice that you've jumped/looped into a long note.
Re-issue that note and then a SEEK for that voice with the same timestamp.
Plugs that support it will have no glitching. Plugs that don't won't get
re-triggered.
I think it's too much to ask for plugin writers to
manage seeking. Instead the transport should do it by prerolling some distance at faster
than realtime (playback buffers are thrown away as they are generated).
eww, the seeking needs to be instantaneous, and unless you suggest
supporting infinite tempo (forward and backward)...
Tim