19 Dec
2002
19 Dec
'02
10:10 a.m.
On Thursday 19 December 2002 06.40, Tim Hockin wrote:
The transport/sequencer does. Whether it's part of the host or not is
another matter. :-)
Well, one loop
is just fine for linear music editing, but what
about interactive music? (The old, primitive approach, based on
conditional jumps.)
I was thinking one could generalize this by using N cue points
(abstract objects) instead of hardcoded loop markers in the time
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*.
Then again, provided the transport position tracks the play position
marker at all times (playing or not), there's no real need for a
special cue point. Plugins get the information they need anyway.
When a loop-point is set (and it just stays forever
until unset?)
Yes.
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.
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.
//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 ---