Re: Proposal for new MusicXML 3.1 glyph element

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/
> 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.
>
>


-- 
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