[MEI-L] Thin brackets in orchestral scores

Fri Dec 13 09:33:18 CET 2013

Don: yes, this makes sense. Historically, we can probably argue that
brackets became the standard practice for grouping instruments as the
consequence of being more convenient to print, especially with many staves
- whereas braces are easier to write by hand. In handwritten manuscripts,
we most of the time find braces including for orchestral scores. As an
example, the autograph of Bach's mass in B-minor has braces for grouping
any set of instruments/voices when there is more than one system on the
page - otherwise there is nothing. In the first prints of the mass, we will
find brackets. Actually, even in the very first printed scores in the late
16th or early 17h centuries, where anything is used to represent grouping
of the system (most of the time there is nothing), a line or a bracket is
mostly used. And we can see brackets in 18th century keyboard music prints
printed in typography, again because this was probably easier to print.
Braces remained in use and became a standard practice for grouping two or
three staves, indeed most of the time for instruments written on multiple
staves. Thin square brackets are obviously a later addition in large
orchestral scores.

One example
http://pds.lib.harvard.edu/pds/view/17525736

Laurent

On Thu, Dec 12, 2013 at 10:19 PM, 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
>>
>>
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131213/859fb145/attachment.html>