Re: Proposal for new MusicXML 3.1 glyph element

Hi,

slightly different appearences of the same symbol would normally be 
solved by using a different font or font variant. I guess this is not 
the case here?

Pavel


On 2016-10-03 18:49, Michael Good wrote:
> Hello all,
>
> Last Friday I was working on proposed solutions for many of the current
> MusicXML 3.1 issues. You can see these proposals by looking at the In
> Progress issues on GitHub
> at https://github.com/w3c/musicxml/issues?q=is%3Aissue+is%3Aopen+label%3A%22In+Progress%22
> <https://github.com/w3c/musicxml/issues?q=is:issue+is:open+label:"In+Progress">.
>
> While working on issues 64 (SMuFL clefs), 71 (SMuFL rests), and 72
> (SMuFL octaves), I realized there were two different types of solutions
> available. I would like to discuss this on the list here before adding
> the proposed solutions to these 3 issues.
>
> These issues all involve distinguishing different glyphs that have the
> same semantic meaning. In issue 64, for instance, there are at least 3
> different glyphs for representing the G clef transposed down an octave
> (SMuFL glyphs gClef8vb, gClef8vbOld, gClef8vbCClef). In rest issue 71,
> there are three different glyphs for quarter rests (restQuarter,
> restQuarterOld, restQuarterZ). Similarly for the octave issue 72, there
> are many different glyphs for representing different MusicXML
> octave-shift values.
>
> I believe that in the large majority of cases, a single piece of music
> uses just one of these glyphs as a matter of editorial style. If this is
> true, we might best support these different glyphs in the MusicXML
> appearance element. The appearance element is global to a MusicXML score.
>
> To do this we could add a new glyph element as a child element of the
> appearance element. Like its sibling elements, it would have a type
> attribute to indicate the type of glyph, and a text value for the actual
> data - in this case, a SMuFL canonical glyph name.
>
> We would then document the standard glyph types and their associated
> SMuFL values. However we would keep both the type attribute and the
> element content as strings, not enumerations, so this could be extended
> as needed. Some examples would be:
>
> - Type of "quarter-rest": Values include restQuarter, restQuarterOld,
> restQuarterZ
> - Type of "g-clef-ottava-bassa": Values include gClef8vb, gClef8vbOld,
> gClef8vbCClef
> - Type of "octave-shift-up-8": Values include ottava, ottavaBassa,
> ottavaBassaBa, ottavaBassaVb, octaveBassa
>
> Other types that would be supported include c-clef, f-clef,
> percussion-clef, octave-shift-down-8, octave-shift-down-15,
> octave-shift-up-15, octave-shift-down-22, and octave-shift-up-22.
>
> Some additional work would still be done for these issue beyond this new
> element. For the clef issue, we could add a new "semipitched" clef value
> to handle semipitchedPercussionClef1 and semipitchedPercussionClef2.
> This would support mixing semipitched and unpitched clefs within a
> single piece. For the octave issue, we would also document the use of a
> size of 22 for 3-octave shifts.
>
> The alternative solution would be to add new attributes and/or elements
> to the child elements of the clef, note (either rest or type), and
> octave-shift elements. That seems more complex, given the
> interrelationships between the glyphs and the musical semantics. It
> seems simpler to isolate the semantic combination for each glyph choice
> (e.g., a sign of "G" and an octave-shift of "-1") within a new glyph
> element.
>
> What do you think? Does handling these glyphs in the appearance element
> make sense? Or do you think we do need to handle each glyph in a score
> individually? If there are examples of where different types of glyphs
> for the same semantics are combined in a single musical score, could you
> please reference them? Is there a different way to approach these issues
> than the two solutions mentioned here?
>
> Thank you for your help on this!
>
> Best regards,
>
> Michael Good
> VP of MusicXML Technologies
> MakeMusic, Inc.
>

Received on Tuesday, 4 October 2016 06:34:20 UTC