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