[gmpi] Re: [OT] meter representation
- From: "Frederick Umminger" <Frederick_Umminger@xxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 30 Apr 2003 16:50:26 -0700
Paul,
I know that rhythm does not equal meter. But 3+3+2 is not the rhythm of rumba,
it is in fact the (compound) meter. Exactly as 2+2+2, but not 3+3, is the
(compound) meter of waltz. Meter is the repetitive tendency for notes in
certain positions to be stressed or unstressed or form groupings, usually at
several levels of heirarchy. The rhythm is not the tendency, but what actually
is performed. Only in very boring music does the rhythm always match the meter.
Possibly this is just a difference in semantics. I am using "meter" in the
sense of "metrical structure".
To address some specific points:
A/B is in fact not a descriptor of the temporal divisions in music, at least
not an accurate one. The temporal division of waltz is 2+2+2. It really is. And
it really is not 3+3. To perform a waltz in a 3+3 division would be wrong, it
would be a butchery of the music, and would probably completely undanceable.
This is not captured in A/B notation.
A/B is, however, a descriptor of the temporal divisions in music notation. It
tells you what represents one beat, and it tells you how often the bar lines
are going to appear to help you not lose your place. A music program that is
going to produce traditional notation needs to know these things. Plugins,
however, do not.
To ask a plugin to derive the meter from a score, as human musicians do, is to
ask it to perform an incredibly difficult task of artificial intelligence. To
ask it to derive the meter from cultural knowledge, the way human musicians do
("I know the next piece is a samba"), is to simply ask it to do the impossible.
The score does not in fact represent the meter well, precisely because only in
very boring music do the instruments slavishly follow the meter. Even in
musical genres in which there is a rhythm section whose primary purpose is
simply to mark the meter there will be fills and syncopations and
improvisations in the rhythm section instruments.
I don't think A/B really provides the musician with much useful information
beyond which note value equals one beat. From A/B one cannot tell the length of
the dominant metrical cycle, which may be longer, or possibly even shorter,
than one measure. One also cannot reliably tell what the note value of the
tactus is, or which beats of the measure are accented, or by how much. One
cannot tell which beats are grouped, or which beats are swung. It tells you
almost nothing that you need to know in order to respect the metrical feel of
the music.
-Frederick Umminger
-----Original Message-----
From: Paul Davis [mailto:paul@xxxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, April 30, 2003 11:18 AM
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: [OT] meter representation
ah, a subject dear to my heart, and one my major reasons to begin
writing a replacement for protools 3 years ago :)
the fundamental problem with these objections, despite them all being
based on a completely correct analysis of the weakness of the A/B
representation, is this:
the A/B notation is not a descriptor of rythmic structure
its a descriptor of temporal divisions, and no more. it fails
miserably at representing rythmic structure, which is fine because its
clear that musicians are able to handle the music just fine. how do
they do this? they do it in one (or both) of two ways:
1) they read the score
2) they ignore the meter and use "tradition" to define
the rythmic structure (e.g. most music coming out
of almost any non-caucasian culture)
we don't have any standards for representing rythmic structure, which
i suggest is firstly because of the profoundly simple approach to
rythmn within the western canon and secondly because rythmic structure
has been well handled by tradition and score interpretation.
>dard afro-cuban rhythms. They are all nominally 2/4 or 4/4, but in reality the
>y all obviously have distinct multi-level patterns of stressed and unstressed
>(and swung) beats that are crucial to the feel.
right, and the rythmic structure of such music is not represented by
the A/B notation. however, it turns out that the score represents it
quite well to any non-percussive musician that actually reads a score.
most of the time, percussionists involved are not generally reading a
score at all except to provide sync with everyone else.
the problem is, therefore, not how to replace the A/B notation which
clearly provides musicians with *some* useful information in many
cases, but how to augment it for plugins in the same way the score
and/or tradition does for musicians.
>This is not just anal-retentive music-theoretic wankery. If the true metric st
rythmn != meter. thats the whole point. A/B tells you how we break
down time in the simplest way. rythmn arises from imposing particular
patterns on that temporal division. they are not the same thing, and
we should not try to represent them both in the same way.
>A standard API needs to be able to express music in a sensible, musically mean
>ingful way, so that sensible, musically meaningful things can be done with it.
> Otherwise it is going to limit the music-making of our entire culture for dec
>ades to come. Real music of quality, in virtually any genre, simply does not f
>ollow the simplistic fractional-meter paradigm.
i absolutely agree with this. as i noted above, it was a major
motivation in beginning to write ardour, although for various reasons
ardour is still not at a point where is can do much better than
protools (or any other DAW) in this area. i haven't even added
per-track tempo maps, partly because i realized that i really want
rythmn maps first :)
i think the closest we get to this right now in software is via drum
editors, and i think there is interesting work to be done defining
representations of rythmic structure for music software. there is a
long way to go to get as far as i think both of us would like to.
sharing such information will eventually be as important within GMPI
as sharing the A/B tempo map is already.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
