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

[Joachim Veit]

Only a short "a parte":
The form of the "thin square brackets" (Finale's option 6) is very often 
to be found (not only in Berlioz' example) in new Schott-Scores (e.g. in 
the new Schumann Complete edition). In the Weber edition we use them 
only in a very few special cases (I don't like them really...)
Thanks for the interesting discussion! and best greetings,
Joachim


Am 13.12.13 04:12, schrieb Byrd, Donald A.:
> Thanks, Perry. I was thinking of #3 and #5 as being basically square 
> brackets, but they're really not that square :-) . I don't think I've 
> seen any other shapes "in the wild" either.
>
> --DAB
>
>
> On Thu, 12 Dec 2013 19:10:27 +0000, "Roland, Perry (pdr4h)" 
> <pdr4h at eservices.virginia.edu> wrote:
>
>> Hi Don,
>>
>> Finale provides 6 options in its "Group Attributes" dialog box. See
>> http://www.finalemusic.com/usermanuals/finale2012win/content/finale/GROUPDLG.htm. 
>> I think "bracket" accurately describes options 3, 5, & 6 (from the 
>> left), "brace" being used for option 4.  I can't say that I've seen 
>> any other symbols "in the
>> wild".
>>
>> (NB -- My mention of Finale doesn't constitute any kind of
>> endorsement.  It's just that its documentation is easily accessible.)
>>
>> MEI currently offers only "none", "brace", "bracket", and "line" as
>> possibilities, where "line" is reserved for the thin line connecting
>> the score/system staves.  These are sufficient to capture the broad
>> categories of symbols, but they (especially "bracket") don't provide
>> much in the way of visual detail.  The question is, how/where should
>> that detail be located?
>>
>> My solution is to add "rule" and "bracketsq", representing Finale
>> options 2 and 6, respectively.  This expands the level of visual
>> detail encapsulated in the @symbol attribute, but still doesn't
>> differentiate between options 3 and 5 or capture "typographical"
>> features (so-called 'hook' shape, color, line width, etc.). However,
>> it does provide the same level of granularity as MusicXML, enhancing
>> loss-less conversion to/from MEI.
>>
>> Of course, multiple typographical details can't be captured in a
>> single attribute value.  And it's bad practice to add more attributes
>> to <staffGrp> to comment on the value in @symbol.  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.  This mechanism can be used for any symbol used to group
>> staves, if someone does find an example outside the usual ones you
>> mention, for instance in a manuscript score.
>>
>> Not exactly what you asked for, but helpful nonetheless I hope,
>>
>> -- 
>> 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
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : veit.vcf
Dateityp    : text/x-vcard
Dateigr??e  : 364 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131215/e383e3d0/attachment.vcf>