Re: Proposal for new MusicXML 3.1 glyph element

Yes, flexibility necessarily causes complexity.  Personally, I do think
that the complexity is worthwhile to accommodate educational, academic, and
theoretical applications.  It seems to me that wherever the semantic
meaning is most clearly declared is where a glyph override should also be
declared (the type element where 'quarter' is declared in your example, I
would say).

Sienna

On Tue, Oct 4, 2016 at 11:00 AM, Michael Good <mgood@makemusic.com> wrote:

> 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>
> 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.seescore.co.uk <http://www.dolphin-com.co.uk/>
>>
>>
>>
>> On 3 Oct 2016, at 21:43, Michael Good <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>
>> *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>
>>
>> Michael Good <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 | Fax: +49 (40) 21035-300 | www.steinberg.net
>>
>> President: Andreas Stelling | Managing Director: Thomas Schöpe, Hirofumi
>> Osawa
>>
>> Registration Court: Hamburg HRB 86534
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>
>>
>>
>>
>
>