Subject: Re: [linux-audio-dev] XAP: a polemic
From: David Olofson (david_AT_olofson.net)
Date: Wed Dec 18 2002 - 15:45:03 EET
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 ---
This archive was generated by hypermail 2b28 : Wed Dec 18 2002 - 15:47:18 EET