[MEI-L] Beat in 6/8
Laurent Pugin
lxpugin at gmail.com
Fri Sep 4 13:57:49 CEST 2015
On Fri, Sep 4, 2015 at 11:31 AM, Johannes Kepper <kepper at edirom.de> wrote:
> 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.
>
I agree this is problematic. I would expect The fact that timestamp use
decimal (and not fractions) was another issue raised in the aforementioned
discussion that would clearly cause problems here.
>
> > 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
>
>
> _______________________________________________
> 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/20150904/748ba941/attachment.html>
More information about the mei-l
mailing list