[linux-audio-dev] XAP: a polemic

Tim Goetze tim at quitte.de
Sun Dec 15 17:21:00 UTC 2002


David Olofson wrote:

>> >Musical time *stops* when you stop the sequencer, which means that

>How would you go about implementing an event delay effect?

by definition, time isn't flowing when the transport is 
stopped. a delay in stationary time can only be a zero
delay because there's no future. this doesn't preclude 
other ways of processing, ie. plugins might only refrain 
from scheduling future events in stopped state.

>This won't help if you're locking to an external device. (I'm sure 
>Paul can explain this a lot better - I only seem to confuse people 
>most of the time...)

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.

>> you may also want to synchronize changes to the tempo map and
>> the loop points to be executed at cycle boundaries, which is
>> how i am making these less invasive, but that's another story.
>
>I certainly wouldn't want the API to depend on such limitations. 
>Applications may do what they like, but thinking of block/cycle 
>boundaries as anything more than the limits for the non-zero length 
>time span that is "now", is not helpful in any way, if you want fully 
>sample accurate timing.

block/cycle boundaries exist because hosts do block/cycle
based processing -- and will do so for a couple of years
on commodity hardware. conceptually, blockless processing
is no different from one-sample sized blocks.

if you change/add tempo map entries while only half your
network has completed a cycle, you're in deep sh*t. i
found the easiest solution to be preventing this from
happening in the first place. 

i don't see how this plays into sample-accuracy matters.

>I'm arguing for audio timestamps, because I do not want plugins to 
>have two different time domains forced upon them, especially not when 
>stopping one of them prevents plugins from communicating properly.

it does not, because any point in time can be expressed in
any domain. and to repeat, in stopped state all clocks are 
frozen, no matter what they count. and to repeat again, 
device-dependent units for information interchange across
implementation/abstraction layers are stoneage methodology.

>You're not required to sequencer every event in the network. 

you wouldn't mind either, would you?

>> transport control is no event because it invariably involves
>> a discontinuity in time, thus it transcends the very idea of
>> an event in time.
>
>Yes - if you think of time in terms of musical time only.

if you think in any form of transport time, be it ticks,
seconds or frames. this is the time context that plugins
operate in. any other concept of time is orthogonal.

>> and plugins don't have an internal 'song position counter'.
>
>It could be anywhere, but then you'd have to make a call somewhere 
>every time you want a sample accurate version of it.

that's what a system-wide uniform time base requires.

tim




More information about the Linux-audio-dev mailing list