[MEI-L] Beat in 6/8
Kőmíves Zoltán
zolaemil at gmail.com
Tue Sep 1 11:54:44 CEST 2015
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>:
>
> 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 (w)
> pdr4h (at) virginia (dot) edu
> ------------------------------
> *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland,
> Perry D. (pdr4h) [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 (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 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> 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 (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.
>>
>> Laurent
>>
>> On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl <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> 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
>>> 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 listmei-l at lists.uni-paderborn.dehttps://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>
>>>
>>>
>>> _______________________________________________
>>> mei-l mailing list
>>> 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
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>
>>
>
> _______________________________________________
> mei-l mailing list
> 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/20150901/b56f4cde/attachment.html>
More information about the mei-l
mailing list