[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Sun Dec 15 21:25:32 UTC 2002


On Monday 16 December 2002 02.21, Tim Hockin wrote:
> > tim h. had written:
> > >>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'.
> >
> > sounds fine, except that there are some difficult cases to handle
> > at a higher level. consider "actuate this event when get the
> > following point in the music", delivered when we are looping, and
> > have already passed that point in the music, yet its within the
> > loop. the event needs to be delivered at a point which is now in
> > the *past*, yet will soon be in the *future*!
>
> but a plugin would never receive an event that said 'actuate this
> event at this musical time'.  Plugin-external events (i.e. from the
> sequencer) would ALWAYS be related to the current buffer.

Or rather, related to audio time, since the timestamps are free 
running + wrapping, and not specifically related to the start of any 
audio block. Doesn't really matter, though, since the point is that 
you should not think in terms of audio time outside the current block.


> Plugin
> internal events (for lack of a better word) can be either 'do this
> in N samples' or 'do this in M ticks' (where tick-width is
> calculated from tempo and rate).

Right.


> Alternatively, if we have some
> sort of keyframe mechanism (TOCK events?) it could also
> periodically sync to the host clock, but I am not sure that is
> needed.

That's not an alternative, but rather a way of ensuring that beatsync 
plugins don't drift because of rounding errors or whatever. They're 
just "unmotivated" POSITION_CHANGE events. No special handling needed.

If plugins or the host maintains a sample accurate representation of 
musical time, all you need to do is look at that. If you get TEMPO + 
POSITION_* events, those will ensure that your internal 
representation is in sync with the timeline, for every single sample 
that you process.

If you want to know about the future, you could make a call somewhere 
- but yet again: No one knows anything about the future, so the 
answers are just guesses. Ask for musical time, but don't expect to 
ever reach the point returned.


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