20 Dec
2002
20 Dec
'02
noon
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