[linux-audio-dev] XAP: cue points / looping

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


On Friday 20 December 2002 02.58, Tim Hockin wrote:
> > The "objects" I'm talking about are "Zero Latency Start Points"
> > or "Precache Points". The whole point with them is to let plugins
> > know about jump target points that the sequencer wants to be able
> > to jump to at any time, without disrupting playback.
>
> CuePoints are absolute ticks, right?

Yes.


> The problem I see with PCP (I prefer to think of it as jump-point)

Yes, that's what they are.


> is that your PCPs are either global to all plugins in this
> timeline, or local to each plugin.  If they are global, then
> absolute position does you no good. A synth that gets a VOICE_ON at
> bar12:beat3 has no idea what it means to have a PCP at tick 8675. 

A synth would not care about PCPs at all, unless it's actually a 
"vocaliser" that's generating backing harmonies from a HDR vocal 
track or something like that. (And then, the data would probably come 
from the HDR anyway. The "vocalizer" is just an audio effect, and 
doesn't even need basic beat sync.)


> If you jump back in time (loop) you need to either trigger that
> note again and seek to the position, or seek backwards (if it was
> playing when you jumped).

Yes, but that's a different problem entirely. Synths can't do this 
anyway, unless they have integrated sequencers.


> The only things that can make use of this are things like
> disk-streaming plugins, which start at bar1:beat1.  The idea of
> passing an absolute-ticks value to a plugin is wrong, with the
> exception of 'automatic' starting plugins, like a disk streamer. 
> We pass absolute position to POSITION aware plugins because it is a
> clean way of indicating the passing of transport-time for any that
> want to sync, and for things like disk-streamers.  Are we to add
> this feature JUST for those plugins, also? I'm not completely
> against it, I just want to make sure we're all clear that it's not
> so useful to anyone else.

Right. A synth should (probably) never have PCP support, since it 
can't do anything useful with it anyway.

The purpose with the PCP interface is simply to have a standard 
protocol for the timeline/prebuffering stuff.

The alternative would be to enforce that timeline and transport are 
part of the HDR, and that sequencers always slave to HDRs. That way, 
a HDR can implement this stuff internally - but obvisously, you can't 
make this work with more than one "unit" of this kind in the system. 
Also, it might be a bit weird to have to load part of your song (the 
timeline) into the HDR, and the rest into the sequencer...


> Or am I really missing something?

No, PCPs and the proposed SEEK control solve two different problems.


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