Subject: Re: [linux-audio-dev] XAP: a polemic
From: David Olofson (david_AT_olofson.net)
Date: Mon Dec 16 2002 - 04:40:01 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.
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...)
> >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.
Exactly.
> 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.
*Exactly.*
> >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.
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 ---
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 04:48:01 EET