MakeMusic
SmartMusic Finale Garritan MusicXML

MusicXML 3.0 symbols missing from SMuFL 0.4

Moderator: Michael Good

MusicXML 3.0 symbols missing from SMuFL 0.4

Postby Michael Good » Wed Jul 03, 2013 3:41 pm

Hi Daniel and all,

I apologize for the delay on finishing and sending this. Here at last are the font symbols missing from SMuFL 0.4 that MusicXML 3.0 supports. Most if not all of these have already been raised, but I think a consolidated list should still be helpful. I think you already have sources for glyphs and usages for all of these. If not, please let me know.


Barlines: There are no equivalents for the MusicXML dotted, heavy, and heavy-heavy bar-style values.

Notes: There are no 1024th notes.

Flags: There are no combining flags for 1024th notes.

Accidentals: There are no equivalents for MusicXML's sharp-sharp, natural-sharp, natural-flat, triple-sharp, triple-flat, sharp-1, sharp-2, sharp-3, sharp-5, flat-1, flat-2, flat-3, flat-4, sori, and koron accidental values, either here or in the AEU accidentals section.

Articulations: There is no staccatissimo / spiccato (stroke) distinction. The staccatissimo symbol looks closer to the stroke / spiccato symbol.

Rests: There is no 1024th rest.

Dynamics: I'm not sure how OpenType ligatures work. If a program is going to see an mp ligature, for instance, as a separate code point, that code point needs to be standardized, not left up to the font designer's discretion. Otherwise programs that try to interpret SMuFL semantically will be as bad if not worse off with SMuFL than they are now. Multiple-letter dynamics that need to be standardized for MusicXML are pp, ppp, pppp, ppppp, pppppp, ff, fff, ffff, fffff, ffffff, mp, mf, sf, sfp, sfpp, fp, rf, rfz, sfz, sffz, and fz. I'd rather see these just standardized in the font; it's just 21 extra code points and it seems it would make life for a lot of applications much easier. It seems similar to the convenience of having accent-staccato characters, which are in SMuFL 0.4 even though it's a combination of accent and staccato characters.

Ornaments: There is no equivalent to MusicXML's schleifer or long mordent element. It would be helpful if each ornament had a unique name, preferably
(if feasible) indicating one of the more common semantics of the symbols . Right now there are a lot of "Cadence" symbols. The choice for a symbol named "mordent" seems unusual.

String techniques: This is no equivalent for MusicXML's thumb-position element.

Wind techniques: It would be good to have double- and triple-tongue symbols without the slur-like portion.

Percussion pictograms in general: Might it be possible to adopt MusicXML's categorization here, maybe splitting some MusicXML categories into multiple categories if desired? All these categorizations are fairly arbitrary anyway when it comes to percussion. One common arbitrary system might be easier for developers to handle than two close-but-not-quite systems.

Tuned mallet percussion pictograms: Marimba, vibraphone, and xylophone are mixed up in the 0.4 document. There's no equivalent for MusicXML's mallet value for the pitched element.

Bells pictograms: There is no equivalent for MusicXML's handbell value for the metal element.

Cymbals pictograms: There is no equivalent for MusicXML's Chinese cymbal value for the metal element.

Shakers or rattles pictograms: There is no equivalent for MusicXML's maracas or sandpaper block values for the wood element. The current maracas in SMuFL is MusicXML's maraca value.

Beaters pictograms: There is no equivalent for MusicXML's chime hammer or triangle beater plain values for the beater element.

Handbells: There is no equivalent for MusicXML's pluck lift value for the handbell element.

Chord symbols: There is no equivalent for MusicXML's minor chord symbol
(used when use-symbols="yes").

Conductor symbols (or maybe elsewhere): There is no equivalent for MusicXML's eyeglasses element.

Accordion: Not all the possibilities are covered from MusicXML's accordion-registration element. But it's been a long time since I looked at that literature so I'm not sure which are actually used. MusicXML handles circular 3 rank symbols with 0 or 1 dots in the top and bottom and 0 to 3 dots in the middle.

Figured bass: There is no equivalent for MusicXML's sharp-sharp prefix/suffix values.


Of course, there are many symbols in the other direction, where SMuFL 0.4 has symbols that MusicXML 3.0 does not support. I think there's a lot of potential for a future version of MusicXML to close the circle and support the extra SMuFL symbols. That's part of the source for the comment about unique names. It will make it easier to follow MusicXML references to SMuFL symbols if they can always be meaningful names rather than needing to rely exclusively on code points.

Thanks again for your great efforts on SMuFL. I'm looking forward to seeing the next iteration.

Best regards,

Michael Good MakeMusic, Inc.
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: MusicXML 3.0 symbols missing from SMuFL 0.4

Postby Daniel Spreadbury » Fri Jul 05, 2013 3:51 am

Michael Good wrote:I apologize for the delay on finishing and sending this. Here at last are the font symbols missing from SMuFL 0.4 that MusicXML 3.0 supports.

Thanks for taking the time to do this. My comments inline below.

Michael Good wrote:Barlines: There are no equivalents for the MusicXML dotted, heavy, and heavy-heavy bar-style values.

I've added these, even though I don't know what their usage is!

Somebody wrote:Notes: There are no 1024th notes. Flags: There are no combining flags for 1024th notes. Rests: There is no 1024th rest.

These had already been added since SMuFL 0.4, and will be in the next revision.

Michael Good wrote:Accidentals: There are no equivalents for MusicXML's sharp-sharp, natural-sharp, natural-flat, triple-sharp, triple-flat, sharp-1, sharp-2, sharp-3, sharp-5, flat-1, flat-2, flat-3, flat-4, sori, and koron accidental values, either here or in the AEU accidentals section.

I don't have "sharp-sharp" because (to my ignorant eye) it looks just like a duplication of double sharp. I have added the n-comma flat/sharp glyphs in a new range immediately following the AEU accidentals. The koron and sori Persian accidentals had already been added since SMuFL 0.4.

Michael Good wrote:Articulations: There is no staccatissimo / spiccato (stroke) distinction. The staccatissimo symbol looks closer to the stroke / spiccato symbol.

These too had already been added since SMuFL 0.4.

Michael Good wrote:Dynamics: I'm not sure how OpenType ligatures work. If a program is going to see an mp ligature, for instance, as a separate code point, that code

Michael Good wrote:point needs to be standardized, not left up to the font designer's discretion. Otherwise programs that try to interpret SMuFL semantically will be as bad if not worse off with SMuFL than they are now. Multiple-letter dynamics that need to be standardized for MusicXML are pp, ppp, pppp, ppppp, pppppp, ff, fff, ffff, fffff, ffffff, mp, mf, sf, sfp,

Michael Good wrote:sfpp, fp, rf, rfz, sfz, sffz, and fz. I'd rather see these just standardized in the font; it's just 21 extra code points and it seems it

Michael Good wrote:would make life for a lot of applications much easier. It seems similar to the convenience of having accent-staccato characters, which are in SMuFL

> 0.4 even though it's a combination of accent and staccato characters.

I have encoded the above pre-composed dynamics in the dynamics range, somewhat against my better judgement ;^)

Michael Good wrote:Ornaments: There is no equivalent to MusicXML's schleifer or long mordent element. It would be helpful if each ornament had a unique name, preferably
(if feasible) indicating one of the more common semantics of the symbols

.
Michael Good wrote:Right now there are a lot of "Cadence" symbols. The choice for a symbol named "mordent" seems unusual.

I am open to suggestions from the community about how better to name the ornaments in SMuFL. If all else fails I guess we could resort to "Cadence 1", "Cadence 2", etc.

I have added the traditional mordent and inverted mordent glyphs (by which I mean the symbols we all learn when we first encounter baroque and classical keyboard music), and have also added your "schleifer" mordent.

Michael Good wrote:String techniques: This is no equivalent for MusicXML's thumb-position element.

I have added this.

Michael Good wrote:Wind techniques: It would be good to have double- and triple-tongue symbols without the slur-like portion.

I have added these as stylistic alternates for the existing double- and triple-tonguing symbols.

Michael Good wrote:Percussion pictograms in general: Might it be possible to adopt MusicXML's categorization here, maybe splitting some MusicXML categories into multiple categories if desired? All these categorizations are fairly arbitrary anyway when it comes to percussion. One common arbitrary system might be

> easier for developers to handle than two close-but-not-quite systems.

Changing the categorisation of percussion pictograms in SMuFL at this point would be a pretty significant job of work. I'm not ruling it out, but it's not something I can consider for this revision.

Michael Good wrote:Tuned mallet percussion pictograms: Marimba, vibraphone, and xylophone are mixed up in the 0.4 document. There's no equivalent for MusicXML's mallet value for the pitched element.

The mix-up has already been fixed, and likewise an empty trapezoid glyph has also been added since SMuFL 0.4.

Michael Good wrote:Bells pictograms: There is no equivalent for MusicXML's handbell value for the metal element.

This too has been added since SMuFL 0.4.

> Cymbals pictograms: There is no equivalent for MusicXML's Chinese cymbal

> value for the metal element.

And this :^)

Michael Good wrote:Shakers or rattles pictograms: There is no equivalent for MusicXML's maracas or sandpaper block values for the wood element. The current maracas in SMuFL is MusicXML's maraca value.

Sandpaper blocks is indeed already encoded in SMuFL 0.4, in the
'Miscellaneous percussion instruments pictograms' range (page 54 in the 0.4 doc).

I have added the plural maracas pictogram, and renamed the existing maracas pictogram in the singular.

Michael Good wrote:Beaters pictograms: There is no equivalent for MusicXML's chime hammer or triangle beater plain values for the beater element.

Both of these are included in SMuFL 0.4; see page 56 in the 0.4 doc. I have changed the name of "mallet" to "chime hammer" in the 0.5 document to match MusicXML.

Michael Good wrote:Handbells: There is no equivalent for MusicXML's pluck lift value for the handbell element.

Now added.

Michael Good wrote:Chord symbols: There is no equivalent for MusicXML's minor chord symbol
(used when use-symbols="yes").

Also now added.

Michael Good wrote:Conductor symbols (or maybe elsewhere): There is no equivalent for MusicXML's eyeglasses element.

This has been added since SMuFL 0.4, to the 'Miscellaneous symbols' range.

Michael Good wrote:Accordion: Not all the possibilities are covered from MusicXML's accordion-registration element. But it's been a long time since I looked at that literature so I'm not sure which are actually used. MusicXML handles circular 3 rank symbols with 0 or 1 dots in the top and bottom and 0 to 3 dots in the middle.

I researched the actual registrations possible and recommended on accordions and settled on the set of registrations that are included. It may make sense to include the various empty coupler diagrams and a dot glyph so that scoring applications can construct other arbitrary diagrams if needed; I will think about this for a future revision.

Michael Good wrote:Figured bass: There is no equivalent for MusicXML's sharp-sharp prefix/suffix values.

Again, to my ignorant and untrained eye, "sharp-sharp" = "double sharp", which is already included, so I have elected not to add this.

Thanks again for the comprehensive review. I hope to be able to publish SMuFL 0.5 early next week; I am just waiting for Dave Keenan and George Secor to finish their deliberations about how best to include the Sagittal system of microtonal accidentals in the standard, which they have said they will do in the next few days.

All the best,

Daniel

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | www.steinberg.net Managing Director: Andreas Stelling, Kazunori Kobayashi Registration Court: Hamburg HRB 86534
Daniel Spreadbury, Steinberg
http://blog.steinberg.net
User avatar
Daniel Spreadbury
 
Posts: 13
Joined: March, 2014
Location: London, UK
Reputation: 0

Re: MusicXML 3.0 symbols missing from SMuFL 0.4

Postby L. Peter Deutsch » Fri Jul 05, 2013 8:11 am

Somebody wrote:> [multiple-letter dynamics]

I have encoded the above pre-composed dynamics in the dynamics range, somewhat against my better judgement ;^)

For what it's worth, my authority on music typography -- a professor at a local university whose principal research interest is in this area -- says that for publication-quality typography, it is absolutely essential that multi-character dynamics be treated as glyphs in their own right, just like ligatures for text setting.

L Peter Deutsch
L. Peter Deutsch
 
Posts: 205
Joined: March, 2014
Reputation: 0

Re: MusicXML 3.0 symbols missing from SMuFL 0.4

Postby Joe Berkovitz » Fri Jul 05, 2013 9:46 am

Daniel Spreadbury wrote:I have encoded the above pre-composed dynamics in the dynamics range, somewhat against my better judgement ;^)

This is a good idea, actually. I think we've already agreed not to absolutely rely on ligatures to supply "essentials" of musical typography. The proper tailoring of these precomposed dynamics is definitely such an essential.

. . . . . ...Joe

Joe Berkovitz President

Noteflight LLC Boston, Mass. phone: +1 978 314 6271 www.noteflight.com
"Your music, everywhere"
Joe Berkovitz
 
Posts: 79
Joined: March, 2014
Reputation: 0

Re: MusicXML 3.0 symbols missing from SMuFL 0.4

Postby Michael Good » Fri Jul 05, 2013 10:23 am

, Hi Daniel,

Thanks for these changes! The dynamics additions will be especially important for top-quality typography, web-based software, and MusicXML-SMuFL interaction.

The sharp-sharp symbol is two sharps symbols (similar to the double flat symbol), as opposed to the x-like symbol for double-sharp. It is part of an older notation style for double sharps, similar to natural-sharp and natural-flat. The visual example on the MusicXML site is incorrect here; this is something we will fix in the future.

So the items still remaining from your list seem to be:

- sharp-sharp for accidentals and figured bass
- triple-sharp and triple-flat for accidentals
- I'm not quite clear about the mordent and inverted mordent elements. Will then have both short and long versions?

Best regards,

Michael Good MakeMusic, Inc.
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Who is online

Users browsing this forum: No registered users and 2 guests