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

Frank van de Pol fvdpol at home.nl
Thu Dec 19 11:16:00 UTC 2002


On Thu, Dec 19, 2002 at 03:05:01PM +0100, David Olofson wrote:
> > > 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*.

isn't the whole purpose of cue points to receive events when a certain
playback position is reached? So instead of polling the playback position you
simply register for a (private?) cue point to get notified when this
position is reached.


> 
> > 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 depends.... when using in a live environment, I sometimes rather prefer
to miss the first portion of a sample and have it catch up later while
keeping the timeline correct, than a lag before the sample starts. Think of
a live DJ set where drum loops and songs are triggered etc. A large amount
of jitter (random delay time) between trigger and start is very frustrating
in those kind of applications. 'Waiting till everyone is ready' in a
real-time context does not sound good to me. At least you need to have a
defined deadline (which voids the 'wait till everyone is read' thing).

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

If you want guarantees you'll need to obey the deadlines from the individual
plugins and their patches. This is not different from a traditional MIDI
sequencer driving a bunch of synths. I know for instance that I need to give
my Akai S3K sampler some time to load patches, I take that into account when
putting the sysex/pgmchanges in my sequence. Everyone does that.
If I made a mistake for that, and my synth was not ready (ie. I didn't obey
the required setup time), I'd love to see that the voice does already start,
though without sound (till the voice is properly setup).


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

If the amount of time the plugin needs to prepare for the loop (eg. time
required from preparing the data for the loop start), it could have the
host/sequencer emit an 'upcoming loop' notification, just in time before the
loop end. This allows the end user to change loop points on the fly, and
have the plugins reakt appropriate without having to wait for the second
time the loop is hit.

Any thought on how this plugin could register for it's private notification
cue point? 


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

agreed, but a loop start-end pair need to have the appropriate update events
to ensure the plugin can adjust the preloading when loop points are changed
'live' during a performance. 

Frank.

-- 
+---- --- -- -  -   -    - 
| Frank van de Pol                  -o)    A-L-S-A
| FvdPol at home.nl                    /\\  Sounds good!
| http://www.alsa-project.org      _\_v
| Linux - Why use Windows if we have doors available?



More information about the Linux-audio-dev mailing list