>David Olofson wrote: > >>On Monday 16 December 2002 21.59, Paul Davis wrote: >>[...] >>> so yes, ticks-per-beat is still necessary, but its a constant (1920 >>> in ardour). >> >>I suggest 1.0/beat for XAP. (64 bit double.)
this is awful. 1 tick per beat provides lousy resolution. when something happens 1/3rd of the way through a beat, we don't want float representation saying 0.33333333 and not 1/3. >>One may claim that that's not an exact representation, but who cares, >>as long as it's much more accurate than what you need for sample >>accurate timing? its not accurate enough, i think. but more importantly, it just makes things non-intutitive: the tick is supposed to be a finer resolution unit than the beat. having 1 tick per beat is just ... well, its just dumb, even if it is floating point. >the good thing about 1920 is it is divisible by both 3 and 4; >this lets both triplets and even sub-beats evaluate to integer >ticks. precisely. actually, 1920 is the preferred value because its wholly divisable by: 2,3,4,5,6,8,10,12 ... >now even if you implement ticks as float, it does make >programming and debugging of tick arithmetics a good deal >easier. agreed. that was my point entirely. >it is a value that should be set by the host, or in turn >the user, exercising his right to make the choice. ok, but implementation wise this can get tricky, because a tick should ideally correspond to the smallest discrete unit of time that we can schedule a musical event for. in audio terms, this is obviously 1 frame, but thats not so simple if you are doing a MIDI or even MIDI-over-network or even SKINI implementation. --p