Re: Proposal for new MusicXML 3.1 glyph element

Having a default glyph for each semantic meaning declared in the appearance
element seems convenient and worthwhile.  However, I think users should be
able to override this default on individual elements if desired.  This
provides the convenience of a global declaration while retaining the
flexibility of individual declarations.

Sienna

On Mon, Oct 3, 2016 at 11:50 AM, Wil Macaulay <wil.macaulay@gmail.com>
wrote:

> In my view, your proposal makes it easier to build global stylesheets. I'd
> like that.
>
> wil
>
> On Mon, Oct 3, 2016 at 9:49 AM, Michael Good <mgood@makemusic.com> 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/musi
>> cxml/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.
>>
>>
>
>
> --
> The Craic app: http://thecraic.co abc tunes on the iPad and iPhone
> Sideband app: http://sideband.co slow down, loop and change the key.
> Learn by ear.
> Products and services: http://flagpig.com
> Twitter: @tom_frog
>