tim, you wrote:
>to allow for everything you mention here, you need to
>start counting a different time -- you've stopped the
>transport, so transport time isn't flowing any more.
>
>at least that's what i do, calling it 'virtual time'.
>
>the thing is that you need to keep time well-defined
>and controllable at one point, for the whole network.
>if you don't, things like synchronization and transport
>control are tough to get right.
yet earlier, you wrote:
>yes, because you are confusing things yourself. there is
>only one time within one system. if you sync this system
>to external, the flow of this time sways somewhat, but
>it's still one integral time.
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. but a sequencer or tape device would use
a positional synchronization signal that is entirely independent of
the sample rate.
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*!
--p
