[smufl-discuss] Fw: MusicXML 3.0 symbols missing from SMuFL 0.4

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[smufl-discuss] Fw: MusicXML 3.0 symbols missing from SMuFL 0.4

dspreadbury
Administrator
Attempting to send this to the list on behalf of Michael, who tried to send this to the list but found that it got bounced.

-----Forwarded by Daniel Spreadbury/SMTG on 2013-07-03 23:34 -----
To: [hidden email]
From: "Good, Michael"
Sent by: [hidden email]
Date: 2013-07-03 22:45
Subject: [MusicXML] MusicXML 3.0 symbols missing from SMuFL 0.4

This message was also sent by [hidden email] to: [hidden email]

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.

-----------------------------------------------------------------------------
  Post your message to the list by sending it to [hidden email].

  To contact the list owner, send your message to
      [hidden email].

To unsubscribe, switch to/from digest, get on/off vacation, or change your email address, click here.
<http://cgi.mail-list.com/u?ln=musicxml&nm=d.spreadbury%40steinberg.de>


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


#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
To switch to the DIGEST mode, E-mail to <[hidden email]>
To switch to the INDEX mode, E-mail to <[hidden email]>
Send administrative queries to  <[hidden email]>