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

Roland, Perry (pdr4h) pdr4h at eservices.virginia.edu
Tue Dec 17 06:35:07 CET 2013

Hi Eleanor & Andrew,

In addition to @barthru, there are other attributes that contribute to the specification of bar lines -- @barplace and @taktplace.  These attributes work together (they sort of "cascade") to fully describe the various combinations of bar line properties.

@barplace takes the values "staff", "mensur", and "takt".  This attribute determines the general placement of bar lines.  There's no explicit default, but CMN assumes the "staff" value.  That is, bar lines are drawn across the staves.  More about this in a moment.

A value of "mensur" (abbreviation of "Mensurstriche") indicates that the bar lines are drawn *between the staves*; that is, as Eleanor described, from the bottom line of one staff to the top line of the one below.  For example, a system of 4 staves will have bar lines between staves 1 and 2, between staves 2 and 3, and between staves 3 and 4.  Currently, these attributes are available only on <scoreDef>, <measure>, and <barLine>.  So, there's no method for specifying mensuration bar lines for a subset of adjacent staves.  However, I think this can be accomplished by allowing @barplace and @taktplace on<staffGrp>.  An argument could even be made that they should be moved from <scoreDef> to <staffGrp>.

As you might expect, @taktplace is only useful when @barplace = 'takt'.  @taktplace takes a value between 0 and 2 times the number of staff lines.  On a 5-line staff, the value '1' indicates a "tick mark" through the bottom line, '9' a mark through the top line.

Typically, the so-called "takt" bar line is drawn at the same place for each measure and in all the staves, but when it's not, @barline can be explicitly set on each <measure> or <barLine> element.  I'll skip the detailed explanation of the use of <barLine> for now, but it should be used in mensural notation (instead of <measure>), even if the bar lines "line up" across all the staves.

Returning to CMN, @barthru  assumes a value of 'staff' for @barplace and adds information about which staves are crossed by the bar lines.  Any other value of @barplace makes @barthru meaningless.  Said the other way around, @barthru precludes any value for @barplace except 'staff', so @barplace isn't necessary in the presence of @barthru.  That's why I haven't mentioned it before in the discussion of CMN bar lines and staff groups.

Since they can occur on <measure> and <barLine>, these attributes are independent of the initial connecting line and grouping symbol given on <scoreDef>, so it's possible to group a set of 4 staves, record that there is an initial connecting line and brace, and still indicate Mensurstriche bar lines for the remainder of the notation -- 

<scoreDef barplace="mensur">
  <staffGrp symbol="bracket" initialline="true">
    <staffDef n="1" clef.shape="G" clef.line="2"/>
    <staffDef n="2" clef.shape="G" clef.line="2"/>
    <staffDef n="3" clef.shape="G" clef.line="2"/>
    <staffDef n="4" clef.shape="F" clef.line="4"/>

Sorry for the long-winded response, but I thought some folks here might want the (more or less) complete picture.

12:30am, must ... sleep ... now,


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 Andrew Hankinson [andrew.hankinson at mail.mcgill.ca]
Sent: Monday, December 16, 2013 8:29 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] thru barlines [WAS: bracketing]

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.


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

mei-l mailing list
mei-l at lists.uni-paderborn.de

More information about the mei-l mailing list