16 Dec
2002
16 Dec
'02
9:39 p.m.
On Monday 16 December 2002 22.30, Tim Goetze wrote:
[...]
What's wrong with 1.0? I don't see the point in introducing PPQN
here. It belongs in sequencer UIs, IMHO. (If you really care, ask for
a XAP_time_info.)
[...]
it must be assumed the hosts knows seconds-per-beat better
than the plugin.
If that's the case, there is a problem with the host/plugin (or
rather sequencer/plugin) interface.
so yes,
ticks-per-beat is still necessary, but its a constant
(1920 in ardour).
there's no point in limiting this to be a fixed value. you're right, it doesn't matter what reference
length you
choose. quarters simply happen to work well, and there's
no need to break with convention here.
Doesn't work very well for 5/8, does it...?
add seconds-per-beat for plugins that are not limited
to
audio purposes.
but thats just a straightforward transform of samples-per-beat
given samples-per-second, so there is no reason to specify both.
either one seems equally good to me. thus, forcing another calculation back
from frame units is illogical.
The only relevant relation to "seconds" here is that with the audio
sample rate - and you have that in common with the sequencer.
[...]
one of the basic properties of rhythmn is that human
beings
are able to count it, otherwise they cannot sync (groove)
to it. no musical tradition i know of violates this principle;
rhythmn is integral by its very nature.
i'd be happy to hear a good example proving this wrong. but
take note that i don't accept 1/2, 1/3 and relatives as
qualifying because they can better be (and usually are)
expressed using integer numbers.
Well, it's just that you can't stretch that "trick" indefintitely,
since eventually, you run out of standard note values - and then you
need float for those anyway.
Either way, if you don't care, don't worry. You can still calculate
the number of ticks in a beat, or in a bar if you want. What
situations are you worried about?
about arithmetic: float operations, as you know,
introduce
round-off error.
No, only when the result doesn't fit in the mantissa.
integers can be used in accumulators with
much less inconvenience.
When are you actually expecting to se *exact* values?
The very process of mapping musical time to an audio sample rate is
inherently inexact, unless you express tempo as a fixed relation
between ticks and samples. (Which is entirely useless.)
//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 ---