[MEI-L] Questions about Beaming

Tue Aug 12 00:15:19 CEST 2014

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.  ☺

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.

--
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:

[cid:image002.jpg at 01CFB58F.E7C1EAF0]

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:
[cid:image003.png at 01CFB58F.E7C1EAF0]
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:

[cid:image005.jpg at 01CFB58F.E7C1EAF0]

The following example would then require <beamSpan>s (or a mixture of <beamSpan>s and <beam>s):

[cid:image007.jpg at 01CFB58F.E7C1EAF0]
Now I am wondering how this can be encoded as in a single layer:

[cid:image009.jpg at 01CFB58F.E7C1EAF0]

-=+Craig

On 11 August 2014 13:23, Christopher Antila <christopher at antila.ca<mailto: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<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/20140811/094a200b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 15854 bytes
Desc: image002.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/094a200b/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 12446 bytes
Desc: image003.png
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/094a200b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 10719 bytes
Desc: image005.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/094a200b/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.jpg
Type: image/jpeg
Size: 10917 bytes
Desc: image007.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/094a200b/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.jpg
Type: image/jpeg
Size: 10715 bytes
Desc: image009.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/094a200b/attachment-0003.jpg>