[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Wed Dec 18 07:19:01 UTC 2002


On Wednesday 18 December 2002 11.51, Tim Goetze wrote:
[...]
> >TIMEBASE:  fixed value
> >  - units: ticks/beat
> >  - fixed at 1920
>
> no way. this is an arbitrary value,

Not really. It happens to give you exact results when divided with 
lots of interesting integer values.


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

Well, which ones qualify?


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



More information about the Linux-audio-dev mailing list