[MEI-L] ...brackets in orchestral scores: Finale shapes, etc.

Andrew Hankinson andrew.hankinson at mail.mcgill.ca
Mon Dec 16 22:28:20 CET 2013

Two clarifying questions:

1) You wouldn’t be talking about eliminating all nested <staffGrp />, would you?
2) Why would you bump this up to <scoreDef />? How would that eliminate the need for schematron rules? (Keeping the symbol on <staffGrp /> seems a bit more explicit to me.)

For reference, Sibelius refers to the first line as the “Initial barline”, not as a grouping symbol. You can en/disable showing this, but interestingly disabling the initial barline also hides any brackets associated with the group. If you re-enable the barline, it will show the bracket or brace.

On Dec 16, 2013, at 10:09 AM, Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu> wrote:

> Thinking about Laurent's original question a little more, I've come to realize that my original thinking on staff grouping was, well, misguided.
> I now think that instead of reserving @symbol="line" for the left-hand, staff-connecting line, another attribute should be added to <staffGrp> (or even on <scoreDef>) to capture the presence of this line.  This eliminates the need for nested <staffGrp> elements as well as the need to change any existing software.
> This new attribute (I'm still casting about for a name) should take a value of true or false depending on the presence/absence of the connecting line.  Of course, this attribute can only make sense when it's on the outermost <staffGrp>.  This is a good argument for pushing it up a level to <scoreDef>.  Doing that eliminates the need for schematron rules or reliance on convention to enforce good practice.
> The existing @symbol attribute with a value of "line" can be used (as in MusicXML) to describe the presence of a wide line used as the grouping symbol.  Of course, the Guidelines will need to be changed to reflect these changes.
> I'm aware that changes like this, that is, keeping the same markup but changing its meaning, are dangerous.  But sometimes it's the simplest, and indeed the best, solution.
> Humbly,
> --
> p.
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

More information about the mei-l mailing list