[MEI-L] Thin brackets in orchestral scores

[Johannes Kepper]

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

-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigr??e  : 496 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131211/24839aac/attachment.sig>