[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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: