[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