15 Dec
2002
15 Dec
'02
10:15 p.m.
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:
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.
>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*,
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 ---