Subject: Re: [linux-audio-dev] XAP: a polemic
From: David Olofson (david_AT_olofson.net)
Date: Mon Dec 16 2002 - 03:46:01 EET
On Monday 16 December 2002 02.01, Tim Hockin wrote:
> > >Standing proposal:
> > > Host processes blocks of 'n' samples. Events are delivered
> > > with a timestamp that says 'actuate this event at this time
> > > within this buffer'. This is exactly what user-supplied
> > > automation is, totally randomly timed events. Some plugins
> > > need to sync to tempo or music-milestones. They indicate this
> > > need and receive tempo, meter, ticks events. It is responsible
> > > for tracking changes.
> >
> > drop the tick events and it starts to sound reasonable.
>
> Ok. So how does a plugin know about musical milestones, then?
> Suppose it wants to lock onto a beat edge. I agree that TICKS
> events are not needed, since if you know the sample rate (you do)
> and you know the tempo (you can), then you can extrapolate a
> tick-width.
Synchronizing: Tempo data.
Alt 1: You adjust your internal "tempo" variable whenever
you get a TEMPO Control change. For every sample in
your inner loops, you add that value to your internal
"position" variable. The "position" variable now
corresponds to "free running musical time", tracking
the tempo of the timeline, but not locking to the
position.
Alt 2: Call the host whenever you want the tempo at a
specific position. If you want to know exactly when
tempo changes occur, you'll simply have to ask for
the tempo for each frame in the block, or you need
a more advanced API.
> The tick edge is the trick.
Locking: Positional data.
Alt 1: Maintain sync and local position as described above.
When you get a POSITION_CHANGE Control change, adjust
your "position" to the new value. Now, "position" is
locked to the timeline position.
Alt 2: Call the host whenever you want the musical position
for a specific sample, or (as in VST) get timeinfo
for the first sample in the block, and then ask for
the tempo for each sample frame, to reconstruct the
musical position for the whole block.
All the details of Alt 1 can easilly be wrapped in the plugin SDK, if
people find it complicated enough to motivate it.
> Or do we not worry about
> it and assume that the user will start things at the proper edge,
> and plugins will just need numbers of tick-widths?
No no, that's way to flaky, and would also mean that transport events
(loops, skips, start, stop) cannot be handled at all. You must be
able to resync the position at any time, to any position in the
timeline.
> > buffer-relative timestamps are a definite no.
>
> Yeah, I didn't mean it to come across that way - we've already
> decided that timestamps are continuous. Sorry for the
> miscommunication.
>
> I don't get what you were saying about virtual time. Let me try:
> frame-count is a global rolling counter. It never stops, unless
> the host has a special 'off' mode. Ticks is a mucial counter
> starting at some point, 0, that represents the timeline
> (track/song/whatever). It can jump forward (12, 13, 165) or
> backward (165, 166, 1) or loop, or pause. If it is paused or
> stopped, the frame-counter is still going. Since plugins just
> track 'ticks' by that, they still work.
>
> Is that correct?
Hmm... If it is, then virtual time is basically the same thing as
audio time, only in a different unit, and not necessarily fixed to
audio time. (Still can't see much point, though.)
//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 : Mon Dec 16 2002 - 03:54:35 EET