Add complete SMuFL figured bass range

[mdgood]

MusicXML could add support for the complete SMuFL figured bass range U+EA50–U+EA6F for better interoperability between applications. The range is documented at http://w3c.github.io/smufl/gitbook/tables/figured-bass.html.

MusicXML 3.0 includes support for most of the symbols in the range, but is vague about the contents of the suffix element and the meaning of the slash value. This is related to the SMuFL issue w3c/smufl#9 for clarifying forward and backward slashes. Once the SMuFL glyphs are clarified, MusicXML could then distinguish between raising and lowering, as well as the variety of raising glyphs within SMuFL.

MusicXML 3.0 allows parentheses and brackets around an entire figured-bass element. SMuFL includes figured bass parentheses and brackets glyphs that can work at the per-figure/prefix/suffix level. This might be added to MusicXML by adding support for the editorial entity for the children of the figured-bass element.

This issue arose while analyzing MusicXML 3.0 for SMuFL support in preparation for the 2015 MusicXML community meeting at Musikmesse.

[mdgood]

I believe we can address this issue with the following steps:

• Add the "plus" value to the list of values allowed for the prefix element.
• Specify the "slash", "back slash", and "vertical" values for the suffix element.

I believe that doing this will allow us to distinguish all the figure glyphs in the figured bass and figured bass supplement ranges except for the difference between figbass6Raised and figbass6Raised2.

I am not very experienced with figured bass notation. I hope those more knowledgeable than me (@dspreadbury? @mscuthbert? anyone else?) can review this and perhaps answer some questions:

• Currently the values for the prefix, figure-number, and suffix elements are all unrestricted text. Should these be limited to enumerations for the prefix and suffix element, and to positive (or non-negative) integers for the figure-number element?
• Do the values for the suffix element make sense or should they be revised? I think we want to keep "slash" for continuity with previous versions of MusicXML, and "back slash" is similar to what we use for noteheads. Is there a better name than "vertical" for the type of slash seen in figbass2Raised and figbass5Raised1?

Parentheses and bracket support on a per-figure basis are another issue which I will address in a separate comment.

[mdgood]

For per-figure parentheses and bracket support, we could add the editorial group (XSD) or entity (DTD) to the figure element. This will allow them at a per-figure level, but not at a lower level separating the prefix from the figure number. This seems reasonable to me. Does this seem reasonable to those with more figured bass expertise?

[mscuthbert]

Hi -- you've hit upon one of my "imposture syndrome" points. I've never been a star figured bass person (the people who have the most computer representation experience who are major baroque music people are Walter Hewlett and Eleanor Selfridge-Field at Stanford), but I'll give it a shot...

My sense is that both SMuFL and MusicXML would be best served by having separate entities/code-points for representing semantics and/or visuals (and I mean both "and" and "or"). Nadia Boulanger, Paul Vidal and other French composers, if I recall correctly, use certain figured bass figures to mean the exact opposite of what older Italian and German composers mean -- so that slashes that mean lower in one context mean raise in another, etc. So ideally I'd like to be able to "say" (meaning represent in SMuFL or MusicXML) "raised 5" or "5 with a slash through it" or "5 with a slash through it meaning raised 5" (or "5 with a backslash meaning lowered 5") -- since there are times when all we know is the shape, and other times when all we care about representing is the meaning. So I would allow for suffix and or prefix to be what it currently is but then have a separate "alter" value which might represent the meaning. In the absence of "alter" meaning can be inferred as currently, but in the absence of "prefix" or "suffix", then "alter" would be sufficient. (Anything like this should also define a "supports" tag at the same time).

For "figure-number", I would be fine with non-negative-integer since it can be omitted; but I'd also like to argue for a implied="yes" of some sort, so that one can define <figure-number implied="yes">3</figure-number> to mean "the third-of-the-chord-but-that's-obvious-so-don't-display". We might want to have a "leave-space" attribute too, so that for an implied 7-5-3, we can see:

7 ---- 6
4
3 --- 2

as opposed to

             6
7 ----- 4
3 ------ 2

There may also be need for a "dividing-extend" which takes a single figure and divides it up (like a hairpin, or two arrows, one drifting upwards, one downwards), as one sees with 5 going to both 6 and 4. This is more commonly done when figured bass is used in analysis.

Thanks!

[mscuthbert]

Also, an "alter" tag would clarify the semantics of a "sharp" suffix which can mean "raise by half step" or "make a sharp (perhaps by not doing anything, probably by raising a half step, but maybe raising by two half-steps)"

[mscuthbert]

One last thing that seems like it might be important to get in the "figured-bass" object is an alignment model -- in the case of a figure with a suffix of a sharp, etc.alone (common for the 3rd of a chord), should the suffix align underneath other numbers. I would imagine that as a default, all the numbers should be align-right, prefixes should go to the left of each number, and suffixes should align left after all numbers, but there are cases where the prefix should be aligned with the number, etc.

Clarifying whether empty "figure" tags should be used in order to put a number in a lower position seems like another important thing. For instance, mm. 3-4 of this passage use the lower positions of the figured bass to show the continuity of line 8-7-5-4:

As an advanced (or perhaps later version) discussion point: what should happen if there were a reflow between measure 3 and measure 4 -- in this case, I would imagine that any engraver would move the 6/5 and 4 figures up one space to be closer to the A in the bass -- there's now no longer a visual reason to keep these elements aligned. It's a similar problem to, say, wanting to keep all dynamics in a staff-system or all lyrics in a staff-system vertically aligned, but removing the restriction on keeping lyrics vertically aligned once a reflow has taken place.

[mscuthbert]

Example of the alignment issue of a number and suffix from the Vidal figured basses:

and some very thorny alignment issues.

Vidal uses +4 to mean an augmented fourth -- this might mean that the note needs to be raised (as in the case of +4 on the F#, meaning the B needs to become B#) or that it doesn't need to be altered from the key signature (as in the +4 on the F-natural or the D-natural). A prefix on the figure always indicates the accidental to be applied to the note (so b5 means that the fifth needs to have a flat on it), but a figure without a prefix does not necessarily mean that the note is natural (only an explicit natural sign means that).

This is why, I think some sort of system encoding meaning/playback separate from notation is necessary, because I'm pretty sure that Vidal/Boulanger's system is not uniformly used.

[mdgood]

Thank you for all this detail, Michael! I think that the <harmony> element already handles the separate encoding of the semantics. I will take a closer look at your other points next week, and reach out to Eleanor and the CCARH folks. MusicXML's current representation of figured bass is based on their MuseData work.

[mdgood]

I understand the importance of these alignment issues, but they seem to be beyond the scope of MusicXML 3.1. Lyrics and other markings can have similar issues.

After looking at these examples I think we do want to keep the prefix, figure-number, and suffix elements as unrestricted text.

I did reach out to Eleanor and Craig at CCARH. They are pretty busy right now but hope to be able to look at this pretty soon. In the meantime I will proceed with a more specific proposal that limits itself to the issue of SMuFL glyph coverage.

[mdgood]

Here is a proposal for a revised figure definition that should support the SMuFL figured bass range. I changed "back slash" to "back-slash" for consistency with the accidentals that are used as suffix values. Similar changes would be made in the DTD and XSLT files.

<xs:complexType name="figure">
	<xs:annotation>
		<xs:documentation>The figure type represents a single figure within a figured-bass element.</xs:documentation>
	</xs:annotation>
	<xs:sequence>
		<xs:element name="prefix" type="style-text" minOccurs="0">
			<xs:annotation>
				<xs:documentation>Values for the prefix element include plus and the accidental values sharp, flat, natural, double-sharp, flat-flat, and sharp-sharp. The prefix element may contain additional values for symbols specific to particular figured bass styles.</xs:documentation>
			</xs:annotation>
		</xs:element>
		<xs:element name="figure-number" type="style-text" minOccurs="0">
			<xs:annotation>
				<xs:documentation>A figure-number is a number. Overstrikes of the figure number are represented in the suffix element.</xs:documentation>
			</xs:annotation>
		</xs:element>
		<xs:element name="suffix" type="style-text" minOccurs="0">
			<xs:annotation>
				<xs:documentation>Values for the suffix element include plus and the accidental values sharp, flat, natural, double-sharp, flat-flat, and sharp-sharp. Suffixes include both symbols that come after the figure number and those that overstrike the figure number. The suffix values slash, back-slash, and vertical are used for slashed numbers indicating chromatic alteration. The orientation and display of the slash usually depends on the figure number. The suffix element may contain additional values for symbols specific to particular figured bass styles.</xs:documentation>
			</xs:annotation>
		</xs:element>
		<xs:element name="extend" type="extend" minOccurs="0"/>
		<xs:group ref="editorial"/>
	</xs:sequence>
</xs:complexType>

[mdgood]

Pull request #202 addresses this issue.