16 Dec
2002
16 Dec
'02
5:37 p.m.
Paul Davis wrote:
it is ticks for all i know, spell it tpq if you happen
to like that better. have you ever parsed a MIDI file?
the same value is called 'division' in the file specs.
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.
it must be assumed the hosts knows seconds-per-beat better
than the plugin. thus, forcing another calculation back
from frame units is illogical.
what arithmetic is cumbersome? beats-per-measure has to floating to
accomodate most non-western music, and if thats a float, you may as
well make beat-note-value the same, to avoid constant casting back and
forth.
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.
about arithmetic: float operations, as you know, introduce
round-off error. integers can be used in accumulators with
much less inconvenience.
tim
you absolutely
need ppq for the tick system to properly map
different measures (5/4 time, 6/8 time etc) as per previous
post.
well, if ppqn is variable, then sure. but cubase and all other vst
apps have defined it to be 1, which makes it irrelevant. their "pulse"
or "parts" (there seems to be disagreement over what the first "p" in
"ppqn" stands for) is not the same as the "tick" are discussing,
however. 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
better off specifying tempo as quarter beats/minute
uniformly for the above reasons.
what reasons? after 2 rounds of fairly intense discussion on
ardour-dev, we could find no reason to favor quarters over any other
value. it makes no difference unless all the music you ever want to
handle uses quarters as the beat note value. since this is
demonstrably false, there is nothing particular interesting about
using quarters. 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. the METER event needs to include
beats-per-measure (floating point value) [ 3, 5, 7, 9.5 etc ]
beat-note-value (floating point value) [quarter,1/16th, etc]
i wouldn't make either a float, it is by far too uncommon
to be justified and makes some arithmetic cumbersome.