[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Mon Dec 16 22:31:51 UTC 2002


On Tuesday 17 December 2002 03.45, Paul Davis wrote:
> >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.

Well, double has some 14 figures of accuracy (decimal), so it would 
be more like 0.33333333333333 or so. When you're at tick 1000.0 (1000 
*beats*!), it would be 1000.3333333333. Given 120 BPM, that would be 
at a sample rate of 192 kHz, you'll have 12 fractional bits per 
sample. 1000 beats at 120 BPM is 83.3 days.

Please check; I could be missing something.

If not, I simply have to disagree. :-)


Note that I'm *not* suggesting that sequencers must use this 
internally.


> >>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.

How much finer?


> having 1 tick per beat is just ...
> well, its just dumb, even if it is floating point.

Why call it a "tick" at all? (That's not really my invention. I'd 
just call it "musical time".)


> >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 ...

Well, "exact" *is* nicer than "approximate", so... I'm beginning to 
like this. :-)


> >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.

Well, since I assume you've both done it, while I (IIRC) have only 
done it with integers; point taken.


> >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.

Still, if it's floating point, there is no such restriction, really. 
You *could* implement a sequencer with higher resolution, and make 
use of the fractions below 1920.


> 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.

Right. There's no absolute maximum resolution.

So, considering the advantage of double with 1920 ticks/beat being 
truly useful inside sequencers (no rounding errors), and it still 
providing sub-tick accuracy, I move over to the 1920 side.

	XAP audio time unit:	1920.0 ticks/beat


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list