18 Dec
2002
18 Dec
'02
9:13 a.m.
Time in XAP:
-----
SAMPLE_RATE: all plugins know this from create()
- units: frames/sec (uint)
long unsigned int, just to be sure.
TEMPO: a plugin can have a TEMPO control
- units: beats/sec (float)
- deliver a TEMPO event at plugin init and whenever the tempo changes
note that the TEMPO control needs to allow for ramped values just like
other events.
TIMEBASE: fixed value
- units: ticks/beat
- fixed at 1920
METER: a plugin can have a METER control (or controls)
- units: beats/measure (float) and beat-note-size (float)
- another option: encode as a fixed-point value and int inside 32 bits
- deliver a METER event at plugin init and whenever the meter changes
TRANSPORT: a plugin can have a TRANSPORT control
- units: absolute ticks (float)
- deliver a TRANSPORT control when transport starts (start tick), stops
(negative), jumps (new tick value) and periodically (recommend each beat
or each measure)
excellent. i'd suggest one addition though, based on the analysis i
did for JACK based on VST. The TRANSPORT control needs to be able to
indicate a looped state. This allows things like disk-based samplers
and sequencers to fetch the correct data ahead of time, and thus stay
locked to the transport time. JACK just sets the transport state value
to "Looping", and has two additional time points (in audio frames) to
indicate the loop start and end.
Is meter simpler as QN/beat and beats/measure, with
tempo = QN/sec and
timebase=1920 ticks/QN ? It seems that this is how most everyone else does
it. Is it simpler, or is there a reason they do?
the focus on the quarter note is quite irritating to many composers of
non-4/4 music. it adds a whole round of extra thinking that one has to
do so that you convert between QN and whatever beat-note-value you're
actually using. thats why i prefer beats-per-measure,beat-note-value,
tempo=beats/sec, timebase=1920 ticks/beat, as in your summary above.
--p