[MEI-L] thru barlines [WAS: bracketing]

[Andrew Hankinson]

Hi Eleanor,

Both the scoreDef and staffGrp elements can have the “@barthru” attribute, which can be true or false. This is meant to encode whether the bar line continues vertically through the group (through the inter-staff area) or not.

I’m not entirely sure how this would be interpreted in the second case you mention, however. I have also seen bar lines that only fall between the inter-staff space, not through the staves themselves, but I’m not sure how we would encode that.

If there’s no satisfactory method, we can create an issue on Google Code and make the changes to the schema.

Thanks!
-Andrew

On Dec 16, 2013, at 8:15 PM, Eleanor Selfridge-Field <esfield at stanford.edu> wrote:

> Thinking about Perry's latest view prompts me to ask a question that may
> be redundant.  In our typesetting we assume a relationship between these
> much discussed staff groups and the implications for barring throughout a
> score.  Some vertical lines in staff groups are continuous from top to
> bottom of a system, but some (especially for things like obbligato
> instruments or a chorus in a mainly orchestral work) may not be.  Do these
> various nesting schemes have any "generative" implications for how to
> coding continues?  
> 
> Barring systems vary somewhat by publisher and national tradition.  Some
> publishers do not continue what I'll call "measure bars" (running unbroken
> from top to bottom of a system) across all systems, but the ways in which
> they are broken up is somewhat variable and may depend also on the complex
> of instruments/voices in force.
> 
> Then there are Mensurstriche (editions of Renaissance music), where the
> barlines never cross a clef but instead run from the bottom line of one
> clef to the top line of one underneath.  This is not usually detectable
> from the presentation of the initial staff group.
> 
> I realize that all these points fall outside the emphasis on source
> description, but they are real and frequent issues in getting from most
> encoding systems to something useable.  On the other hand, anyone using
> MEI to make a new edition may be guided by publishers' requirements
> irrespective of the source coding.
> 
> Eleanor
> 
> 
> 
> 
> Eleanor Selfridge-Field
> Consulting Professor, Music (and, by courtesy, Symbolic Systems)
> Braun Music Center #129
> Stanford University
> Stanford, CA 94305-3076, USA
> http://www.stanford.edu/~esfield/  +1/ 650 725-9242
> 
> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
> Roland, Perry (pdr4h)
> Sent: Monday, December 16, 2013 7:09 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc.
> 
> 
> 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
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l