<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri","sans-serif";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 113.7pt 1.0in 113.7pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Hi Christopher,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">It’s good to hear from you again. That means you haven’t given up working on the MEI -> Music21 conversion. ;-)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Precedence is not an issue for <beam> and <beamSpan>, since they operate at the same level. That is, a single beam construct shouldn't be indicated by both <beam> and <beamSpan> elements. One or the other should be used, never both.
<beam> will only work, however, when the beam doesn't cross a bar line. <beamSpan> will work in all cases.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">@beam is really an analytical mechanism and in the next release of MEI I’d like to place it in the analytical domain, meaning it can be "turned off" at will. Therefore, it must take a lower precedence than the other two for rendering
purposes. I might go so far as to say that it should never be relied on for rendering, but if it’s the only beaming indication you’ve got ...<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The fact that <beam> can contain <beam> is a side effect of the MEI class system. Since <beam> contains events, and a beam element is effectively an event, it follows that syntactically <beam> can contain <beam>. However, that kind
of markup is not likely to be very useful. (N.B. Exclusions; that is, rules specifying that <beam> can contain any event EXCEPT <beam>, were allowed in SGML but are not in XML unfortunately.)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">For overlapping beams, <beamSpan> elements should be used, for instance where a run of eighth notes has beams beginning on the first and 5th notes *and* on the 2nd and 6th notes, e.g.,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">[In case you can’t see the inline images, the examples are also attached.]<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">[beamExample.png]<o:p></o:p></p>
<p class="MsoPlainText"><img width="216" height="143" id="Picture_x0020_3" src="cid:image004.jpg@01CFB58F.56EEB8F0"><o:p></o:p></p>
<p class="MsoPlainText">(I can’t replicate the situation exactly with the Bach font, so you have to imagine the 2 lines of notes superimposed.)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">(Very abbreviated) markup for this example:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><note xml:id=”n1” dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"><note xml:id=”n2” dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"><note xml:id=”n3” dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"><note xml:id=”n4” dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"><note xml:id=”n5” dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"><note xml:id=”n6” dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"><note xml:id=”n7” dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"><note xml:id=”n8” dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText">[barLine]<o:p></o:p></p>
<p class="MsoPlainText"><note xml:id=”n9” dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><beamSpan startid=”#n1” endid=”#n4”/><o:p></o:p></p>
<p class="MsoPlainText"><beamSpan startid=”#n2” endid=”#n5”/<o:p></o:p></p>
<p class="MsoPlainText"><beamSpan startid=”#n5” endid=”#n8”/><o:p></o:p></p>
<p class="MsoPlainText"><beamSpan startid=”#n6” endid=”#n9”/><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Of course, this only occurs in special circumstances. And, of course, <beamSpan> can be used instead of <beam>. <beam> is just easier to deal with when one is creating the markup by hand.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Remember that secondary (tertiary, etc.) beams are *not* indicated in MEI by adding more <beam> elements. The following example is *INCORRECT*.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><beam><o:p></o:p></p>
<p class="MsoPlainText"> <beam><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"> </beam><o:p></o:p></p>
<p class="MsoPlainText"></beam><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">A set of beamed notes is marked up with a single <beam> element, regardless of the durations under the beam. (Maybe a better name for this element would have been <beamedGroup>, but that presented difficulties of a different nature.)
In any case, the element indicates a *set of beamed notes*, not individual beam “lines” (for want of a better term for the horizontal “bars”). In other words, in MEI 8th note groups, 16th note groups, or mixed groups all only have 1 beam element because they’re
all part of the same “beamed group”. For example,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><beam><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"></beam><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">OR<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><beam><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"></beam><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">OR EVEN<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><beam><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”8”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"></beam><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">As you say, they all share the same primary beam. And it’s the primary beam we’re most concerned about. In every case, the rendering engine can figure out how many beams to draw and where to draw them based on the note durations.
When there’s a question about where to break the secondary beam(s), the @breaksec attribute is needed. For example,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><beam><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16” breaksec=”1”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"> <note dur=”16”/><o:p></o:p></p>
<p class="MsoPlainText"></beam><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">indicates a break in the secondary beam following the 2nd note. The value of @breaksec records how many beams should remain *unbroken*, resulting in a rendering like --<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">[beamExample2.png]<o:p></o:p></p>
<p class="MsoPlainText"><img width="106" height="106" id="Picture_x0020_4" src="cid:image001.png@01CFB58A.0DECA2C0"><o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Does that help?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">--<o:p></o:p></p>
<p class="MsoPlainText">p.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> -----Original Message-----</p>
<p class="MsoPlainText">> From: mei-l [mailto:mei-l-bounces@lists.uni-paderborn.de] On Behalf Of</p>
<p class="MsoPlainText">> Christopher Antila</p>
<p class="MsoPlainText">> Sent: Monday, August 11, 2014 4:24 PM</p>
<p class="MsoPlainText">> To: Music Encoding Initiative</p>
<p class="MsoPlainText">> Subject: [MEI-L] Questions about Beaming</p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> Greetings MEI List Members:</p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> I have another set of questions related to importing MEI to music21!</p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> This time I'm having issues with beams, so I hope someone can help</p>
<p class="MsoPlainText">> clarify the MEI Guidelines. Though it may seem like I'm splitting hairs,</p>
<p class="MsoPlainText">> I'm really looking for answers to two specific questions: (1) what's the</p>
<p class="MsoPlainText">> order of precedence in beam specification? And (2) what do nested <beam></p>
<p class="MsoPlainText">> elements mean?</p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> Elaboration.</p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> 1.) There are (at least?) three ways to encode beams: <beam>,</p>
<p class="MsoPlainText">> <beamSpan>, and @beam. What's the order of precedence for when more</p>
<p class="MsoPlainText">> than</p>
<p class="MsoPlainText">> one of these are specified for the same element? My feeling is that a</p>
<p class="MsoPlainText">> <beamSpan> shall be overridden by a <beam>, which shall be overridden by</p>
<p class="MsoPlainText">> the @beam attribute. Why? While <beamSpan> cannot indicate a beam</p>
<p class="MsoPlainText">> number, <beam> can imply a beam number, and @beam specifically</p>
<p class="MsoPlainText">> requires</p>
<p class="MsoPlainText">> beam numbers. Even though an "order of precedence" is probably beyond</p>
<p class="MsoPlainText">> the scope of what MEI will want to specify, it would be helpful to</p>
<p class="MsoPlainText">> disambiguate the different levels of specificity in the Guideliness---if</p>
<p class="MsoPlainText">> indeed I'm understanding the situation properly.</p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> 2.) On the topic of the <beam> element's implied beam numbers, what do</p>
<p class="MsoPlainText">> nested <beam> elements mean? To me these seem to specify the primary</p>
<p class="MsoPlainText">> then secondary then tertiary, etc., beams for deeper and deeper nesting.</p>
<p class="MsoPlainText">> However, the Guidelines (pg.82) say the "visual rendition of a set of</p>
<p class="MsoPlainText">> beamed notes is presumed to be handled by rendering processes," which</p>
<p class="MsoPlainText">> implies that secondary beaming cannot be encoded with <beam> elements.</p>
<p class="MsoPlainText">> In fact, we could take this further and say that primary beams also</p>
<p class="MsoPlainText">> cannot be specified with <beam> elements: the elements between <beam></p>
<p class="MsoPlainText">> tags are merely "explicitly beamed," in that they have at least one</p>
<p class="MsoPlainText">> beam, but the Guidelines do not actually specify that they must share</p>
<p class="MsoPlainText">> *the same* beam, since that decision is a visual one, and therefore</p>
<p class="MsoPlainText">> "presumed to be handled by rendering processes." (Except, of course,</p>
<p class="MsoPlainText">> when something like @breaksec will specify an aspect of the visual</p>
<p class="MsoPlainText">> rendition...?)</p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> An attempted "common sense" reading of the Guidelines suggests that</p>
<p class="MsoPlainText">> everything within a set of <beam> tags will share the same primary beam.</p>
<p class="MsoPlainText">> Secondary beams will be specified by some built-in default, by a</p>
<p class="MsoPlainText">> @beam.group attribute, or the @breaksec attribute. If this is the</p>
<p class="MsoPlainText">> intended interpretation, it leaves open the question of how to handled</p>
<p class="MsoPlainText">> nested <beam> elements.</p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> Thank you in advance for your feedback. As always, I would be happy to</p>
<p class="MsoPlainText">> help clarify my questions if required.</p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> </p>
<p class="MsoPlainText">> Christopher</p>
</div>
</body>
</html>