<div dir="ltr">Hi Christopher,<div><br></div><div>You can wait for someone else to comment more precisely, but in the meantime here are examples as points of discussion:</div><div><br></div><div><div><img src="cid:ii_hyq9vpms1_147c6d446865f53c" width="562" height="147"><br>
</div><br></div><div>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.</div>
<div><br></div><div><br></div><div>The only case I have come across for nested beams would be that grace-note beams are independent of regular beams:</div><div><div><img src="cid:ii_hyqa72en2_147c6dc5bcac3339" width="382" height="170"><br>
</div>In this case the beam organization would be:<br></div><div> </div><div> <beam> grace-A, grace-B </beam></div><div> <beam> regular-A, regular-G# <beam>grace-A, grace-B</beam>, regular-A </beam></div>
<div><br></div><div><br></div><div>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:</div>
<div><br></div><div><div><img src="cid:ii_hyqanfl53_147c6e8036652ff1" width="562" height="110"><br></div><div><br></div>The following example would then require <beamSpan>s (or a mixture of <beamSpan>s and <beam>s):</div>
<div><br></div><div><div><img src="cid:ii_hyqawpq54_147c6ee9d0bcca42" width="562" height="127"><br></div>Now I am wondering how this can be encoded as in a single layer:<br></div><div><br></div><div><div><img src="cid:ii_hyqb22dl5_147c6f26c103364c" width="562" height="115"><br>
</div><br></div><div>-=+Craig</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 11 August 2014 13:23, Christopher Antila <span dir="ltr"><<a href="mailto:christopher@antila.ca" target="_blank">christopher@antila.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings MEI List Members:<br>
<br>
I have another set of questions related to importing MEI to music21!<br>
<br>
This time I'm having issues with beams, so I hope someone can help<br>
clarify the MEI Guidelines. Though it may seem like I'm splitting hairs,<br>
I'm really looking for answers to two specific questions: (1) what's the<br>
order of precedence in beam specification? And (2) what do nested <beam><br>
elements mean?<br>
<br>
Elaboration.<br>
<br>
1.) There are (at least?) three ways to encode beams: <beam>,<br>
<beamSpan>, and @beam. What's the order of precedence for when more than<br>
one of these are specified for the same element? My feeling is that a<br>
<beamSpan> shall be overridden by a <beam>, which shall be overridden by<br>
the @beam attribute. Why? While <beamSpan> cannot indicate a beam<br>
number, <beam> can imply a beam number, and @beam specifically requires<br>
beam numbers. Even though an "order of precedence" is probably beyond<br>
the scope of what MEI will want to specify, it would be helpful to<br>
disambiguate the different levels of specificity in the Guideliness---if<br>
indeed I'm understanding the situation properly.<br>
<br>
2.) On the topic of the <beam> element's implied beam numbers, what do<br>
nested <beam> elements mean? To me these seem to specify the primary<br>
then secondary then tertiary, etc., beams for deeper and deeper nesting.<br>
However, the Guidelines (pg.82) say the "visual rendition of a set of<br>
beamed notes is presumed to be handled by rendering processes," which<br>
implies that secondary beaming cannot be encoded with <beam> elements.<br>
In fact, we could take this further and say that primary beams also<br>
cannot be specified with <beam> elements: the elements between <beam><br>
tags are merely "explicitly beamed," in that they have at least one<br>
beam, but the Guidelines do not actually specify that they must share<br>
*the same* beam, since that decision is a visual one, and therefore<br>
"presumed to be handled by rendering processes." (Except, of course,<br>
when something like @breaksec will specify an aspect of the visual<br>
rendition...?)<br>
<br>
An attempted "common sense" reading of the Guidelines suggests that<br>
everything within a set of <beam> tags will share the same primary beam.<br>
Secondary beams will be specified by some built-in default, by a<br>
@beam.group attribute, or the @breaksec attribute. If this is the<br>
intended interpretation, it leaves open the question of how to handled<br>
nested <beam> elements.<br>
<br>
Thank you in advance for your feedback. As always, I would be happy to<br>
help clarify my questions if required.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Christopher<br>
</font></span><br>_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br></blockquote></div><br></div>