Re: [linux-audio-dev] XAP: a polemic

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] XAP: a polemic
From: David Olofson (david_AT_olofson.net)
Date: Mon Dec 16 2002 - 04:19:29 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 04:28:12 EET