[MEI-L] Thin brackets in orchestral scores

Thu Dec 12 10:30:43 CET 2013

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>

>  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 (w)
> pdr4h (at) virginia (dot) edu
>   ------------------------------
> *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Zoltán
> Kőmíves [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 <andrew.hankinson at mail.mcgill.ca>
> Sent: 2013.12.11. 20:45
> To: Music Encoding Initiative <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> 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>
>
>> 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> wrote:
>>
>>> Yes, caution is advised.
>>>
>>>
>>> --
>>> 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+pdr4h=virginia.edu at lists.uni-paderborn.de]
>>> on behalf of Johannes Kepper [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>:
>>>
>>> > 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 (w)
>>> > pdr4h (at) virginia (dot) edu
>>> > ________________________________________
>>> > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of
>>> Johannes Kepper [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
>>> >:
>>> >
>>>  >> 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> 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
>>> >> 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
>>> >
>>>  > Dr. Johannes Kepper
>>> > BMBF-Projekt "Freischütz Digital"
>>> >
>>> > Musikwiss. Seminar Detmold / Paderborn
>>> > Gartenstraße 20
>>> > 32756 Detmold
>>> >
>>> > Tel. +49 5231 975669
>>> > Mail: kepper at edirom.de
>>>  > _______________________________________________
>>> > 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
>>
>>
>  _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131212/24a0a5b6/attachment.html>