[MEI-L] thin [& other] brackets [& braces] in orchestral scores

[Byrd, Donald A.]

First, I should revise my claim earlier today that the only possible 
shapes are square brackets, (curly) braces, and a single line to 
include squarish brackets with flared ends. (The "curly" for braces can 
be omitted; I believe braces are curly by definition.) And yes, some 
square brackets are thinner than others :-) .

I just looked thru a bunch of orchestral scores on my shelf -- Bach, 
Beethoven, Berg, Berlioz, Debussy, Elgar, Haydn, Hindemith, Mahler, 
Mendelssohn, Mozart, Rimsky-Korsakov, Schoenberg, Schumann, Stravinsky, 
and Tchaikovsky. I also checked Elaine Gould's _Behind Bars_, which 
claims -- probably justifiably -- to be "the definitive guide to music 
notation". I've always thought that the differences in shapes are 
purely a matter of style and carry no information whatever; both the 
scores I looked at and what Gould says support that. Though there_are_ 
standard practices -- e.g., if a single instrument has multiple staves, 
they're generally connected with a brace, and never with a square 
bracket. Braces _may_ be used to group, e.g., 1st and 2nd violins, but 
square brackets (perhaps with flared ends, perhaps thin) are preferred 
nowadays.

--DAB


On Thu, 12 Dec 2013 22:19:47 +0100, Laurent Pugin 
<laurent at music.mcgill.ca> wrote:

> Hi Raffaele,
>
> I agree we should keep the list of options as short as possible, and I
> don't think there is any intention here to extend it widely. The line
> between what has a different function and what it "just" representation in
> music notation is always difficulty to draw ;-) I am not sure there is a
> deep functional difference between brace and bracket, but I might be wrong.
>
> Laurent
>
>
> On Thu, Dec 12, 2013 at 9:21 PM, Roland, Perry (pdr4h) <
> pdr4h at eservices.virginia.edu> wrote:
>
>>  Hi Raffaele,
>>
>>
>> > Example
>> > MEI: these staves are grouped. This group has and id "grp1"
>> > Other system: the class "stave brackets" has to be rendered according to
>> this routine. Apply
>> > it to MEI element #grp1. Also, #grp1 is a special case, so tweak this
>> parameter a bit.
>> > I feel strongly that MEI ought to be fully agnostic of the "other
>> system" in the example.
>>
>> I agree with you.  In so far as it's practical, MEI should remain agnostic
>> about many things.  However, as yet there is nothing like CSS for music
>> notation, so we're left to deal with a wide range of so-called "other
>> systems" for rendition.  I regard the attribute values we've been
>> discussing as parameters to those other systems.  This is why I refer to
>> them as "hints".
>>
>> I don't think, however, we can ignore those cases where the encoder has a
>> very definite symbol in mind and wishes to provide an exemplar, e.g., in
>> the case of so-called "non-standard" symbols.  We should also keep in mind
>> the possibility of MEI functioning as an intermediate representation
>> *between systems* at a level beyond "there's a bracket here, draw one of
>> your choosing". While, as Zoltan said, MEI != SVG, I believe there are
>> cases where the possibility of passing a precise rendition to a down-stream
>> application would be very useful.  The combination of @altsym and
>> <symbolDef> provides for these cases.
>>
>> Since it aims to standardize the musical symbol repertoire, I believe a
>> SMuFL codepoint could be appropriate content of <symbolDef>, similar to the
>> way Unicode codepoints can be referenced by TEI <char> elements.  SVG,
>> PostScript, or other graphic description languages could also be
>> appropriate content.
>>
>> I don't characterize this as "degrading MEI to SVG" (one of my new
>> favorite phrases), but rather as practical employment of existing
>> standards.  I also don't think it diminishes MEI's level of/commitment
>> to agnosticism.
>>
>> --
>> 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:* Thursday, December 12, 2013 2:22 PM
>>
>> *To:* Music Encoding Initiative
>> *Subject:* Re: [MEI-L] Thin brackets in orchestral scores
>>
>>    On Thu, Dec 12, 2013 at 2:10 PM, Roland, Perry (pdr4h) <
>> pdr4h at eservices.virginia.edu> wrote:
>>>
>>>
>>> So, recording those details necessitates a <grpSym> child of <staffGrp>
>>> with its own attributes.  Those attributes can then be used to describe the
>>> symbol in greater detail or point to a precise rendition stored elsewhere.
>>>
>>
>>  I would keep the options as limited as possible. Micah is right: we
>> should introduce a new symbol only if it translates to a different
>> function, otherwise MEI should not bother: we are not doing typesetting
>> (even while we acknowledge it as a 4th, hovering, dimension).
>>
>>  Wouldn't it be best having other standards pointing at a semantic MEI
>> elements to provide a rendition, rather than adding a pointing mechanisms
>> from MEI?
>>
>>  Example
>> MEI: these staves are grouped. This group has and id "grp1"
>> Other system: the class "stave brackets" has to be rendered according to
>> this routine. Apply it to MEI element #grp1. Also, #grp1 is a special case,
>> so tweak this parameter a bit.
>>
>>  I feel strongly that MEI ought to be fully agnostic of the "other
>> system" in the example.
>>
>>  Raf
>>
>>
>>
>>>
>>> --
>>> 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 Byrd,
>>>  Donald A. [donbyrd at indiana.edu]
>>> Sent: Thursday, December 12, 2013 1:21 PM
>>> To: mei-l at lists.uni-paderborn.de
>>>  Subject: Re: [MEI-L] Thin brackets in orchestral scores
>>>
>>> Leaving aside nesting and details like thinness, as far as I know, the
>>> _only_ symbols ever used to connect staves or groups of staves in CWMN
>>> are (1) curly braces, (2) square brackets, and (3) a thin line -- the
>>> last being used only to connect all the staves of a system. If there
>>> are others, I'd love to see an example.
>>>
>>> --Don
>>>
>>>
>>> On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson
>>> <andrew.hankinson at mail.mcgill.ca> wrote:
>>>
>>> > Hi Zoltan,
>>> >
>>> > There is no limit to the number of nested staff groups. However, if
>>> > you have more than four nested staff groups, each with its own
>>> > bracket style, your engraver should be fired! :)
>>> >
>>> > @symbol is simply meant to indicate that there is a ?generic?
>>> > bracket, brace, or line present. This is to give a visual hint, but
>>> > not a visual definition, to any software parsing the MEI file. Do you
>>> > have any examples of connecting symbols that are not one of these?
>>> > (Beyond those previously discussed by Laurent?)
>>> >
>>> > -Andrew
>>> >
>>> > On Dec 12, 2013, at 4:30 AM, K?míves Zoltán
>>> > <zolaemil at gmail.com<mailto:zolaemil at gmail.com>> wrote:
>>> >
>>> > Hi Perry,
>>> >
>>> > It makes sense to separately encode the visual characteristics in a
>>> > child element, such as <grpSym>. Forgive me for my ignorance about
>>> > the existence of this element!
>>> >
>>> > However, I contemplate the problem of having too few values for @symbol.
>>> >
>>> > Consider the following statement: "there are N different symbols used
>>> > in the score that connect groups of staves". How would you encode the
>>> > staff groups if N>=4?
>>> >
>>> > Thanks
>>> > Zoltan
>>> >
>>> >
>>> > 2013/12/11 Roland, Perry (pdr4h)
>>> > <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>
>>> >
>>> > Hi Zoltan,
>>> >
>>> >
>>> >
>>> > Some elements (but not <staffGrp>) already allow @altsym, which
>>> > contains a pointer to a <symbolDef> element that, in turn, contains
>>> > instructions on how to "draw" the symbol.  This area of the schema
>>> > has not been exercised much and could therefore use a lot of work.
>>> > However, I think <symbolDef> could be extended to contain SVG,
>>> > PostScript, etc.
>>> >
>>> >
>>> >
>>> > Turning to how this would work with <staffGrp>, the @altsym attribute
>>> > doesn't actually belong on <staffGrp>.  It's the visual
>>> > characteristics of <grpSym> we're trying to capture, not those of
>>> > <staffGrp>.  I believe this is what Andrew's comment was intended to
>>> > mean.  So, instead of <staffGrp>, <grpSym>, which can be a child of
>>> > <staffGrp>, should bear @altsym, e.g.,
>>> >
>>> >
>>> >
>>> > <staffGrp xml:id="P2" label="Piano" barthru="true">
>>> >
>>> >  <grpSym symbol="brace" altsym="#myBrace"/>
>>> >
>>> >  <staffDef ...
>>> >
>>> > </staffGrp>
>>> >
>>> >
>>> >
>>> > Although sometimes it can't be avoided, it's generally bad practice
>>> > to use attributes to describe other attributes.  The usual way to
>>> > handle this is to "promote" an attribute to element status and then
>>> > give it its own attributes.  That's what <grpSym> is doing.
>>> >
>>> >
>>> >
>>> > The <grpSym> element, however, still has the @symbol attribute with
>>> > the same values as when it's used on <staffGrp>.  In effect,
>>> >
>>> >
>>> >
>>> > <staffGrp symbol="brace">
>>> >
>>> >
>>> >
>>> > is short-hand for
>>> >
>>> >
>>> >
>>> > <staffGrp><grpSym symbol="brace"/>.
>>> >
>>> >
>>> >
>>> > In other words, as in several places in MEI, it's possible to use
>>> > attributes for less-detail-oriented encodings (for example, when you
>>> > don't care what the brace looks like), but use elements when you do.
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > 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
>>> > ________________________________
>>> > From: mei-l
>>> > [mei-l-bounces at lists.uni-paderborn.de<mailto:
>>> mei-l-bounces at lists.uni-paderborn.de>] on behalf of Zoltán
>>> > K?míves
>>> > [zolaemil at gmail.com<mailto:zolaemil at gmail.com>]
>>> > Sent: Wednesday, December 11, 2013 5:10 PM
>>> >
>>> > To: Music Encoding Initiative
>>> > Subject: Re: [MEI-L] Thin brackets in orchestral scores
>>> >
>>> > Hi Andrew,
>>> >
>>> > The grouping of staves is captured by the staffGrp elements without
>>> > specifying @symbol. @symbol captures additional information. I talk
>>> > about this additional content.
>>> >
>>> > Zoltan
>>> > ________________________________
>>> > From: Andrew Hankinson<mailto:andrew.hankinson at mail.mcgill.ca>
>>> > Sent: 2013.12.11. 20:45
>>> > To: Music Encoding Initiative<mailto:mei-l at lists.uni-paderborn.de>
>>> > Subject: Re: [MEI-L] Thin brackets in orchestral scores
>>> >
>>> > The intellectual content (?logical domain?) is the groups of staves,
>>> > not the symbol.
>>> >
>>> > On Dec 11, 2013, at 2:06 PM, K?míves Zoltán
>>> > <zolaemil at gmail.com<mailto:zolaemil at gmail.com>> wrote:
>>> >
>>> > Hello,
>>> >
>>> > Would you mind to read my crazy thoughts about this issue? I'm just
>>> > curious what you people think of my thinking.
>>> >
>>> > I think the "intellectual content" in this case isn't so much how the
>>> > connecting symbols look, but the fact that the symbols are
>>> > *different*.
>>> >
>>> > The current values of @symbol already bear some sort of graphical
>>> > information, I think. The problem arose now, because it seems that
>>> > the current set of values don't provide a *complete" classification
>>> > (that is, in some cases there's no value which describes the symbol's
>>> > graphical shape appropriately). But of course, it's impossible to
>>> > provide a complete classification without degrading the markup to SVG.
>>> >
>>> > If we accept that the intellectual content is the *difference*
>>> > between the connecting symbols, then the proper separation of the
>>> > "intellectual content" from it's graphical representation would be to
>>> > use a set of values something like this:
>>> >
>>> > "symbol1",
>>> > "symbol2",
>>> > "symbol3",
>>> > etc.
>>> >
>>> > If one wanted to capture more info about their "look and feel", one
>>> > could use some pointing mechanism to point to a different element
>>> > that records the graphical info (possibly even pointing to an
>>> > external SVG...)
>>> >
>>> > I know, it's a crazy abstraction. And it may be way too abstract
>>> > compared to its practical use, and we could be better off adding a
>>> > handful of carefully defined values.
>>> >
>>> > Zoltan
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > 2013/12/11 Laurent Pugin
>>> > <laurent at music.mcgill.ca<mailto:laurent at music.mcgill.ca>>
>>> > It seems to me that adding "bracketsq" as a possible value would be
>>> > an appropriate addition. I don't think this particular case should
>>> > necessary open up a discussion on what is just typesetting or not.
>>> >
>>> > Laurent
>>> >
>>> >
>>> > On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h)
>>> > <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>
>>> > wrote:
>>> > Yes, caution is advised.
>>> >
>>> >
>>> > --
>>> > 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
>>> > ________________________________________
>>> > From: mei-l
>>> > [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de<mailto:
>>> virginia.edu at lists.uni-paderborn.de>] on behalf of Johannes
>>> > Kepper
>>> > [kepper at edirom.de<mailto:kepper at edirom.de>]
>>> > Sent: Wednesday, December 11, 2013 10:02 AM
>>> >
>>> > To: Music Encoding Initiative
>>> > Subject: Re: [MEI-L] Thin brackets in orchestral scores
>>> >
>>> > While there is certainly no harm in adding a well-defined set of
>>> > additional attribute values, the risk I see is that the distinction
>>> > between these values gets harder every time, eventually watering down
>>> > their expressiveness in terms of interchange. I'm not saying we're
>>> > reaching that point here, I'm just saying that we should be careful?
>>> >
>>> >
>>> >
>>> > Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h)
>>> > <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>:
>>> >
>>> >> The "land of music typesetting" is always nearby, not unlike a 4th
>>> >> dimension hovering around us and within us.  :-)   Intellectual
>>> >> content and presentation are always difficult to separate.  But try
>>> >> we must.
>>> >>
>>> >> There are already issues in the tracker related to @symbol -- nos.
>>> >> 180 & 182.
>>> >>
>>> >> From issue #180 -- "The top and bottom components of a bracket can
>>> >> be rendered as curved (similar to Unicode #x1D115) or straight
>>> >> (similar to Unicode #x0005B). The simplest method of dealing with
>>> >> this distinction is to add "bracketsq" (bracket square) to the
>>> >> values allowed by @symbol.  "bracket" will continue to be used for
>>> >> the usual, curved musical bracket. The documentation should be
>>> >> edited to make the distinction clear."
>>> >>
>>> >> I won't attempt to reproduce #182 here, but it covers the selection
>>> >> of a value for @symbol that captures a line (often fairly wide) used
>>> >> to group systems instead of a brace or bracket.  There's an image in
>>> >> #182 that illustrates various grouping symbols.
>>> >>
>>> >> Neither the so-called square bracket nor the
>>> >> wide-line-grouping-symbol can be encoded using @symbol="line" since
>>> >> that value is already reserved for the line connecting the staves at
>>> >> their left edge.  I'm partial to the value "rule", but I'm open to
>>> >> suggestions.
>>> >>
>>> >> I see no harm in adding generic values like this to MEI because they
>>> >> are what I like to call "rendering hints" for the intellectual
>>> >> content -- in this case the staff group.  But obviously this
>>> >> mechanism is not optimal for capturing all the visual details of the
>>> >> symbol, such as line width, color, position, etc.  I am somewhat
>>> >> trepidatious about going too far down that road, at the end of which
>>> >> MEI becomes a re-definition of SVG.  :-)
>>> >>
>>> >> Yes, there are still things to add to MEI.  And, yes, this is an
>>> >> opportunity to do so.  Now, if there were only more hours in the day
>>> >> ...
>>> >>
>>> >> --
>>> >> 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
>>> >> ________________________________________
>>> >> From: mei-l
>>> >> [mei-l-bounces at lists.uni-paderborn.de<mailto:
>>> mei-l-bounces at lists.uni-paderborn.de>] on behalf of Johannes
>>> >> Kepper
>>> >> [kepper at edirom.de<mailto:kepper at edirom.de>]
>>> >> Sent: Wednesday, December 11, 2013 8:47 AM
>>> >> To: Music Encoding Initiative
>>> >> Subject: Re: [MEI-L] Thin brackets in orchestral scores
>>> >>
>>> >> The reason why I feel slightly uneasy with this all is that it seems
>>> >> that we seem to enter the land of a music typesetting program here.
>>> >> In my ignorance about such details, I would probably encode that as
>>> >> a line, and ignore the fact that it is connected on both ends. In
>>> >> manuscripts, there would probably be no difference between this and
>>> >> either brackets or lines. But maybe you're right, and we should
>>> >> include the additional value. @Perry, do I remember correctly that
>>> >> you spotted some values in MusicXML not currently supported by MEI
>>> >> anyway? Is this an opportunity to revise them?
>>> >>
>>> >> jo
>>> >>
>>> >>
>>> >>
>>> >> Am 11.12.2013 um 14:39 schrieb Laurent Pugin
>>> >> <laurent at music.mcgill.ca<mailto:laurent at music.mcgill.ca>>:
>>> >>
>>> >>> You are right, I think it is missing.
>>> >>>
>>> >>> There are actually a few of them in the examples, at least there is
>>> >>> this one (however with no representation in the encoding)
>>> >>>
>>> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf
>>> >>>
>>> >>> Laurent
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Wed, Dec 11, 2013 at 1:21 PM, TW
>>> >>> <zupftom at googlemail.com<mailto:zupftom at googlemail.com>> wrote:
>>> >>> Laurent's post made me wonder whether we might be missing an
>>> >>> additional value for staffGrp/@symbol for the thin bracket that is
>>> >>> used for sub-groups in orchestral scores[1].  Looking at some PDFs in
>>> >>> the sample collection I didn't see anything like that (I didn't look
>>> >>> through all of them).
>>> >>>
>>> >>> Thomas
>>> >>>
>>> >>>
>>> >>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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
>>> >>
>>> >> Dr. Johannes Kepper
>>> >> BMBF-Projekt "Freischütz Digital"
>>> >>
>>> >> Musikwiss. Seminar Detmold / Paderborn
>>> >> Gartenstraße 20
>>> >> 32756 Detmold
>>> >>
>>> >> Tel. +49 5231 975669<tel:%2B49%205231%20975669>
>>> >> Mail: kepper at edirom.de<mailto:kepper at edirom.de>
>>> >> _______________________________________________
>>> >> 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
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Donald Byrd
>>> Woodrow Wilson Indiana Teaching Fellow
>>> Adjunct Associate Professor of Informatics
>>> Visiting Scientist, Research Technologies
>>> Indiana University Bloomington
>>>
>>>
>>> _______________________________________________
>>> 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
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>
>>
>



--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics
Visiting Scientist, Research Technologies
Indiana University Bloomington