Subject: Re: [linux-audio-dev] XAP: a polemic
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Mon Dec 16 2002 - 05:51:39 EET
>On Monday 16 December 2002 03.09, Paul Davis wrote:
>> >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.
>>
>> two words i learnt from ardour-dev: accelerando, decelarando. think
>> about it ;)
>
>You still want it applied to all plugins in *sync*, don't you? You
>don't run a random set of plugin using and older version of the
>timeline.
my point was that the tempo *is* changing within processing
cycles. its moving from one value to another. unless the API allows
this to be indicated, its goodbye to a certain category of organized
noise. you can't feasibly indicate it with a value for each sample -
you need to indicate it with a ramp. nothing we've spoken about so far
has covered this.
>> moreover,
>> "transport" time can run backwards while other kinds of time run
>> forwards.
>
>That's an interesting point, BTW. How do you handle queued events
>with musical timestamps in reverse order...? :-)
how do you handle any queued events in reverse order?
>> there is absolutely no mapping between "transport" time
>> and a free running clock.
>
>Well, perhaps besides the point, but what would you call the implicit
>"mapping" that is defined as events finally reach the outputs of your
>interface, in the form of audio signals? (I mean, theoretically,
>there has to be one, since every timestamp, whatever domain it
>belongs in, eventually ends up in the real world, as a real "event"
>that occurs at some point in wall clock time.)
what do i call it? "user operations". the mapping is defined in
real-time at run-time by the choices the user makes. "start", "stop",
"locate to time T", "rewind", "loop over this section", "slow that
down" etc. by the time we have this information, there is a mapping,
but its too late to be useful.
--p
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 05:51:23 EET