[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Sun Dec 15 20:52:01 UTC 2002


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 ---



More information about the Linux-audio-dev mailing list