Subject: Re: [linux-audio-dev] XAP: cue points / looping
From: David Olofson (david_AT_olofson.net)
Date: Thu Dec 19 2002 - 18:53:00 EET
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 ---
This archive was generated by hypermail 2b28 : Thu Dec 19 2002 - 19:00:27 EET