[linux-audio-dev] XAP: a polemic

Paul Davis paul at linuxaudiosystems.com
Mon Dec 16 16:02:01 UTC 2002


>Paul Davis wrote:
>
>>>* Host sends buffers of N samples to plugins, with a starting timestamp
>>>* Things send timestamped events to plugins
>>>* Timestamps are measured in whole audio samples
>>>* Host/timeline must export/deliver:
>>>  - SAMPLE RATE (samples/sec - passed at instantiation)
>>>  - TEMPO (sec/tick - event?)
>>>  - PPQN (ticks/qn - host-global? event? fixed?)
>>
>>i suggest forgetting this. VST sets it to 1 PPQN, and treats "QN" as
>>"1 beat", so the information is really quite useless. there's no need
>>for it given TEMPO and METER.
>
>you absolutely need ppq for the tick system to properly map
>different measures (5/4 time, 6/8 time etc) as per previous
>post.

well, if ppqn is variable, then sure. but cubase and all other vst
apps have defined it to be 1, which makes it irrelevant. their "pulse"
or "parts" (there seems to be disagreement over what the first "p" in
"ppqn" stands for) is not the same as the "tick" are discussing,
however. 

so yes, ticks-per-beat is still necessary, but its a constant (1920 in
ardour). 

>>>* units for meter (I don't know enough music theory to answer properly)
>>
>>after much discussion about this on ardour-dev, we settled on beats
>>per minute, where beats are whatever unit the time signature is
>>using. for some music, the unit is irrelevant, because nothing else
>>uses subdivisions of the beat note value in any coherent way (i.e. you
>>can decide that a beat is a quarter note, or a half note or a whole
>>note, and nothing else will care). for other music, its important that
>>the beat value is known.
>
>you're better off specifying tempo as quarter beats/minute 
>uniformly for the above reasons.

what reasons? after 2 rounds of fairly intense discussion on
ardour-dev, we could find no reason to favor quarters over any other
value. it makes no difference unless all the music you ever want to
handle uses quarters as the beat note value. since this is
demonstrably false, there is nothing particular interesting about
using quarters.

>>the TEMPO event needs to include:
>>     
>>     samples-per-beat (as a floating point value) [ time between beats ]
>>     ramp slope  (possibly 0)  [ for accelerando and ritard ]
>>     ramp target (irrelevant if ramp slope is zero) [ ditto ]
>
>add seconds-per-beat for plugins that are not limited to
>audio purposes.

but thats just a straightforward transform of samples-per-beat given
samples-per-second, so there is no reason to specify both. either one
seems equally good to me.

>>the METER event needs to include
>>
>>     beats-per-measure (floating point value) [ 3, 5, 7, 9.5 etc ]
>>     beat-note-value (floating point value) [quarter,1/16th, etc]
>
>i wouldn't make either a float, it is by far too uncommon
>to be justified and makes some arithmetic cumbersome.

what arithmetic is cumbersome? beats-per-measure has to floating to
accomodate most non-western music, and if thats a float, you may as
well make beat-note-value the same, to avoid constant casting back and
forth.

--p



More information about the Linux-audio-dev mailing list