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

David Olofson david at olofson.net
Sat Dec 21 12:21:01 UTC 2002


On Friday 20 December 2002 16.47, Ben Loftis wrote:
> >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?

Make it every *sample* frame, or it just won't work. (Unless that's 
what you actually meant).

That would work, but there are a bunch of values you need to 
calculate, and the cost might be significant. My guess would be that 
generating full time info for every sample burns about as much CPU as 
a bunch of basic filters.


> This
> makes it available in the process loop without a function call and
> makes it thread-safe, right?

Thread safety is not an issue. If you have multiple threads, you have 
many other issues as well, so you just can't do it without gateways 
between the threads. (I've mentioned what you need to do for 
RT/non-RT event passing for GUIs, and this applies to multithreaded 
hosts to some extent as well.)


> 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.

Yeah, and it's even more annoying if you have drum loops and other 
rhythmic sounds. The pads can be handled in an acceptable way by just 
adjusting the note start - or rather; find the last event for each 
control before the starting point. (Remember that we don't have 
actual note on/off events, but rather think of it as a note being 
played whenever VELOCITY is non-zero.)

SEEK is needed when you want to tell the synth/sampler to skip the 
first part of the note, so it's basically the other half of the 
solution. (Minus a few percent; it doesn't handle pitch bend and 
other things that may affect the time/position relation. Sequencers 
could approximate it by looking at PITCH, but that won't work for 
modulation and other stuff that depends entirely on the sound/patch.)


> I think it's too much to ask for plugin writers to manage seeking. 

It's optional, and not too hard to implement. Doesn't even have to be 
accurate. (It *can't* be with this interface anyway.) A synth can 
just look at SEEK when it's time to start a note, and if it's beyond 
the attack + decay sections of the envelope, start with the hold 
section or something. Do what works "ok" for the job it's supposed to 
do, or just don't do it at all.


> Instead the transport should do it by prerolling some distance at
> faster than realtime (playback buffers are thrown away as they are
> generated).

That won't work, unless you can tell plugins to just process events 
and not audio. It's not much use trying to do it faster than real 
time unless you're only using a fraction of the available CPU time 
when playing in real time.

Besides, this prerolling would have to be done outside the RT net, or 
you would have glitches (or rather, long pauses) in the RT audio 
processing.


> 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.

If you need it sample accurate, you only need to go back to some 
point where no events that are playing at the actual start position 
have started.


> 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.

Note that this is basically only for hard disk recording and similar 
tasks. Synths should very rarely need this.


>  Making changes to a plugin before the
> cuepoint would invalidate the cuepoint.

No, but it *might* force the plugin to redo the prebuffering work. 
For this very reason, I don't think you should do any "parametric" 
processing before the data goes into the buffers.

For example, a HDR wouldn't apply EQ and stuff in the butler thread, 
but rather on the RT side. (Or there isn't much point in having a low 
latency RT part at all, obviously.) Thus, control changes would have 
no effect on PCPs/cue points. PREDELAY might have an effect, but only 
if the change is big enough that the PCP buffers need to hold a 
different position in the file.


>  When starting playback
> from an invalid cue point, the transport would have to pre-roll
> from the last valid cue point.

Yes, but again, there isn't much point unless the system is furiously 
overpowered. It might be though, and this is certainly an interesting 
feature for sophisticated hosts - but it's not a general solution for 
the problems we're truing to solve with PCPs and SEEK.


> Of course this is no real solution for outboard synths.

Nope, and doing it *completely* right with internal synths is very 
hairy, very expensive or both. I think SEEK events would be a 
realistic way of doing it quite a bit better with internal synths, 
but going beyond that doesn't make much sense to me.


> (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.)

Very little is set in stone so far, and it's to be expected that the 
only documentation will be the headers, until we're close to 
finalization.

Might be nice to have HTMLized versions of the existing headers on 
the site, though. Can someone suggest a nice and handy tool for that?


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list