[MEI-L] Beat in 6/8

Thu Sep 3 21:15:06 CEST 2015

Hi,

Thanks for contributing to the discussion, Zoltán.  As usual, I too am in favor of multiple encoding methods, especially in the early phases of trying to figure out the best approach – we can deprecate all but one at the point where the “right” solution is obvious.

That being said, and despite what I said earlier about the co-occurrence of @copyof and @plist, I think the two approaches here are:

1. add @plist to <beatRpt> to allow explicit referencing of the events to be repeated
2. add another attribute, yet to be named, to permit encoding of the amount of time to be repeated

The first option is super easy – just make <beatRpt> a member of att.plist.  The differentiation of @plist and @copyof must remain clear, however.  @plist identifies the events to be repeated while @copyof identifies the element *which the beatRpt element is a copy of*.  The likelihood of any element being a copy of another one is rare, so the use of @copyof should also occur very infrequently.

The second option is somewhat more complex, but still practical.  I just don’t think we can overload @dur or @dur.ges for this purpose.  I suggest that syntax similar to that of @dur.ges be used but another name selected, perhaps “beat” or “beatDef”, as its purpose is to define what constitutes a beat in a particular context.  Here, we *are* talking about metrical/musical beats, not MEI beat units.  So, in a measure of 6/8, @beatDef should take the value “4.r” (using Humdrum notation). This defines a repeated beat as a dotted quarter note.  Suggestions for a better name for this attribute are greatly appreciated.

Adding these new attributes may help with automated resolution of a beatRpt sign, but their presence can’t be required, meaning that can’t rely on them entirely in the determination of how much time or which events should be repeated.  There always has to be a fallback approach that makes a reasonable guess based on the context.

I’ve had a cursory look at where/how the term “beat” is used in descriptions and documentation and I think that simply replacing “beat” with “beat unit” won’t work well.  It probably would be better to look for places to insert new text about how MEI treats compound meters literally, for example in section 4.1.5 “Timestamps and Durations”.

Sound good?

--
p.

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Komíves Zoltán
Sent: Tuesday, September 01, 2015 5:55 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Beat in 6/8

Hi All,

As far as I understand there have been two suggestions to solve the problem of determining the material that is repeated by <beatRpt>:
1. use @dur attribute on beatRpt to indicate how much of the preceding material is repeated.
2. provide explicitly what material is repeated.

I think both solutions make sense. The first one is concise, and has no complicated implications, while the second one provides more flexibility - I sense there could be situations when the (1) would not suffice, perhaps some multi-voice situation when only the material in one voice is repeated, but don't want to think about this too hard now... :)

Could we perhaps allow both solutions, so encoders could chose whichever fits best their use case?

Regarding the discussion of beat in compound meters, I also think it's perhaps best to stay away from defining the beat as such, but I also support to clarify terminology: using "beat unit" rigorously could be a good enough solution.

Best
Zoltan

2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>:

Here are some possibilities for moving forward --

Using @copyof on beatRpt makes it possible to indicate which events are to be repeated; for example --

<measure>
  <note dur="8" xml:id="n1"/>
  <note dur="8" xml:id="n2"/>
  <note dur="8" xml:id="n3"/>
  <beatRpt copyof="#n1 #n2 #n3"/>
</measure>

or perhaps

<measure>
  <beam xml:id="beam1">
    <note dur="8" xml:id="n1"/>
    <note dur="8" xml:id="n2"/>
    <note dur="8" xml:id="n3"/>
</beam>
  <beatRpt copyof="#beam1"/>
</measure>

In previous discussions about using the copyof attribute, it has been determined that the copy is a modified "deep" one; that is, that the result tree has the same structure as the designated node with certain attribute values removed or modified, like xml:id, for example.

There's a slight problem with using @copyof, however, in that it doesn't allow multiple URIs. We could allow multiple values, but I'm not sure what it means to say that something is a copy of more than one thing.  That means it's a synthesis, doesn't it?  :-)  So, I'm a little reluctant to add @copyof and I lean more toward adding @plist instead.  Of course, this also gets us into a  little trouble as both @copyof and @plist would be allowed.  As a work-around, a new @targets (notice the plural) could be added to beatRpt.

Another option is to allow beatRpt to contain content -- either new events that duplicate those that the repetition sign refers to or <ptr> elements that reference the events; for example,

<measure>
  <note dur="8" xml:id="n1"/>
  <note dur="8" xml:id="n2"/>
  <note dur="8" xml:id="n3"/>
  <beatRpt>
    <note dur="8" xml:id="n4"/>
    <note dur="8" xml:id="n5"/>
    <note dur="8" xml:id="n6"/>
  </beatRpt>
</measure>

or

<measure>
  <note dur="8" xml:id="n1"/>
  <note dur="8" xml:id="n2"/>
  <note dur="8" xml:id="n3"/>
  <beatRpt>
    <ptr target="#n1"/>
    <ptr target="#n2"/>
    <ptr target="#n3"/>
  </beatRpt>
</measure>

Each one of these options allows an easy "toggling" between the repetition sign and the material inside.  The 2nd method may be more flexible because of the use of references.  The down-side for both of these possibilities is that they are more verbose than using an attribute.

Yet another approach is to create a generic copy element, say, <copyOf> that represents a copy of any event.  That may be too general, however.  For example, the function of the copyOf (beatRpt, mRpt, etc.) would have to be placed in an attribute.  This could lead to mis-use and it would be more difficult to control where certain functions could occur.  But, Johannes has put this forward in the past, so he's better qualified to address this approach than I.

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702<tel:434-982-2702> (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] on behalf of Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>]
Sent: Thursday, August 27, 2015 11:48 AM

To: Music Encoding Initiative
Subject: Re: [MEI-L] Beat in 6/8

Ok, this gives us a place to start.  It seems to me, however, that rather than talking about how much time it repeats (as this reignites the confusion around "beat" and "beat unit"), it may be better to investigate ways to explicitly indicate which *events* are to repeated.

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702<tel:434-982-2702> (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] on behalf of Laurent Pugin [lxpugin at gmail.com<mailto:lxpugin at gmail.com>]
Sent: Thursday, August 27, 2015 11:18 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Beat in 6/8
The problem is that when I encounter a <beatRpt> in an encoding I would like to know how much time it repeats. I understand that it represent the repetition of the material that occur on a previous musical beat, as you say. However, since the duration of what the musical beat is not encoded explicitly (as far as I understand) it does not seem to be possible to know it (i.e., how much time it repeats.).

Laurent

On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote:

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?

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702<tel:434-982-2702> (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] on behalf of Laurent Pugin [lxpugin at gmail.com<mailto: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.

Laurent

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
    https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter<https://en.wikipedia.org/wiki/Meter_%28music%29#Compound_meter>
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;-)
Benni

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

-=+Craig

_______________________________________________

mei-l mailing list

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

https://lists.uni-paderborn.de/mailman/listinfo/mei-l

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

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