Re: Same symbol, different SMuFL semantics

Hi Jeremy and Glenn,

Thank you for your thoughts here.

Jeremy, what you propose about adding a SMuFL glyph attribute is similar to one proposed solution for the coda and segno alternates (issue 84: https://github.com/w3c/musicxml/issues/84 <https://github.com/w3c/musicxml/issues/84>). If we go in this direction, I would like to go with the existing smufl attribute group - a smufl attribute where the content is the SMuFL canonical glyph name, not the code point.

I don't think we will be able to do a "complete" version where every possible MusicXML element with alternate SMuFL glyphs will be covered, but I think it's a simpler approach than adding lots of additional elements throughout the format. The one place we have been doing that is in the percussion element.

Glenn, you raise some very interesting questions. An overall issue with music from notation applications is that the emphasis at publishers has usually been to make it look good in print. We are starting to see that change to print and digital, but there's a large repertoire of existing music files where semantic entry is an issue. Older files tend to have more problems, as notation software does an even-better job over time of guiding users to better semantics. However people under time pressure may still enter things "wrong" if it is faster and looks good (e.g. the first category your software suggests that has the symbol you are looking for).

I think Jeremy's proposal fits in well with what we have been doing elsewhere in MusicXML 3.1. I am inclined to go in that direction. Are there other proposals for how to address this overall issue?

Best regards,

Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.