16 Dec
2002
16 Dec
'02
4:35 p.m.
Paul Davis wrote:
you absolutely need ppq for the tick system to properly map
different measures (5/4 time, 6/8 time etc) as per previous
post.
you're better off specifying tempo as quarter beats/minute
uniformly for the above reasons.
* 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. * 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. 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