[MEI-L] Beat in 6/8

Fri Sep 4 11:31:41 CEST 2015

Hi Zoltan,

Am 03.09.2015 um 23:47 schrieb Kőmíves Zoltán <zolaemil at gmail.com>:

> Hi Jo,
> 
> Interesting proposition! I am sure there are great use cases for this, especially for editorial purposes. My feeling is that the sugar of beatRpt would still be handy for a great deal of cases.
> 

By no means I'm in favor of removing all the specialized <*Rpt> elements, so <beatRpt> should definitely stay. It's just that the <cpMark> can be very explicit about what to copy in cases where the "beat" may be confusing.

> I have couple of questions:
> 1. tstamp="2" tstamp2="0m+2": it seems to me that a context is needed in order to determine how long this repetition lasts, i.e. it will last for as long as the material at tstamp="2" lasts for. Do I understand this correctly?

Well, afaik we didn't come across a beatRpt that would have been replaced by a <cpMark>. In essence, this is another occasion of the "ending tstamp" discussion Raffaele brought up with addressability proposal. My assumption with encoding this (in 4/4) was that the first beat holds a quarter note. If there were 8th notes, I would have written tstamp2="0m+2.5". I know this isn't absolutely satisfactory, but I believe it's a more general problem, which just surfaces in this situation. But yes, your understanding is correct.

> 2. What would the "target slot" addressed by the @ref.* attributes contain? <space> perhaps?

That's how we used it. Actually, we generated a <choice>, with an <abbr> containing a space, and an <expan> containing the copied material. This way, you can simply decide if you want to see the source as it is written or as it is performed. In addition, all "copied" notes etc. have a @corresp pointing to their original counterpart, which makes certain analytical approaches very simple.

> 3. ref.tstamp2 feels redundant. Is it mainly for convenience reasons? (I could see why, especially when the target context has a different meter...)

In most cases, it is redundant (and could be defaulted to the value of @tstamp2 in the documentation). However, if you try to encode a <halfmRpt> with the means of <cpMark> (which we did quite often), your origin sits in a different slot than the target. The complex meters you brought up in your other mail also require to have a separate attribute for this, I believe.

Thanks,
jo

> 
> Best
> Zoltan
> 
> 
> 2015-09-03 21:49 GMT+01:00 Johannes Kepper <kepper at edirom.de>:
> Hi all,
> 
> sorry for coming to this discussion very late. Fwiw, I'd like to mention an element we came up with during the Freischütz project, which still lacks sufficient documentation to be implemented into general MEI – even though I strongly believe it's very useful for other projects as well. In essence, it's a more general approach to repeat symbols and other notational "shortcuts". We call it a "cpMark", where the "cp" may be read as "copy" and / or "colla parte". This element is a controlEvent (= it lives inside a measure, just like a slur or dir). In a 4/4 measure, a beatRpt on the second beat of the first staff could look like this:
> 
> <cpMark staff="2" tstamp="2" tstamp2="0m+2" ref.offset="0m+1" ref.offset2="0m+1">/</cpMark>
> 
> The attribute pair @tstamp and @tstamp2 is used to delimit the "beats" that this element will say something about – just as in any other control event. "beats" in this context is clearly the numbers of the @meter.count. Then, the attribute pair @ref.offset and @ref.offset2 is used to say from where context is to be copied into this "empty" or "abbreviated" slot. @ref.offset uses the same data type as @tstamp2, with the only difference that the first number (the one before the "m+" part) may take negative values, that is, refer to preceding measures), and @ref.offset2 uses the exact same data type as @tstamp2 (it's value is relative to the origin defined by @ref.offset). These elements may be combined or replaced by @ref.staff (and @ref.layer), which allow to do a colla parte encoding ("…for the range defined by @tstamp and @tstamp2, just copy in the stuff in @ref.staff, potentially affected by @dis for an 'in ottava'…"). The cpMark may contain textual content (plus some editorial stuff) to grab what the source says – a simple slash, a verbal instruction, whatever.
> 
> This is just a very brief introduction to this element, but I hope you get the idea. Like I said, I'm not sure if it really helps in this discussion of <beatRpt>, but I think it allows to be very explicit about the scope of a beat repetition symbol. In my understanding, <beatRpt>, <mRpt>, and all the other <*Rpt> elements are syntactic sugar for this <cpMark> element, which is really a more semantic solution for a specific type of <dir>. Would it be an option to use <cpMark> instead of <beatRpt> – just to be more explicit? I think this is more or less in line with Perry's second suggestion, or at least I believe we should coordinate the search for an additional attribute with our <cpMark> proposal.
> 
> Hth,
> jo
> 
> 
> 
> 
> 
> Am 03.09.2015 um 21:15 schrieb Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu>:
> 
> >
> > 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>:
> >
> > 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 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
> >
> >
> >
> > _______________________________________________
> > 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
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 496 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20150904/cca3587c/attachment.sig>