[MEI-L] Beat in 6/8

Roland, Perry D. (pdr4h) pdr4h at eservices.virginia.edu
Thu Aug 27 17:02:38 CEST 2015

Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an attribute?

And how does one allow an attribute directly "in" <measure> or <staff>?

We should stay away from determination of meter in MEI.  As we've already heard, it often introduces a lot of subjectivity and interpretation.  That kind of thing is best left to a different, analytical layer.

I still don't see the point -- what does this have to do with beatRpt?


Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com]
Sent: Thursday, August 27, 2015 10:45 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Beat in 6/8

What seems fortunate to me is that "beat" is not used as attribute in MEI (yet?)

Maybe we could use it when we need to specify a musical beat that is not the meter.unit. As I suggested with <beatRpt>, it would be assumed to be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired musical beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, it could be useful to allow the attribute directly in <measure> (or even <staff>?) when the beat structure is changing.


On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl <bohl at edirom.de<mailto:bohl at edirom.de>> wrote:
Dear Craig,
 many thanks for your always helpful advice!

Am 27.08.2015 um 11:08 schrieb Craig Sapp:

The problem is the ambiguous/conflicting terminology in this sentence:

On 27 August 2015 at 01:19, Benjamin Wolff Bohl <bohl at edirom.de<mailto:bohl at edirom.de>> wrote:
meter.unit contains the number indicating the beat unit, that is, the bottom number of the meter signature.

This is only ambiguous/conflicting if you are to smart and know too much about music! Regarding the term "beat" in the closed system of MEI everything is obvious an unambiguous.

The problem is that in compound meters such as 6/8
The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note.  Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is.

This then would promote using another term in MEI in order to avoid confusion, let's say "meter-unit-n".

The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat.

This could be a beating argument, if it is the purpose and intention of MEI to do musical analysis.
Is it? I'd rather say it provides a basis for doing analysis, the logic of the analysis is not part of MEI, although the result of the analysis might be encoded in MEI.

The musical beat is also needed to automatically beam notes.  Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat.

"Automatically" beaming notes is not part of the encoding but of the rendering logic an thus will not be reflected in (pure-logical-domain-)MEI.

For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same.

Another more common corner case would be time signatures such as 3/8.  Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)?

And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures.

The two above are only a problem if we consider "beat" as being the "musical beat". If we consider it to be "meter-unit-n" instead, everything would work out fine.

Compound meters resulted in a degeneration of mensural notation.  Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent).  These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level.

Ok, air is getting thin for me...
I've had a problem with modern transcription of mensural notation ever since I first encountered it, or more precisely I was whinig about modern notation being so restrictive due to having abandoned mensuration signs. I would prefer modern transcription sticking to mensuration signs and logic instead of adding dots, but I might not be able to change the world about this...

But to bang the drum for "meter-unit-n": Couldn't this problem also be solved by <mensur> or some additional attribute on <scoreDef> or <staffDef>?

Considering the case of a modern transcription of "perfect" mensural notation using <beatRpt> in terms of "meter-unit-n" would result in completely different applicable cases compared to using it in the sense of "musical beat". An there it is the again,
** ambiguous and conflicting**

Just for the sake ofplaying advocatus diavoli  3;-)

I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases...


mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>

mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20150827/33db7ac3/attachment.html>

More information about the mei-l mailing list