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