[linux-audio-dev] XAP: a polemic

David Gerard Matthews dgm4+ at pitt.edu
Sat Dec 14 21:27:01 UTC 2002


David Olofson wrote:

>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.
>
Ok, fair enough.  Yes, the approach you outline above seems reasonable.

>>>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.
>
Right.  

>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.
>
Absolutely.

>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.
>>
Point taken.  

>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...
>
Well, not necessarily!  A quarter note is not always the unit of a 
single beat.  In traditional
music theory, 6/8 meter is frequently thought of in 2  - the 
dotted-quarter note gets the beat.
Half-note based meters (2/2, 3/2) are also very common, and things like 
5/16 are not
uncommon in modern music.  That said, I think what you mean by 
quarter-note is
what I would call "counting unit" or "durational unit" or something like 
that.

>  while you can just modulate some audio with 
>(sin(musical_time * M_PI * 2.0) + 1.0) or whatever. ;-)
>
Nice.  Sounds like fun.

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