15 Dec
2002
15 Dec
'02
10:11 p.m.
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 ;)
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.
this isn't true. when "transport" time stops, free running audio time,
as well as wallclock time continues to run. moreover, "transport" time
can run backwards while other kinds of time run forwards. there is
absolutely no mapping between "transport" time and a free running
clock.
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.
this is also false. plugins that want to measure time in absolute
terms (e.g. a 150ms delay line) do not pay *any* attention to this
concept of time. the fact that a transport has stopped doesn't change
the way such a plugin operates in any way.
that's what a system-wide uniform time base
requires.
there is no uniform time. there are several timebases, most of which
need to be uniform across the system, and a few of which do not.
--p