Subject: Re: [linux-audio-dev] XAP: a polemic
From: Tim Goetze (tim_AT_quitte.de)
Date: Mon Dec 16 2002 - 22:21:54 EET
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.
>>* 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.
>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.
>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.
>in addition to this, the host/API needs to provide two other
>functions:
>
> "get current time information"
>
> - the structure needs to be based on the VST time info structure.
> it will indicate the sample position of the next beat, and
> the next bar. it will indicate the state of the transport,
> including loop information in the way that JACK's time info
> structure does. it can only be called from the "process"
> handler of the plugin, because the information is all
> specific to the current block being processed.
>
> "convert musical time"
>
> - passed a musical time (B|b|t) and an indicator of which
> timeline to use, it returns the audio frame at which
> the event will occur, independent of transport state.
> if transport state matters, the plugin will have to
> handle that itself. this function doesn't require host
> information, but it does require a way to access
> a (possibly) shared timeline and it needs to be implemented
> only once :)
from my experience, more conversion functions are needed, in
effect you need to map from any of these domains to any other:
* bar.beat.fractional (or .tick if you will),
* tick
* time in seconds
* audio frame
you may want to implement it using one call and a structure
with flags denoting your interest, or offer any of these as
a separate function. i have opted for the latter -- to keep
things sane, b.b.f conversion is only done for ticks and
vice versa though.
tim
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 22:33:45 EET