Re: Proposal for new MusicXML 3.1 glyph element

Hi Jeremy, James, Pavel, Daniel, Sienna, and Will,

Thanks to all of you for your feedback on this proposal!

Pavel, this is a case where these are different symbols within the same font. A SMuFL-compllant font like Bravura has different glyphs for these different variations on clef, rest, and octave symbols. We want to be able to capture that variation of glyphs within a single font within MusicXML 3.1. As more applications add SMuFL support, better support for SMuFL symbols will be necessary to keep MusicXML interoperability at a high level.

Jeremy and Sienna, I initially started out trying to design this as you suggested, with the glyphs being able be overridden locally. However I quickly ran into two problems.

The first is that, unlike our other issues for adding better SMuFL support, there is not one localized MusicXML element to extend to capture these differences. For noteheads and accidentals, for instance, we just added a smufl attribute to the notehead and accidental elements. For dynamics, we just added new elements like n as children of the dynamics element.

For rests especially, things are not so simple. We are trying to specify the glyph appearance when the rest element is present and the sibling type element has a content of "quarter". So would this go with the rest element or the type element? How would you document the restriction that this really only applies to one specific combination of the two elements? How likely is it that people will understand that inherently confusing documentation and do the right thing, either reading or writing? Similar issues come up with overriding clefs (a mix of sign and clef-octave-change elements) and to a lesser extent with octave symbols (a mix of type and size attributes in the octave-shift element). This seems error-prone, which is not good for effective score interchange.

The second problem is that the local representation obscures what is going on. In real-life repertoire, the choice of these glyphs is indeed a document-level decision. So it is not only more convenient to place these choices in the appearance element. It is a more accurate representation of how these glyph differences are actually used in musical scores. 

We seem to agree on the second point. The difference of opinion appears to be on the cost / benefit of also providing a local override for these symbols. My take on things is that MusicXML 3.0 is already complicated enough representing actual musical repertoire, given the inherent complexity of music notation. I think it would be wise to not add features that involve complex interactions to handle use cases that at present seem more theoretical. I think the two cases that Jeremy mentions could also be handled by having separate MusicXML scores, or perhaps by using XML processing instructions.

If there are actual repertoire examples where different glyphs are used within the same musical score, or proposals for how to locally override these glyphs in a less complex way than I have been able to find, please let me know!

Best regards,

Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.

> On Oct 4, 2016, at 5:05 AM, Jeremy Sawruk <jeremy.sawruk@gmail.com> wrote:
> 
> I'm going to respectfully disagree with what I think is the consensus so far, that once the glyph is defined in the <appearance> element, it is applied globally. Instead, I agree with Sienna's position that "users should be able to override this default on individual elements if desired". 
> 
> To James Sutton's point about it being unexpected or confusing to use different symbols in the same score, this is true if we are looking at a score, but may be false in a few conditions, such as:
> - Academic or reference works demonstrating the use of the different glyphs
> - Software testing to see if a renderer is SMuFL and MusicXML compliant, such as the Lilypond MusicXML test suite.
> 
> On Tue, Oct 4, 2016 at 4:48 AM, James Sutton <jsutton@dolphin-com.co.uk <mailto:jsutton@dolphin-com.co.uk>> wrote:
> Seems good to me. It would be unexpected and confusing for a score to use different symbols for the same thing in different places
> 
> James Sutton
> Dolphin Computing
> http://www.dolphin-com.co.uk <http://www.dolphin-com.co.uk/>
> http://www.seescore.co.uk <http://www.dolphin-com.co.uk/>
> 
> 
>> On 3 Oct 2016, at 21:43, Michael Good <mgood@makemusic.com <mailto:mgood@makemusic.com>> wrote:
>> 
>> Forwarded with Daniel's approval as this was intended for the entire list…
>> 
>>> Begin forwarded message:
>>> 
>>> From: "Daniel Spreadbury" <D.Spreadbury@steinberg.de <mailto:D.Spreadbury@steinberg.de>>
>>> Subject: Re: Proposal for new MusicXML 3.1 glyph element
>>> Date: October 3, 2016 at 12:54:21 PM PDT
>>> To: Michael Good <mgood@makemusic.com <mailto:mgood@makemusic.com>>
>>> 
>>> Michael Good <mgood@makemusic.com <mailto:mgood@makemusic.com>> wrote on 03/10/2016 17:49:52:
>>> 
>>> > 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?
>>> 
>>> This sounds like an appropriately pragmatic approach to me. In my research on these specific glyphs as part of the SMuFL work, the idea that these glyphs would not be mixed within the same edition was certainly supported by the usage we found in actual publications. I think therefore that a good general approach to encoding different appearances for semantically identical symbols would be to use the <appearance> element.
>>> 
>>> Daniel
>>> 
>>> 
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
>>> 
>>> Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany
>>> 
>>> Phone: +49 (40) 21035-0 <tel:%2B49%20%2840%29%2021035-0> | Fax: +49 (40) 21035-300 <tel:%2B49%20%2840%29%2021035-300> | www.steinberg.net <http://www.steinberg.net/>
>>> 
>>> President: Andreas Stelling | Managing Director: Thomas Schöpe, Hirofumi Osawa
>>> 
>>> Registration Court: Hamburg HRB 86534
>>> 
>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
>> 
> 
>