>What if we made it more of a broadcast. Have a way to have host or timeline
>global variables (which is what these are) which can be read by plugins.
>....
>Plugins are free to drop these global events. There is no function call
>overhead. The only overhead is the indirection of using a pointer to a
>global.
>
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?
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.
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).
I see 2 solutions, which can be combined:
1) user settable pre-roll. Set it to 0 for live applications; a few seconds
for normal use; and "from the top" when you must be sample-accurate.
2) cue points. When the user marks a cue point, the plugin must stream its
internal state (LFO values, sample offsets, etc) into a buffer. Then playback can
start immediately from this point later. Making changes to a plugin before the
cuepoint would invalidate the cuepoint. When starting playback from an invalid cue
point, the transport would have to pre-roll from the last valid cue point.
Of course this is no real solution for outboard synths.
(sorry if I'm restating the obvious.. I'm new to the list. Is there a "general
overview" of XAP? I couldn't find one at the web site.)
-Ben Loftis
