15 Dec
2002
15 Dec
'02
10:45 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.
Whether the part of the timeline we're dealing with for any
particular block contains lots of tempo changes, or one or more tempo
ramps, is irrelevant. It's a totally different problem.
(BTW, a problem that is handled very poorly by VST. There, you can't
tell when this happens without asking for a VstTimeInfo, and then for
the tempo for each frame of the whole buffer - 1 sample. *That's*
what I call a waste of resources, when most people will have 10 tempo
changes in a song, at most...)
Exactly.
*Exactly.*
Right. Basically, just pick one that's free running and handy to work
with most of the time, so you don't end up without a common reference
for basic communication while the net is still running.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
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.
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.)
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.