[linux-audio-dev] XAP: a polemic

Tim Goetze tim at quitte.de
Wed Dec 18 12:56:01 UTC 2002


David Olofson wrote:

>> >Well, you've already disqualified at least one on this list, I
>> > think. (And I don't count myself, of course.)
>>
>> which?
>
>Well, that would be David Gerard Matthews, IIRC.

did i? i didn't mean to fwiw.

>> i'll remind you that 9.5 = 19 / 2 -- that doesn't prove
>> me wrong.
>
>Well, that doesn't make x == x / 2. (Unless x == 0, but that's 
>irrelevant, of course.)

the meter describes only the division of musical cycles,
not which beats are emphasized. otherwise all 4/4 pieces
would sound the same.

>> it is not theoretical. it is the practical foundation of
>> musical time.
>
>You keep saying that. It may be practical most of the time, but what 
>makes it the only correct representation?

true, you can go for what you want.

>> why should it? it knows what time unit it is synced to, doesn't
>> it? at least that usually is one of its prime parameters.
>
>Yes, but if you specify it as "1 beat", it will look at the meter, 
>and then *boom* - incorrect results...!

but if your plugin can either do, say, 1/8, 1/16, etc, and
'beat', you introduce a special case for no particular reason.

>> not at all. but you don't have to complete the current
>> measure to put in a new meter, do you? it's just a way
>> to count the passage of time, it's not time itself.
>
>So, meters are basically timstamped, short fragments of defined time 
>placed arbitrarily along the timeline? Sounds a *lot* messier than 
>just assuming that the next one starts where the current one ends, 
>and allowing any lengths.

that's right, they remain valid until the next meter.
your case of a shortened measure is even easier if you
simply add a new meter where the shortened ends -- it
only needs one new meter, not two as you propose.

>> there is no *real* beat value. if your arpeggiator starts
>> emitting 8th notes when switching to 4/4 from 7/8, i'd say
>> there's something wrong with it.
>
>Not if you *specifically* tell it to interpret the parameter as 
>related to the beat value, rather than a specific note value.

see above on emphasis/meter and sync choice, and why this
implementation would be less handy.

>> anytime you introduce a
>> new meter, you introduce a new "one" beat. your plugin
>> absolutely needs to sync to that, right?
>
>Yes - just like it locks to musical time, whatever the meter may be. 
>The point is just that the plugin should be able to *understand* the 
>meter as it was indended by the composer - or, plugins should not 
>have access to the full meter information in the first place, since 
>it becomes essentially musically irrelevant.

for the plugin to *understand* the meter, you'd need more
intelligence than any computer can offer anyway. there's no 
difference between 4/4 and 4.0/4.0 but there is a whole lot of
difference between a wes montgomery 4/4 and a deep purple 4/4.

>Ever heard a "break" (as they call it in pop music) in a shortened 
>bar?
>
>The "breaking" of the periodicity is sometimes *intentional*, and 
>often so subtle that you can't reasonably "count" to deal with it. 
>63/64ths...?

go ahead, you can do this without fractional beats -- as you 
say, use 63/64.

>You've probably also failed to notice a rather popular "trick" used 
>back in the disco era was to lag behind over the measure, for that 
>"push" feel of the one beat. (Yeah, it has a name too, but I can't 
>seem to remember it, being totally illiterate when it comes to music, 
>and all...)

that is in reference to another beat, yes? that doesn't have
anything to do with fractional meters, right?

>> please put them here; i honestly don't know which questions
>> you are referring to.
>
>Well, sorry if I just missed it, but I'm still waiting for an 
>explanation as to why non-integer meters automatically result in 
>sequencer/plugin sync issues.

i haven't made any claims about sync issues, did i?

>I'm here to participate in the creation of a plugin API. I'm much 
>more interested in serious arguments than in being personally 
>attacked for having the wrong view, or whatever this is about.

i don't mean to attack you personally. i do see the need
of pointing out where you make claims that are unfounded,
just as you do when i make such claims.

>Why? Counting in ticks, you can handle these subdivisions without 
>rounding errors. Then it doesn't really matter if they represent 
>integer *beats* and *note values*, since they're still integer 
>numbers.

you can't implement fractions on a finite-precision machine
without error if you don't choose integers for both n / d,
right?

tim




More information about the Linux-audio-dev mailing list