18 Dec
2002
18 Dec
'02
1:55 p.m.
David Olofson wrote:
Well, that would be David Gerard Matthews, IIRC.
did i? i didn't mean to fwiw.
the meter describes only the division of musical cycles,
not which beats are emphasized. otherwise all 4/4 pieces
would sound the same.
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.
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.
see above on emphasis/meter and sync choice, and why this
implementation would be less handy.
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 haven't made any claims about sync issues, did i?
Well, you've already disqualified at least one on
this list, I
think. (And I don't count myself, of course.)
which? 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. 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. 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?
tim