[linux-audio-dev] XAP: a polemic

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


On Monday 16 December 2002 02.12, Paul Davis wrote:
[...]
> so, there isn't just one time! this is the whole issue with
> positional versus rate synchronization. positional references
> provide one kind of time ("transport" or "virtual" time). its not
> monotonic, not invariant and not continous. rate synchronization
> controls a continuous, but not necessarily monotonic or invariant
> flow of time.
>
> different things want to lock to each of these. converters need the
> rate synchronization provided by sources like word clock. this is
> the same time that something like JACK and now the proposed XAP
> would be using as its basic timebase.

Yep.


> but a sequencer or tape
> device would use a positional synchronization signal that is
> entirely independent of the sample rate.

Yes - and I believe this is where musical time belongs. Thus, there 
is no reason to involve musical time timestamps unless you actually 
care about musical time. It would be like plugins sending audio rate 
control data at 44.1 kHz and and audio at 48 kHz, where the two 
sample rates are not in a fixed relation to each other.


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

That's exactly why I don't want to have plugins deal with musical 
time, unless they really want to. It's tricky to get right, and in 
the majority of plugins (including most beat sync'ed effects), 
there's no need for it whatsoever.


> the event needs to be delivered at a point which is now in
> the *past*,

Unless I'm totally misunderstanding what you have in mind, this can 
only happen if someone modifies the song while playing. It that case, 
there isn't much to do about it; the new event is behind the current 
play position, be it in a loop or not. So, you missed it, this time.

I'd think it's too much to ask that every synth supports FFWDing 
waveforms, envelopes, LFOs and all to the position they would have 
been, had the event been delivered in time. It's theoretically 
possible indeed, but I strongly doubt there's a point in implementing 
it, only so dragging notes around in the piano roll works better with 
long and dynamic sounds. The stop/restart hack is quite sufficient, 
considering what it takes to do it *properly*.


> yet will soon be in the *future*!

It doesn't matter whether or not the event exists both in the past 
and in the future; the future will still soon be within the current 
block.

Unless someone hits stop, or moves the loop marker, or whatever.

Again, plugins can't know anything about the future (who does?), so 
they shouldn't pretend they do.


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