[MEI-L] Questions about Beaming

Thu Aug 14 09:28:01 CEST 2014

One note on the nested beams case: the Berlioz Symphony in the
encoding examples has three nested beams as described by Craig:
http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.xml

<beam>
    <note xml:id="d1e11116" pname="d" oct="5" dur="8" stem.dir="down"/>
    <beam>
        <note xml:id="d1e11132" grace="unacc" pname="e" oct="5"
dur="16" stem.dir="up"/>
        <note xml:id="d1e11149" grace="unacc" pname="d" oct="5"
dur="16" stem.dir="up"/>
    </beam>
    <note xml:id="d1e11166" pname="c" oct="5" dur="8" stem.dir="down"/>
    <note xml:id="d1e11182" pname="d" oct="5" dur="8" stem.dir="down"/>
</beam>

Best,
Laurent


On Tue, Aug 12, 2014 at 8:51 PM, Christopher Antila
<christopher at antila.ca> wrote:
> Hi Craig, Johannes, Perry, and Others:
>
>> It’s good to hear from you again. That means you haven’t given up
>> working on the MEI -> Music21 conversion.  ;-)
> Not only have I not given up, but most of the "complete examples" sample
> encodings mostly work, most of the time. Many of the failures are
> related to less-than-perfect MEI files; more on this in another email.
>
> It's filled with known bugs, and very much incomplete, but adventurous
> people can give it a try...
> https://github.com/ELVIS-Project/music21/tree/mei
>
> Simply import an MEI file as with any other music21-supported format! If
> using Python 2, you will need to install the "mock" package. It's part
> of the standard library starting with Python 3.3.
>
> ----
>
> Answer to My Question 1: Because <beam> and <beamSpan> both only specify
> primary beams, and because <beamSpan> is more flexible than <beam>, the
> importer will prefer <beamSpan> to <beam> if there is conflicting
> information. The @beam attribute will be ignored unless no other beaming
> information is available.
>
> Answer to My Question 2: Nested <beam> elements specify nested primary
> beams, which so far only makes sense for the grace note situation Craig
> mentioned. Furthermore, using nested <beam> elements to refer to
> secondary beams is not only superfluous but incorrect; the @breaksec
> attribute is the only method for this.
>
> ----
>
> As an additional note, Johannes suggested using @plist in a <beamSpan>,
> which is a strategy I endorse. Using @plist whenever possible is a good
> way to help ensure your files are imported correctly and efficiently.
>
> Johannes also suggested using a profile to limit the scope of MEI
> elements and attributes that music21 would import. Although I'm not
> attempting to support all of MEI, I hadn't thought of formalizing this
> with a profile. It's certainly something I'll consider!
>
>
> Thanks,
> Christopher
>
> On Tue, 2014-08-12 at 08:58 +0200, Johannes Kepper wrote:
>> Almost everything important has been said already. However, there are some more additions I'd like to make.
>>
>> Am 12.08.2014 um 00:15 schrieb Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu>:
>>
>> >
>> > As usual, Craig is faster at the keyboard than I.
>> >
>> > Also, it seems I forgot about the use of <beam> within <beam> as a method of dealing with beamed grace notes.  Ah, well, can’t remember everything.  <sigh/>  So, it seems the side effect is a useful one.  J
>> >
>> > As for Craig’s last 3 examples, I wouldn’t attempt to represent them in a single layer.  This kind of notation is mostly used to indicate 2 “somethings” -- either 2 “voices” from a single instrument or a single “voice” being played on 2 strings.  In either case, it’s easier to treat it/them as 2 layers.
>>
>> But if you put it on two layers, you have to add a number of <space> elements to spread to notes correctly on both layers.
>>
>> This leads to another issue I see with Perry's encoding proposal. If you use <beamSpan> (which is clearly the most powerful encoding solution), you should not rely on @startid and @endid (solely). Especially with those "blended" beam groups, it seems much better to use the @plist instead. This "participant list" points to all notes whose stems should attach to the beam(s). You're not only providing start and end points, and have to guess about what's happening in between, this way you explicitly state how things should be rendered.
>>
>> Craig's fallback proposal is an interesting one. However, if we consider this as a correct solution, I'd like to modify it slightly: The <beamSpan>'s @plist should not point to the notes (creating redundant information with the <beam>s), but instead to the <beam>s. This way, you put the hierarchy-compliant parts into <beam> elements, and then you connect these <beam> elements across XML hierarchies using the standoff <beamSpan>. This way, you get a clear separation of information, and don't have to deal with redundant (=possibly conflicting) information.
>>
>> But in general, Perry's recommendation to use one or the other is the best you can do.
>>
>> Just for completeness, there is a fourth way to encode beams.  The @beam.group attribute on <staffDef> and <scoreDef> allows to specify a default beaming behavior. Documentation is (too) scarce on this one, however. It goes back to the first efforts to render MEI with MUP, and tries to provide a way to say things like "all eighth notes shall be beamed in groups of two". However, we're missing examples in here, and we're also missing a defined data format for the values of this attribute. I'd assume that you're supposed to use the same values that MUP utilizes, but since this solution predates my involvement in MEI, I'm just guessing.
>> The @beam.group solution has other significant drawbacks, so I strongly recommend to not use it. It may be helpful for manual encoding, when your most important concern is to save some keystrokes. But there is limited capability to override it in the encoding later on. I'd say it's possible to have a <beam> in the encoding that includes more notes than the @beam.group would indicates. However, there is no <noBeam> element or similar in MEI, allowing to say that some notes are not beamed, contrary to what @beam.group would require. In that case, one would have to insert another <staffDef> (or <scoreDef>), change the default behavior by giving a different value for @beam.group, and change back to the original value after the differing section with another <staffDef>. All this doesn't look very practical to me, so I wouldn't recommend to use @beam.group _unless it's exactly the solution for your specific problem_.
>>
>> Just for curiosity, have you considered to create a profile for MEI to be used as starting point for your conversion? I think its honorable but futile to try to cover everything under the MEI sun. I would see no harm in operating only on a subset of MEI. In essence, you could say that you cover only <beam>, but not @beam (just as examples). Such a profile can be generated from the underlying ODD, resulting in both HTML documentation of your profile and an RNG schema that allows users to check if their files would go through smoothly or not.
>>
>> Best,
>> Johannes
>>
>>
>>
>>
>> >
>> > --
>> > p.
>> >
>> >
>> > From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Craig Sapp
>> > Sent: Monday, August 11, 2014 5:25 PM
>> > To: Music Encoding Initiative
>> > Subject: Re: [MEI-L] Questions about Beaming
>> >
>> > Hi Christopher,
>> >
>> > You can wait for someone else to comment more precisely, but in the meantime here are examples as points of discussion:
>> >
>> > <image002.jpg>
>> >
>> > In this case <beamSpan> is needed to represent the first beam on the bottom staff.  If there were both <beam> and <beamSpan> at the same time for this case, I would interpret this as "use the <beamSpan> directions unless the notation renderer cannot handle it (particularly Finale...), in which case fall back to the <beam> directions.
>> >
>> >
>> > The only case I have come across for nested beams would be that grace-note beams are independent of regular beams:
>> > <image003.png>
>> > In this case the beam organization would be:
>> >
>> >    <beam> grace-A, grace-B </beam>
>> >    <beam> regular-A, regular-G# <beam>grace-A, grace-B</beam>, regular-A </beam>
>> >
>> >
>> > How would the following example be encoded in MEI (from a hypothetical violin repertory, indicating string numbers via beaming)?  This might also be implemented as a single layer with nested beams:
>> >
>> > <image005.jpg>
>> >
>> > The following example would then require <beamSpan>s (or a mixture of <beamSpan>s and <beam>s):
>> >
>> >
>> > <image007.jpg>
>> > Now I am wondering how this can be encoded as in a single layer:
>> >
>> > <image009.jpg>
>> >
>> > -=+Craig
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 11 August 2014 13:23, Christopher Antila <christopher at antila.ca> wrote:
>> > Greetings MEI List Members:
>> >
>> > I have another set of questions related to importing MEI to music21!
>> >
>> > This time I'm having issues with beams, so I hope someone can help
>> > clarify the MEI Guidelines. Though it may seem like I'm splitting hairs,
>> > I'm really looking for answers to two specific questions: (1) what's the
>> > order of precedence in beam specification? And (2) what do nested <beam>
>> > elements mean?
>> >
>> > Elaboration.
>> >
>> > 1.) There are (at least?) three ways to encode beams: <beam>,
>> > <beamSpan>, and @beam. What's the order of precedence for when more than
>> > one of these are specified for the same element? My feeling is that a
>> > <beamSpan> shall be overridden by a <beam>, which shall be overridden by
>> > the @beam attribute. Why? While <beamSpan> cannot indicate a beam
>> > number, <beam> can imply a beam number, and @beam specifically requires
>> > beam numbers. Even though an "order of precedence" is probably beyond
>> > the scope of what MEI will want to specify, it would be helpful to
>> > disambiguate the different levels of specificity in the Guideliness---if
>> > indeed I'm understanding the situation properly.
>> >
>> > 2.) On the topic of the <beam> element's implied beam numbers, what do
>> > nested <beam> elements mean? To me these seem to specify the primary
>> > then secondary then tertiary, etc., beams for deeper and deeper nesting.
>> > However, the Guidelines (pg.82) say the "visual rendition of a set of
>> > beamed notes is presumed to be handled by rendering processes," which
>> > implies that secondary beaming cannot be encoded with <beam> elements.
>> > In fact, we could take this further and say that primary beams also
>> > cannot be specified with <beam> elements: the elements between <beam>
>> > tags are merely "explicitly beamed," in that they have at least one
>> > beam, but the Guidelines do not actually specify that they must share
>> > *the same* beam, since that decision is a visual one, and therefore
>> > "presumed to be handled by rendering processes." (Except, of course,
>> > when something like @breaksec will specify an aspect of the visual
>> > rendition...?)
>> >
>> > An attempted "common sense" reading of the Guidelines suggests that
>> > everything within a set of <beam> tags will share the same primary beam.
>> > Secondary beams will be specified by some built-in default, by a
>> > @beam.group attribute, or the @breaksec attribute. If this is the
>> > intended interpretation, it leaves open the question of how to handled
>> > nested <beam> elements.
>> >
>> > Thank you in advance for your feedback. As always, I would be happy to
>> > help clarify my questions if required.
>> >
>> >
>> > Christopher
>> >
>> > _______________________________________________
>> > 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
>