[MEI-L] Questions about Beaming

[Craig Sapp]

Hi Christopher,

You can wait for someone else to comment more precisely, but in the
meantime here are examples as points of discussion:


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

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



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

​

​Now I am wondering how this can be encoded as in a single layer:


​
-=+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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/7245dc34/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-08-11 at 1.54.24 PM.png
Type: image/png
Size: 12446 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/7245dc34/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-08-11 at 2.20.48 PM.png
Type: image/png
Size: 19836 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/7245dc34/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-08-11 at 1.47.18 PM.png
Type: image/png
Size: 52795 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/7245dc34/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-08-11 at 2.16.59 PM.png
Type: image/png
Size: 16304 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/7245dc34/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-08-11 at 2.09.35 PM.png
Type: image/png
Size: 16166 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/7245dc34/attachment-0004.png>