[linux-audio-dev] XAP: a polemic

Paul Davis paul at linuxaudiosystems.com
Mon Dec 16 21:47:00 UTC 2002


>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



More information about the Linux-audio-dev mailing list