Specify SMuFL alignment for the rest display-step elements

[mdgood]

MusicXML 3.0 omits details of many alignment issues that are dependent on music fonts. An area where this omission is particularly harmful for interchange is in specifying how rests should be positioned using the display-step element. Christof Schardt (@cschardt) explains the issue:

For example: this line in the DTD

<!ELEMENT rest ((display-step, display-octave)?)>

gives no information how to apply the display-data to a rest-symbol. For noteheads it is obvious (they have a reference-height) for rests it is not. (What is the reference-point for a 64th-rest?)

In consequence programs will interpret this differently. I was affected by this problem yesterday, when I got vertically misplaced rests from sharpeye. In consequence I decided, to remove the evaluation of the display-data for rests in my program as long, as the definition is missing.

This was difficult for MusicXML 3.0 to do as music fonts had no standardization for this. Fortunately the SMuFL specification as addressed this issue and there is now a common standard for a future MusicXML version to reference. MusicXML can now reference the SMuFL specification for this and other alignment applications. Applications with their own legacy fonts can then add corrective offsets when the legacy font alignment does not match the SMuFL standard.

See the MusicXML forum discussion (within a larger discussion of the need for a written MusicXML specification) at http://forums.makemusic.com/viewtopic.php?f=12&t=1891#p4516.

[mdgood]

I think I may have overestimated what SMuFL specifies for rest positions. SMuFL 1.4 specifies standard positioning for half and whole rest glyphs relative to the baseline, but is not as explicit about other rests. For those rests it does specify that the baseline (y=0) should reflect the positioning relative to the middle line of a standard five-line staff.

SMuFL behavior doesn't seem to always match legacy font behavior though, and not just for whole rests. It would be great if we could specify a rule that allows for interchange to be accurate even if a font gets converted from legacy to SMuFL along the way. Exporting a file that uses legacy fonts may require extra steps to convert to a SMuFL-compliant behavior, but we want that behavior to be well specified.

Is this something that could perhaps be clarified in SMuFL 1.4? Or is there something that we can specify on the MusicXML side that can work for both legacy and SMuFL fonts, expressed in terms that are compatible with SMuFL?

Any advice from @dspreadbury, @cschardt, @jangermueller, or other folks interested in getting this type of transfer between applications working better is most welcome!

[dspreadbury]

As you say, there is specific guidance in SMuFL for the placement of half and whole rests, because of course they’re difficult to tell apart aside from their different registration, but for the other rest glyphs, they are registered such that Y=0 is the nominal middle staff line of a normal 5-line staff. The terminals for 8th and shorter rests should always be centred in nominal spaces, and you can see that as they get shorter, they proceed outwards from the middle line of the staff: a 16th note extends one space down more than an 8th rest, and a 32nd note extends one space up than an 16th rest, and so on, alternating the direction in which an additional space is added for each subsequent halving of the duration.

Legacy fonts take a different approach. I've not looked at e.g. Maestro or another Finale font, but I would expect it to be the same as Opus, for example. Opus matches SMuFL's registration for the 16th note, but the 32nd and shorter rests only “grow” upwards, i.e. the bottom of the rest is at the same vertical position, instead of growing alternately upwards and downwards.

The SMuFL registration has the benefit of matching how the rests are actually laid out in conventional use, which is why it was chosen. But for Opus and other legacy fonts, you'd need to apply an offset of n staff spaces to match the SMuFL registration for each subsequent rest after the 32nd rest. Having said that, rests shorter than 32nd rests are pretty uncommon, so perhaps it's not really worth worrying about?

[cschardt]

In PriMus I follow the same way as SMuFL to get nice and cheap default positioning. The tricky thing is positioning in polyphonic staves, where you need access to the exact boxes anyway. The clever baseline selection within the font does not pay off here. When using different fonts it is required to translate the baselines to the intrinisic system, but this is trivial work and done only once. My conclusion: there is nothing to gain, because this translation might be mechanism is already built in most programs (which are capable of handling foreign music fonts).

[mdgood]

Thanks for the discussion @dspreadbury and @cschardt. I think the main motivation for clarifying this is so that applications can more accurately handle the display of rests that have been manually positioned in polyphonic music, rather than relying on their automatic rest placement.

I think we could do this with something like "For rests, the display step is in reference to where SMuFL fonts place the baseline for these symbols. This is the top of a whole rest and the bottom of a half rest. For other rests, it is the position where a rest would be centered by default on a 5-line staff." The whole rest ambiguity might be the most important to resolve rather than the 32nd-and-smaller rests.

If this does not seem useful, we can remove this from the 4.0 release. If most apps retain their legacy behavior, this would not help us much. The problem will likely lessen over time anyway as more applications use SMuFL fonts.