19 Dec
2002
19 Dec
'02
12:58 p.m.
On Thursday 19 December 2002 17.12, Frank van de Pol wrote:
[...]
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.
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?
Of course - but how do you do it for a HDR...? These are two related,
but slightly different problems.
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.
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 ---
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. 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. 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. 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.