[MEI-L] Thin brackets in orchestral scores

Thu Dec 12 20:22:53 CET 2013

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131212/8c1e0de6/attachment.html>