> 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
