Subject: Re: [linux-audio-dev] XAP: a polemic
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Tue Dec 17 2002 - 04:45:16 EET
>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
This archive was generated by hypermail 2b28 : Tue Dec 17 2002 - 04:42:59 EET