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

David Olofson david at olofson.net
Thu Dec 19 11:59:01 UTC 2002


On Thursday 19 December 2002 17.12, Frank van de Pol wrote:
[...]
> > 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.

Well, your question indicates that "cue point" is not the right term 
for this thing.

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.

The most obvious example of this would be conditional looping. (Which 
is actually what any HDR or sequencer with a loop feature has!) If 
you have a loop active, a HDR would know about the loop end, and have 
the disk thread skip to the loop start when the end is passed. All is 
fine, and the looping will work great.
 
However, if the user turns looping off just before the loop end, 
you're in deep sh*t! Your HDR has been reading from the start of the 
loop, maybe for *seconds* - while the sequencer is just about to pass 
the now disable loop end mark... All you can do is stall (and lose 
sync) or just let the HDR go silent until it catches up.

If you instead put a Pre-Cache Point (PCP?) at the loop start, the 
HDR will keep that data in memory at all times, and thus, will be 
ready to instantly start playing from that position at any time.


So, maybe the loop start + end approach isn't all that smart, after 
all...? Although PCPs do waste more memory, they make the 
applications a whole lot more interactive.


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

Yes, and you can easilly have a sequencer do either. (That's what the 
READY control output is for.)

But why not just have instant playback whenever possible?


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

Yes, but that sort of jitter is just a result of using the wrong tool 
for the job, or using the right tool incorrectly.

It is IMPOSSIBLE to have instant playback directly from disk. You 
MUST precache. That's what Gigaspampler, Linuxsampler/EVO and co 
does, and it's the only way to do it, short of simply loading all 
data into RAM before starting playback.


> 'Waiting till everyone is ready' in a real-time
> context does not sound good to me.

I give you three alternatives:

	1. Ignore READY and just play. As far as realistically
	   possible, samplers and HDRs will start playing at
	   the right position when they catch up.

	2. Use READY and wait until the plugins are ready.

	3. Tell your samplers to load the sounds you need,
	   and give the HDR PCPs for any points in a sequence
	   that you need to be able to jump to instantly. Wait
	   until they all are ready. Now, you can play sounds
	   and jump to any of the PCPs without drop-out,
	   delays or other artifacts.


Just pick what works best for each situation. All methods can be used 
at the same time in the same net. (Just disconnect the READY and/or 
PCP controls for the plugins you don't want to prepare or care about.)


> At least you need to have a
> defined deadline (which voids the 'wait till everyone is read'
> thing).

That's virtually impossible. The best you can have is a way for 
plugins to indicate approximately how long they need to precache for 
a PCP. Full RT plugins will just say 0, or just not have PCP inputs.


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

Of course - but how do you do it for a HDR...? These are two related, 
but slightly different problems.


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

Of course. Just disconnect the READY output from the sampler, or 
disable the "wait for ready" feature altogether in the sequencer. The 
READY feature is *optional*.


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

Yes. You can do that with PCPs. Either have plugins suggest a worst 
case latency, or just tell the sequencer to assume something 
reasonable.

Or you can pass the PCPs at "load time" and wait until all plugins 
are ready before you start playing.


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

Yes. You could add, move or remove PCPs at any time, although there 
is obviously no way of eliminating the underlying problem: the need 
for substantial buffering when reading from disk.


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

It doesn't need to "register" explicitly; just say that it supports 
PCPs. It could have a READY output for situations where accurate 
playback is more important than start delay (when you're recording 
songs to disk, for example), and it could have some interface for 
"expected PCP setup latency".


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

Yes. Just use PCPs. (I've realized that start + end markers are only 
half a solution.)

If you're not all that worried about the user moving the loop markers 
at the wrong time, you could still use loop start + end, and just 
watch out for "time info changed!" notification events. (Since that's 
where the loop points would be found.)


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