16 Dec
2002
16 Dec
'02
10:46 p.m.
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