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