18 Dec
2002
18 Dec
'02
6:59 a.m.
Tim Hockin wrote:
TEMPO: a plugin can have a TEMPO control
- units: beats/sec (float)
ticks/sec (float) is much more convenient. for one thing, you
don't have to send both tempo and meter when only one the
meter changes. ticks/sec also happens to play the central
role in time/tick conversion.
TIMEBASE: fixed value
- units: ticks/beat
- fixed at 1920
no way. this is an arbitrary value, and there's absolutely
no need for it. some sequencer authors may already have their
own preference here. why make things difficult for them?
please read some more sequencer source code before you make any
assumptions here. this stance is exactly what made me make a fool
of myself with the initial polemic.
let the user/sequencer combination control this value.
oh and btw: 1920 is not divisible by 9, which is more common
than a division by 10 in music.
METER: a plugin can have a METER control (or
controls)
- units: beats/measure (float) and beat-note-size (float)
rhythmn *is* integral by nature. floats complicate this a lot
for absolutely no good reason.
please, please, please, ask your favourite musician friends.
read good books about it. listen to indian, jazz, techno,
blues, classical western, classical indian, japanese, rap,
whatever music: rhythmn is integral.
if you think you really need this, please remember that this
is how plugins, ie. algorithms implemented on a machine with
a finite computing precision see the meter. it does not say
anything about how musical time is presented to the user.
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 meter information has to convey: the relation of the
denominator to what you call TIMEBASE above, and the nominator.
for tempo, bpm (quarter notes/minute) seems the convention in
user interaction. as has been said, ticks/second seems to be
the most practical value to communicate.
tim