18 Dec
2002
18 Dec
'02
5:29 p.m.
On Wednesday 18 December 2002 18.20, Tim Goetze wrote:
[...]
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! :-)
true, you can go for what you want.
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.
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.
[...]
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.
Yeah, great...
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.
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?
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...
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 ---
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.) 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? 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...! 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. 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. 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'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?