[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Sat Dec 14 21:14:01 UTC 2002


On Sunday 15 December 2002 00.32, Paul Davis wrote:
> >>	* Is there a good reason to make event system timestamps
> >>	  relate to musical time rather than audio time?
> >
> >Again, I would rather let the timestamps deal with audio time. 
> > Hosts which work in bars/beats/frames
> >should be capable of doing the necessary conversion.  Remember,
> > there
>
> you're ignoring *plugins* that want to work with B|b|t durations.
> the canonical examples that i've mentioned several times are
> tempo-synced LFO's and delays. these can either be plugins on their
> own or more likely for XAP, integrated into a modulation section of
> an "instrument".

Exactly.

Unless I'm missing something, all you need for this is a way for 
plugins to keep track of the tempo (sync) and musical time (lock). 
The TEMPO + POSITION_* event set I proposed should be sufficient for 
for sample accurate lock to musical time, even accross tempo changes 
and transport skips.


> >are plenty of parameters which might need some time indications
> > but which are completely unrelated to notions of tempo.  I'm
> > thinking mostly about LFOs and other modualtion sources here
> > (although there might be good grounds for lumping these in with
> > frequency controlled parameters.)  Just as I would rather
>
> yes, sometimes you might want to control them quite independently
> of tempo. but lots of the most interesting instruments in the
> software synth world now allow tempo sync as an option, and its
> very nice to have it available.

It is not just "very nice"; it's a required feature, IMNSHO.

And it should preferably be sample accurate, and capable of tracking 
even the most furious tempo maps. Someone will complain sooner or 
later if they aren't.


> >see pitch control make as few assumptions as possible about tuning
> >and temperament, I would like to see time control make as few
> >assumptions as possible about tempo and duration.  Sequencers
> >generally do operate within the shared assumptions of traditional
> >concepts of periodic rhythm, but in a lot of music (from pure
> > ambient to many non-Western musics to much avant-garde music)
> > such notions are irrelevant at best.
>
> true, and i've been known to make this point myself. but the fact
> that there is a lot of music in which periodic rythmn is irrelevant
> doesn't erase all the music in which its a central organizing
> principle. coming up with an API that doesn't facilitate periodic
> (even if highly variable) structure when arranging things in time
> makes working with such music more cumbersome than it need be, some
> of the time.

I would like to clarify something here: musical time as used in an 
API is not by definition "periodic". (That's just an interpretation 
of it, normally based of the time signature.)

The APIs that don't use audio frames for timestamps and song position 
generally use "ticks". 1.0 per quarter note is a fine unit, for 
example, if we (like practically everyone else) decide to use the 
quarter note as the base. It's rather handy, because a quarter note 
is always a quarter note, but a bar might be anything...

The important point is that musical time represents the movement of a 
*timeline*. Unlike audio time, it is not free running time in any 
way, but a representation of the sequencer's idea of time. That is, 
locking to musical time is essentially the same thing as locking to 
the sequencer. And if you do that, your plugin and the sequencer will 
have a common reference for time, that the sequencer can play around 
with as it wishes, while you can just modulate some audio with 
(sin(musical_time * M_PI * 2.0) + 1.0) or whatever. ;-)


//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 mailing list