Proposal for new MusicXML 3.1 glyph element

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:%22In+Progress%22>.

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.