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

[dspreadbury]

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

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

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

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

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

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

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

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

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.

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

I have added this.

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

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

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

> 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 :^)

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

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

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

Now added.

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

Also now added.

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

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

> 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: [phone] | Fax: [phone] | 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]>