[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Wed Dec 18 16:30:01 UTC 2002


On Wednesday 18 December 2002 18.20, Tim Goetze wrote:
[...]
> >> 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.

Well, that's a point - but I think we should leave that part to the 
user. The API isn't supposed to create the music! :-)


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

There is a reason. My disco reference below would be one example.


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

Two? That's not what I meant. Either way, the problem with this is 
that the plugin doesn't know where a measure ends before it gets the 
new one. That makes it pretty hard to do any useful beat sync 
processing, since you never know the length of a beat for sure.


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

I'm not talking about AI - just that if you want 4/4 shortened just 
slightly, you should still be able to have simple beat sync plugins 
understand that you still want 4 beats, not 15 or 31 or whatever.


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

Yeah, great...


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

It's been explained as playing straight 4/4 at a slightly lower tempo 
than the duration of one measure would indicate.

I would interpret that as the last "4th" being slightly shorter than 
the first 3, since the next measure starts early.


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

No, that's probably rather what I assumed your claims about precision 
issues would be related to, since I'm still not seeing where you 
could go "wrong enough that it matters", as long as you base your 
calculations on the tick where the meter starts.

I'm basically looking for actual examples of when you end up doing 
the wrong thing, because you have an inexact meter, such as 4.3/4 
expressed as 4.3/3.0 - especially if, as you suggest later, meters 
are placed at explicit points along the timeline. Could a meter 
realistically make the measure long enough that you land more than a 
very small fraction of a sample away from where the sequencer thinks 
the measure ends?


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

Well, you have interesting ways of making a point at a time, but no 
serious offense taken. :-)

And indeed, it can't hurt to consider all aspects and verify all 
claims before throwing stuff into an API. Especially with unusual 
solutions where we don't have a lot of existing implementations to 
learn from. It's not all that fun to correct mistakes after the API 
is finalized...


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

Right, but consider these two:

1. (3+1/3)/4. Expressed in the units I suggested before (if I
   got it right, that is), it's 6400/7680. A beat is 1920/7680,
   and a measure is 6400/1920 beats. Indeed, values like 1/7
   won't give nice exact results, but how close do you have to
   get? 274/1920 is rather close.

2. Musical time is expressed as 1920 ticks per *beat*, and tempo
   as beats/minute (or beats/second, maybe). This means that the
   beat value has only one real function: It defines the relation
   between beat values of meters. It's the value you multiply the
   typical QN/minute "BMP" with to get the XAP tempo.


What you see outside the sequencer is simply a tick counter that 
counts to 1920 for each whole beat. In the (3+1/3)/4 example, a new 
measure will start every 6400 ticks. Tempo is <whatever>*1920/7680.

So, how about just rounding the meter values so you always have an 
integer number of ticks per measure? (Not that I'm sure I see any 
point in it.)

However, I'm also interested in finding out whether the sequencer's 
"new measure starts now" event would be sufficient for ensuring sync 
when *not* rounding. After all, you don't know what the next measure 
will look like, so you can't assume anything about it until you 
actually get the event - and then you know where the sequencer 
believes the measure starts. Since measures can be of different 
length, you can't just divide the song position with it, so you have 
to base your calculations on where the measure actually starts anyway.


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