[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Wed Dec 18 08:51:01 UTC 2002


On Wednesday 18 December 2002 14.12, Paul Davis wrote:
[...]
> >TRANSPORT: a plugin can have a TRANSPORT control
> >  - units: absolute ticks (float)
> >  - deliver a TRANSPORT control when transport starts (start
> > tick), stops (negative), jumps (new tick value) and periodically
> > (recommend each beat or each measure)
>
> excellent. i'd suggest one addition though, based on the analysis i
> did for JACK based on VST. The TRANSPORT control needs to be able
> to indicate a looped state. This allows things like disk-based
> samplers and sequencers to fetch the correct data ahead of time,
> and thus stay locked to the transport time. JACK just sets the
> transport state value to "Looping", and has two additional time
> points (in audio frames) to indicate the loop start and end.

I've been thinking about this particular issue. (HDR + loops.)

Well, one loop is just fine for linear music editing, but what about 
interactive music? (The old, primitive approach, based on conditional 
jumps.)

I was thinking one could generalize this by using N cue points 
(abstract objects) instead of hardcoded loop markers in the time 
info. Tell timeline aware plugins about them by sending events 
looking something like this:

	XAP_A_CUE_POINT
		int	id;
		double	position;


The 'id' field is for referencing the point, so it can be changed in 
a reliable fashion. BTW, applications may use one cue point to track 
the play cursor when the sequencer is stopped, to reduce the start 
delay. (Prebuffering would be done while you're moving around, so 
some or all of it is already done when you hit "play".)


This makes me think of another feature we need for anything that 
needs to prequeue data from some background thread or something: 
"Busy." A HDR just won't be able to start playback instantly, and it 
would be rather useful if the host could tell, and deal with it. (The 
alternative would be for such plugins to block or something. Very 
nasty...)

Can't think of any nice way that doesn't require at least one 
block/cycle for the sequencer/timeline to find out whether plugins 
are ready or not. Maybe that's not an issue? As soon as you have that 
kind of plugins, you *will* have "random" start latency anyway...


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