[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Mon Dec 16 20:40:01 UTC 2002


On Monday 16 December 2002 22.30, Tim Goetze wrote:
[...]
> >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.

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


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


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



More information about the Linux-audio-dev mailing list