19 Dec
2002
19 Dec
'02
12:15 p.m.
On Thu, Dec 19, 2002 at 03:05:01PM +0100, David Olofson wrote:
The transport/sequencer does. Whether it's part of the host or not is
another matter. :-)
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.
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).
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?
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? 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*. 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.
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.)
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(a)home.nl /\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?