[MEI-L] Thin brackets in orchestral scores

Wed Dec 11 20:06:26 CET 2013

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