18 Dec
2002
18 Dec
'02
8:18 a.m.
On Wednesday 18 December 2002 11.51, Tim Goetze wrote:
[...]
Not really. It happens to give you exact results when divided with
lots of interesting integer values.
Well, which ones qualify?
TIMEBASE:
fixed value
- units: ticks/beat
- fixed at 1920
no way. this is an arbitrary value, and there's absolutely
no need for it.
Probably not, in the API. But why take chances, when it's only about
a factor?
some sequencer authors may already have their
own preference here. why make things difficult for them?
Difficult? Just multiply your internal tick counts with whatever you
need to get 1920/beat. (Though I'd probably just use 1920 internally
in the sequencer at all times. You can derive all the standard
"PPQNs" from that, AFAIK.)
please read some more sequencer source code before you
make any
assumptions here. this stance is exactly what made me make a fool
of myself with the initial polemic.
let the user/sequencer combination control this value.
oh and btw: 1920 is not divisible by 9, which is more common
than a division by 10 in music.
Well, maybe we should use 17280 instead? Or an even bigger "product
of primes"? (Or whatever these numbers actually are.)
Either way, it's *still* floating point. Why use 1.0 when you can use
something else and get something slightly more logical (maybe...)
than 1.0 ticks/beat, and that allows you to express *lots* of values
in exact form?
I have explaied that 1.0 would work fine on the API level, and *why*
it would work fine. That applies to 1920 vs other tick resolutions as
well.
METER: a
plugin can have a METER control (or controls)
- units: beats/measure (float) and beat-note-size (float)
rhythmn *is* integral by nature. floats complicate this a lot
for absolutely no good reason.
please, please, please, ask your favourite musician friends.
read good books about it. listen to indian, jazz, techno,
blues, classical western, classical indian, japanese, rap,
whatever music: rhythmn is integral. if you think you really need this, please remember
that this
is how plugins, ie. algorithms implemented on a machine with
a finite computing precision see the meter. it does not say
anything about how musical time is presented to the user.
If you really *want* a bar that's shortened by a fractional beat
(which is not all that unusual, even in pop music), what do you
do...? How do you ensure that plugins that beat sync don't freak out
when you multiply the meter to get integers?
//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 ---