[linux-audio-dev] XAP Time/Transport - varispeed/shuttle

Ben Loftis ben at glw.com
Fri Dec 20 11:01:01 UTC 2002


>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



More information about the Linux-audio-dev mailing list