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

Roland, Perry (pdr4h) pdr4h at eservices.virginia.edu
Tue Dec 17 00:43:05 CET 2013


Hi Raf,



There already is a way to indicate if barlines are drawn continuously between staves -- the @barthru attribute on <staffGrp>.  But that's unimportant with regard to your main point, I believe.



The connecting line does indicate "some kind of grouping", but the issue is that sometimes we need to record two properties of the outermost group -- whether there's a connecting line and the brace, bracket, etc. used.  Obviously, this can't be done with a single attribute.



One solution is to expand the hierarchy, placing @symbol="line" on the outer group, and @symbol="bracket" on the inner one.  But this is overly complex.  I think a better solution is to provide a new attribute for indicating the presence of the connecting line.  Reduced complexity makes this new approach more likely to be used and processed correctly.



Having decided we need another attribute, where do we put it?  We could allow it on <staffGrp> also, but without a schematron rule to limit its use to only the outer group, syntactically it can occur on any staff group, which could lead to confusion again.  A different approach is to allow it to occur on the parent of the outer <staffGrp>; that is, on <scoreDef>, as I explained in my previous message.  If it is placed on <scoreDef>, then it is an optional visual property of the score that gets inherited by the outermost staff group.



No matter where the presence of the connecting line is recorded, it's still a visual property of the outermost staff group.



--

p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com]
Sent: Monday, December 16, 2013 5:14 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc.

Let's assume that we add the extra attribute on scoreDef to specify the presence/absence of this line. Shouldn't we then think of a way to specify whether barlines are drawn continuously between staves or not? Or whether stems are extended through beams or not (e.g. French beams)?

I still think that if the line means some sort of grouping (or if the encoder thinks so), let there be an extra staffGrp. If it's only a convention / editing house style, then it shouldn't matter for MEI, like French beams don't matter at the moment. Though someone may want to study the evolution of beam typesetting in Alsace-Lorraine and whether local musicians switched between French and German style... I'm making things up just to point out that any mark on the page is not "semantic" until we decide it is.

Raf


On Mon, Dec 16, 2013 at 4:28 PM, Andrew Hankinson <andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>> wrote:
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<mailto: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<tel:434-982-2702> (w)
> pdr4h (at) virginia (dot) edu
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l


_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131216/038a1437/attachment.html>


More information about the mei-l mailing list