16 Dec
2002
16 Dec
'02
11:29 p.m.
On Tuesday 17 December 2002 03.45, Paul Davis wrote:
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.
How much finer?
Well, "exact" *is* nicer than "approximate", so... I'm beginning
to
like this. :-)
Well, since I assume you've both done it, while I (IIRC) have only
done it with integers; point taken.
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.
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.
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 ... 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.
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 ---