[MEI-L] Thin brackets in orchestral scores

[Byrd, Donald A.]

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