15 Dec
2002
15 Dec
'02
11:53 p.m.
On Monday 16 December 2002 03.09, Paul Davis wrote:
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.
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 ;) 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...? :-) 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.)