[linux-audio-dev] XAP: a polemic
david at olofson.net
Sun Dec 15 20:03:01 UTC 2002
On Sunday 15 December 2002 23.13, Tim Goetze wrote:
> David Olofson wrote:
> >> >Musical time *stops* when you stop the sequencer, which means
> >> > that
> >How would you go about implementing an event delay effect?
> by definition, time isn't flowing when the transport is
My hardware synths and FX disagree...
> a delay in stationary time can only be a zero
> delay because there's no future. this doesn't preclude
> other ways of processing, ie. plugins might only refrain
> from scheduling future events in stopped state.
Sure, but I still don't see any real advantage with *forcing* this
upon the system.
I would find it really rather logical if plugins did the same thing
as my synths when I stop the sequencer - which means maintain tempo,
and let "musical time" freewheel until the sequencer tells them to do
Nothing will convince me that this does not make sense, or that it is
useless. I know for a fact that it *is* both sensible and useful, and
I can see no technical or political reasons to prevent plugins from
acting in the same way.
> >This won't help if you're locking to an external device. (I'm sure
> >Paul can explain this a lot better - I only seem to confuse people
> >most of the time...)
> yes, because you are confusing things yourself.
I'm quite sure I'm not, but I seem to be having a hard time
explaining what I mean. This is getting really rather frustrating...
> there is
> only one time within one system.
So now we don't have wall clock time, audio time, musical time, SMPTE
time or anything else; just "time"...?
Sure, wall clock time is the only *real* time there is. The rest are
just timelines that you map to wall clock time directly or
indirectly, one way or another.
> if you sync this system
> to external, the flow of this time sways somewhat, but
> it's still one integral time.
I would like to see how you manage to sync your audio interface to an
external sequencer or VCR... You may lock the sequencer, but the
audio card (which may well drive the sequencer's thread physically)
will just play the fixed 48 kHz rate you told it to use.
> >> you may also want to synchronize changes to the tempo map and
> >> the loop points to be executed at cycle boundaries, which is
> >> how i am making these less invasive, but that's another story.
> >I certainly wouldn't want the API to depend on such limitations.
> >Applications may do what they like, but thinking of block/cycle
> >boundaries as anything more than the limits for the non-zero
> > length time span that is "now", is not helpful in any way, if you
> > want fully sample accurate timing.
> block/cycle boundaries exist because hosts do block/cycle
> based processing -- and will do so for a couple of years
> on commodity hardware. conceptually, blockless processing
> is no different from one-sample sized blocks.
Well, why do you seem to have the idea that I wouldn't agree?
> if you change/add tempo map entries while only half your
> network has completed a cycle, you're in deep sh*t.
Yes indeed. That's *exactly* what I've been trying to say a number of
> found the easiest solution to be preventing this from
> happening in the first place.
It's the *only* solution. Plugins that run in the same cycle will
(usually) generate data to be played at the same time, so anything
else would simply be incorrect. You can't be at two places in the
same timeline at once.
> i don't see how this plays into sample-accuracy matters.
Well, it doesn't really. It applies to block "accurate" timing as
The point I was trying to make is just that once you start processing
one block, nothing can change. The timeline during that block is
strictly defined and synchronized with whatever you're sync'ing your
sequencer to. The mapping from the timeline to audio time is known
Now, why does it make a difference if you get events timestamped in
audio time or whatever other format someone might find useful? You
can translate back and forth. What makes most sense to *me* at least,
is not to be forced to convert anything if you're only interested in
the actual place in the buffer where each event should be handled.
Besides, VST and AudioUnits all use audio timestamps to control
synths and effects. AFAIK, DXi does too. Mess (MusE synths) isn't
exactly widely adopted, but that's another example.
I have yet to see a widely adopted plugin API that does not use audio
What is it that we're all failing to understand!?
> >I'm arguing for audio timestamps, because I do not want plugins to
> >have two different time domains forced upon them, especially not
> > when stopping one of them prevents plugins from communicating
> > properly.
> 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.
It's just that when the sequencer is stopped, any point in free
running audio time maps to the same point in musical time.
I don't see a good reason to force plugins to accept that, unless
they actually care.
> >You're not required to sequencer every event in the network.
> you wouldn't mind either, would you?
Well, I guess it *could* be useful to control every single plugin
from one place, but I think that most useful setups are more complex
than that. You need to chain plugins to construct anything
interesting, and plugins that don't care about musical time should
not need a direct connection to the sequencer, just to be able to do
much at all. Nor should they be deprived of all means of
communicating anything but audio data with sample accuracy while the
sequencer is stopped.
> >> transport control is no event because it invariably involves
> >> a discontinuity in time, thus it transcends the very idea of
> >> an event in time.
> >Yes - if you think of time in terms of musical time only.
> 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 where I strongly disagree. *Audio time* is what plugins
operate in - or you wouldn't call their process() callbacks, would
> >> and plugins don't have an internal 'song position counter'.
> >It could be anywhere, but then you'd have to make a call somewhere
> >every time you want a sample accurate version of it.
> that's what a system-wide uniform time base requires.
No. It's just one way of implementing an interface to it.
You obviously don't understand what timestamped events are all about,
and what you can do with them.
//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 ---
More information about the Linux-audio-dev