[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Thu Dec 19 09:11:00 UTC 2002


On Thursday 19 December 2002 06.40, Tim Hockin wrote:
> > 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;
>
> When does the host send this event?

The transport/sequencer does. Whether it's part of the host or not is 
another matter. :-)


> When the transport position is moved, but play has not started yet?

Any time a cue point is moved, basically. Obviously, though, there's 
not much point in continously tracking the playback position with a 
cue point when *playing*. You do that only when you're *not* playing, 
so plugins that need to have some extra time before you hit *play*.

Then again, provided the transport position tracks the play position 
marker at all times (playing or not), there's no real need for a 
special cue point. Plugins get the information they need anyway.


> When a loop-point is set (and it just stays forever until unset?)

Yes.


> Shortly before hitting a repeat marker (loop point)?

Nope, that could be too late. If you want to be totally certain that 
everyone is ready, you simply have to wait until all plugins have "1" 
on their READY outputs, after changing any cue points. If you don't 
there can be no guarantees.

This is pretty much the same thing as in Linuxsampler: Before you've 
precached all starting points, there are no guarantees. Just because 
the starting points are ready, you can't start playing until the loop 
points have been cached as well, as there's no guarantee that the 
butler will have them ready in time for the first loop.


> Not a bad little frill, if the semantics are clear.  Totally
> optional for the host and plugin, but if they both do it, then it
> could be a nice optimization.

Not only a nice optimization, but an absolute requirement to handle 
more than one "zero-latency" cue point together with HDR.

I think the semanticts can be made very clear and simple without much 
trouble.

Now I have a guestion for people with more hands-on experience with 
HDR and looping: Do you really need anything more than the loop start 
cue point? What is the loop end info for? (Paul?)

I suspect that the idea is to avoid having to actually keep data for 
all cue points in memory at all times. (That can be a whole lot of 
data!) If you have both start and end info, you don't really have to 
precache, but can basically just move the disk read point to the 
start of the loop once it passes the end of the loop. (Obviously, you 
can't wait for the timeline to tell you "loop!", unless you keep the 
data for the loop start in memory at all times.)


My conclusion:
	The two loop markers are not exactly the same thing as
	N "Zero Latency Cue Points". Looping is really *looping*,
	while "ZLCPs" are more similar to direct-from-disk
	sample playback. Both can be very useful, but they're
	not equivalent.


Obviously, you *can* use a ZLCP instead of a loop start-end pair, but 
it's a waste of memory if you have only one, non-conditional loop. 
The advantage with ZLCPs is that you can jump to them at any time for 
instant playback, and you don't *really* need that for a single loop.


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