[MEI-L] Questions about Beaming

[Christopher Antila]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140811/62a59af7/attachment.sig>