<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
Hi Zoltan,
<div><br>
</div>
<div>There is no limit to the number of nested staff groups. However, if you have more than four nested staff groups, each with its own bracket style, your engraver should be fired! :)</div>
<div><br>
</div>
<div>@symbol is simply meant to indicate that there is a “generic” bracket, brace, or line present. This is to give a visual hint, but not a visual definition, to any software parsing the MEI file. Do you have any examples of connecting symbols that are not
one of these? (Beyond those previously discussed by Laurent?)</div>
<div><br>
</div>
<div>-Andrew</div>
<div><br>
</div>
<div>On Dec 12, 2013, at 4:30 AM, Kőmíves Zoltán <<a href="mailto:zolaemil@gmail.com">zolaemil@gmail.com</a>> wrote:</div>
<div>
<div><br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Hi Perry,
<div><br>
</div>
<div>It makes sense to separately encode the visual characteristics in a child element, such as <grpSym>. Forgive me for my ignorance about the existence of this element!</div>
<div><br>
</div>
<div>However, I contemplate the problem of having too few values for @symbol.</div>
<div><br>
</div>
<div>Consider the following statement: "there are N different symbols used in the score that connect groups of staves". How would you encode the staff groups if N>=4?</div>
<div><br>
</div>
<div>Thanks</div>
<div>Zoltan</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/12/11 Roland, Perry (pdr4h) <span dir="ltr"><<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="WORD-WRAP:break-word">
<div style="direction:ltr;font-size:12pt;font-family:Arial Unicode MS">
<p>Hi Zoltan,</p>
<div> <br class="webkit-block-placeholder">
</div>
<p>Some elements (but not <staffGrp>) already allow @altsym, which contains a pointer to a <symbolDef> element that, in turn, contains instructions on how to "draw" the symbol. This area of the schema has not been exercised much and could therefore use a lot
of work. However, I think <symbolDef> could be extended to contain SVG, PostScript, etc.</p>
<div> <br class="webkit-block-placeholder">
</div>
<p>Turning to how this would work with <staffGrp>, the @altsym attribute doesn't actually belong on <staffGrp>. It's the visual characteristics of <grpSym> we're trying to capture, not those of <staffGrp>. I believe this is what Andrew's comment was intended
to mean. So, instead of <staffGrp>, <grpSym>, which can be a child of <staffGrp>, should bear @altsym, e.g.,</p>
<div> <br class="webkit-block-placeholder">
</div>
<p><staffGrp xml:id="P2" label="Piano" barthru="true"></p>
<p> <grpSym symbol="brace" altsym="#myBrace"/></p>
<p> <staffDef ...</p>
<p></staffGrp></p>
<div> <br class="webkit-block-placeholder">
</div>
<p>Although sometimes it can't be avoided, it's generally bad practice to use attributes to describe other attributes. The usual way to handle this is to "promote" an attribute to element status and then give it its own attributes. That's what <grpSym> is
doing.</p>
<div> <br class="webkit-block-placeholder">
</div>
<p>The <grpSym> element, however, still has the @symbol attribute with the same values as when it's used on <staffGrp>. In effect,
</p>
<div> <br class="webkit-block-placeholder">
</div>
<p><staffGrp symbol="brace"></p>
<div> <br class="webkit-block-placeholder">
</div>
<p>is short-hand for</p>
<div> <br class="webkit-block-placeholder">
</div>
<p><staffGrp><grpSym symbol="brace"/>.</p>
<div> <br class="webkit-block-placeholder">
</div>
<p>In other words, as in several places in MEI, it's possible to use attributes for less-detail-oriented encodings (for example, when you don't care what the brace looks like), but use elements when you do.</p>
<div class="im">
<div> <br class="webkit-block-placeholder">
</div>
<p>--</p>
<p>p.</p>
<div>
<div><font>
<div><br>
__________________________<br>
Perry Roland<br>
Music Library</div>
<div>University of Virginia</div>
<div>P. O. Box 400175</div>
<div>Charlottesville, VA 22904<br>
<a href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a> (w)<br>
pdr4h (at) virginia (dot) edu</div>
</font></div>
</div>
</div>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="DIRECTION:ltr"><font face="Tahoma"><b>From:</b> mei-l [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a>] on behalf of Zoltán Kőmíves [<a href="mailto:zolaemil@gmail.com" target="_blank">zolaemil@gmail.com</a>]<br>
<b>Sent:</b> Wednesday, December 11, 2013 5:10 PM
<div>
<div class="h5"><br>
<b>To:</b> Music Encoding Initiative<br>
<b>Subject:</b> Re: [MEI-L] Thin brackets in orchestral scores<br>
</div>
</div>
</font><br>
</div>
<div>
<div class="h5">
<div></div>
<div>
<div>
<div style="FONT-FAMILY:Calibri,sans-serif;FONT-SIZE:11pt">Hi Andrew, <br>
<br>
The grouping of staves is captured by the staffGrp elements without specifying @symbol. @symbol captures additional information. I talk about this additional content.<br>
<br>
Zoltan</div>
</div>
<div dir="ltr">
<hr>
<span style="FONT-FAMILY:Calibri,sans-serif;FONT-SIZE:11pt;FONT-WEIGHT:bold">From:
</span><span style="FONT-FAMILY:Calibri,sans-serif;FONT-SIZE:11pt"><a href="mailto:andrew.hankinson@mail.mcgill.ca" target="_blank">Andrew Hankinson</a></span><br>
<span style="FONT-FAMILY:Calibri,sans-serif;FONT-SIZE:11pt;FONT-WEIGHT:bold">Sent:
</span><span style="FONT-FAMILY:Calibri,sans-serif;FONT-SIZE:11pt">2013.12.11. 20:45</span><br>
<span style="FONT-FAMILY:Calibri,sans-serif;FONT-SIZE:11pt;FONT-WEIGHT:bold">To: </span>
<span style="FONT-FAMILY:Calibri,sans-serif;FONT-SIZE:11pt"><a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">Music Encoding Initiative</a></span><br>
<span style="FONT-FAMILY:Calibri,sans-serif;FONT-SIZE:11pt;FONT-WEIGHT:bold">Subject:
</span><span style="FONT-FAMILY:Calibri,sans-serif;FONT-SIZE:11pt">Re: [MEI-L] Thin brackets in orchestral scores</span><br>
<br>
</div>
<div>The intellectual content (“logical domain”) is the groups of staves, not the symbol.</div>
<div><br>
</div>
<div>
<div>
<div>On Dec 11, 2013, at 2:06 PM, Kőmíves Zoltán <<a href="mailto:zolaemil@gmail.com" target="_blank">zolaemil@gmail.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">Hello,
<div><br>
</div>
<div>Would you mind to read my crazy thoughts about this issue? I'm just curious what you people think of my thinking. </div>
<div><br>
</div>
<div>I think the "intellectual content" in this case isn't so much how the connecting symbols look, but the fact that the symbols are *different*. </div>
<div><br>
</div>
<div>The current values of @symbol already bear some sort of graphical information, I think. The problem arose now, because it seems that the current set of values don't provide a *complete" classification (that is, in some cases there's no value which describes
the symbol's graphical shape appropriately). But of course, it's impossible to provide a complete classification without degrading the markup to SVG.</div>
<div><br>
</div>
<div>If we accept that the intellectual content is the *difference* between the connecting symbols, then the proper separation of the "intellectual content" from it's graphical representation would be to use a set of values something like this:</div>
<div><br>
</div>
<div>
<div>"symbol1",</div>
<div>"symbol2",</div>
<div>"symbol3", </div>
<div>etc.</div>
</div>
<div><br>
</div>
<div>If one wanted to capture more info about their "look and feel", one could use some pointing mechanism to point to a different element that records the graphical info (possibly even pointing to an external SVG...)</div>
<div><br>
</div>
<div>I know, it's a crazy abstraction. And it may be way too abstract compared to its practical use, and we could be better off adding a handful of carefully defined values.</div>
<div><br>
</div>
<div>Zoltan</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/12/11 Laurent Pugin <span dir="ltr"><<a href="mailto:laurent@music.mcgill.ca" target="_blank">laurent@music.mcgill.ca</a>></span><br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div dir="ltr">It seems to me that adding "<span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">bracketsq" as a possible value would be an appropriate addition. I don't think this particular case should necessary open up a discussion on what is just typesetting
or not.</span>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px"><br>
</span></div>
<div><span style="FONT-FAMILY:arial,sans-serif;FONT-SIZE:13px">Laurent</span></div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) <span dir="ltr">
<<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
Yes, caution is advised.
<div><br>
<div><br>
--<br>
p.<br>
<br>
<br>
__________________________<br>
Perry Roland<br>
Music Library<br>
University of Virginia<br>
P. O. Box 400175<br>
Charlottesville, VA 22904<br>
<a href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a> (w)<br>
pdr4h (at) virginia (dot) edu<br>
________________________________________<br>
</div>
</div>
From: mei-l [mei-l-bounces+pdr4h=<a href="mailto:virginia.edu@lists.uni-paderborn.de" target="_blank">virginia.edu@lists.uni-paderborn.de</a>] on behalf of Johannes Kepper [<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a>]<br>
Sent: Wednesday, December 11, 2013 10:02 AM
<div>
<div><br>
<div>To: Music Encoding Initiative<br>
Subject: Re: [MEI-L] Thin brackets in orchestral scores<br>
<br>
While there is certainly no harm in adding a well-defined set of additional attribute values, the risk I see is that the distinction between these values gets harder every time, eventually watering down their expressiveness in terms of interchange. I'm not
saying we're reaching that point here, I'm just saying that we should be careful…<br>
<br>
<br>
<br>
Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) <<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>>:<br>
<br>
> The "land of music typesetting" is always nearby, not unlike a 4th dimension hovering around us and within us. :-) Intellectual content and presentation are always difficult to separate. But try we must.<br>
><br>
> There are already issues in the tracker related to @symbol -- nos. 180 & 182.<br>
><br>
> From issue #180 -- "The top and bottom components of a bracket can be rendered as curved (similar to Unicode #x1D115) or straight (similar to Unicode #x0005B). The simplest method of dealing with this distinction is to add "bracketsq" (bracket square) to
the values allowed by @symbol. "bracket" will continue to be used for the usual, curved musical bracket. The documentation should be edited to make the distinction clear."<br>
><br>
> I won't attempt to reproduce #182 here, but it covers the selection of a value for @symbol that captures a line (often fairly wide) used to group systems instead of a brace or bracket. There's an image in #182 that illustrates various grouping symbols.<br>
><br>
> Neither the so-called square bracket nor the wide-line-grouping-symbol can be encoded using @symbol="line" since that value is already reserved for the line connecting the staves at their left edge. I'm partial to the value "rule", but I'm open to suggestions.<br>
><br>
> I see no harm in adding generic values like this to MEI because they are what I like to call "rendering hints" for the intellectual content -- in this case the staff group. But obviously this mechanism is not optimal for capturing all the visual details
of the symbol, such as line width, color, position, etc. I am somewhat trepidatious about going too far down that road, at the end of which MEI becomes a re-definition of SVG. :-)<br>
><br>
> Yes, there are still things to add to MEI. And, yes, this is an opportunity to do so. Now, if there were only more hours in the day ...<br>
><br>
> --<br>
> p.<br>
><br>
> __________________________<br>
> Perry Roland<br>
> Music Library<br>
> University of Virginia<br>
> P. O. Box 400175<br>
> Charlottesville, VA 22904<br>
> <a href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a> (w)<br>
> pdr4h (at) virginia (dot) edu<br>
> ________________________________________<br>
> From: mei-l [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a>] on behalf of Johannes Kepper [<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a>]<br>
> Sent: Wednesday, December 11, 2013 8:47 AM<br>
> To: Music Encoding Initiative<br>
> Subject: Re: [MEI-L] Thin brackets in orchestral scores<br>
><br>
> The reason why I feel slightly uneasy with this all is that it seems that we seem to enter the land of a music typesetting program here. In my ignorance about such details, I would probably encode that as a line, and ignore the fact that it is connected on
both ends. In manuscripts, there would probably be no difference between this and either brackets or lines. But maybe you're right, and we should include the additional value. @Perry, do I remember correctly that you spotted some values in MusicXML not currently
supported by MEI anyway? Is this an opportunity to revise them?<br>
><br>
> jo<br>
><br>
><br>
><br>
> Am 11.12.2013 um 14:39 schrieb Laurent Pugin <<a href="mailto:laurent@music.mcgill.ca" target="_blank">laurent@music.mcgill.ca</a>>:<br>
><br>
</div>
<div>>> You are right, I think it is missing.<br>
>><br>
>> There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding)<br>
>> <a href="http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf" target="_blank">
http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf</a><br>
>><br>
>> Laurent<br>
>><br>
>><br>
>><br>
>> On Wed, Dec 11, 2013 at 1:21 PM, TW <<a href="mailto:zupftom@googlemail.com" target="_blank">zupftom@googlemail.com</a>> wrote:<br>
>> Laurent's post made me wonder whether we might be missing an<br>
>> additional value for staffGrp/@symbol for the thin bracket that is<br>
>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in<br>
>> the sample collection I didn't see anything like that (I didn't look<br>
>> through all of them).<br>
>><br>
>> Thomas<br>
>><br>
>><br>
>> [1] see e.g. <a href="http://notengrafik.com/pdf/examples/Tchaikovsky.pdf" target="_blank">
http://notengrafik.com/pdf/examples/Tchaikovsky.pdf</a><br>
>><br>
>> _______________________________________________<br>
>> mei-l mailing list<br>
>> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">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>
>><br>
>> _______________________________________________<br>
>> mei-l mailing list<br>
>> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">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>
</div>
<div>> Dr. Johannes Kepper<br>
> BMBF-Projekt "Freischütz Digital"<br>
><br>
> Musikwiss. Seminar Detmold / Paderborn<br>
> Gartenstraße 20<br>
> 32756 Detmold<br>
><br>
> Tel. <a href="tel:%2B49%205231%20975669" value="+495231975669" target="_blank">
+49 5231 975669</a><br>
> Mail: <a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a><br>
</div>
<div>> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">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>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">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>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">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>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<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>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l<br>
</blockquote>
</div>
<br>
</div>
</body>
</html>