Allow grace cue notes

[mdgood]

MusicXML 3.0 allows a note to be specified as a grace note or a cue note, but not both. This is a carryover from MuseData design that does not necessarily fit as well into the MusicXML format. It would make for a more natural data representation if grace cue notes could be directly represented in MusicXML.

Andreas Wenger (@Xenoage) raised this issue on the MusicXML forum:

This is a "one-dimensional" decision between these types. A note can either be a normal note, a grace note or a cue note. It is not possible to have a note that is both grace and cue. However, I think that there should be a "two-dimensional" decision: A note can either be "normal" (has a duration) or grace, and it can either be in the "normal voice" or in a "cue voice". (I tested it with Sibelius, and there it seems to be implemented the same two-dimensional way)

Michael Good (@mdgood) agreed this would be desirable, but pointed out some technical issues that any such solution will need to overcome:

We should perhaps add an option for grace notes to also be cue notes in the future. That is, if we can do so without running into W3C XML Schema's unique particle attribution constraint, or other XML ambiguity constraints, and without breaking existing MusicXML software.

See the MusicXML forum discussion at http://forums.makemusic.com/viewtopic.php?f=12&t=2127, where Joe Berkovitz (@joeberkovitz) also expressed support for this new feature.

[mscuthbert]

I also haven't fully understood the prohibition on ties in cue notes -- I understand that cue notes are not by default played back, but parsers will want to option of specifying to play cues and without the information, they cannot (without looking for help from ). I don't think that this would run up against unique particle attribution constraint.

[mdgood]

I think we can do this by allowing a cue element to come after the grace element, and providing a choice for what follows after the grace element. In this XSD it would look like this:

    <xs:sequence>
        <xs:element name="grace" type="grace"/>
        <xs:choice>
            <xs:sequence>
                <xs:group ref="full-note"/>
                <xs:element name="tie" type="tie" minOccurs="0" maxOccurs="2"/>
            </xs:sequence>
            <xs:sequence>
                <xs:element name="cue" type="empty"/>
                <xs:group ref="full-note"/>
            </xs:sequence>
        </xs:choice>
    </xs:sequence>

In the DTD, it would like like this:

    (((grace, (%full-note;, (tie, tie?)?) | (cue, %full-note;)) |

By doing it this way, the to30.xsl stylesheet can just remove the cue element if it has a previous sibling instead of being the first element child of the parent note element.

I haven't actually tried this out to make sure it doesn't run into unique particle attribution or other ambiguity constraints, but I don't think that it will.

Comments and suggestions are most welcome!

[mdgood]

I think that adding this feature will also involve adding a new note size for notes that are both grace and cue notes. This would involve adding a new "grace cue" enumeration value to both the note-size-type and symbol-size enumeration simple types. The note-size-type enumeration is used in the note-size element to define default sizes. The symbol-size enumeration is used in the type element to override a default size for a particular note.

While we are adding this we can also clean up some typos in the note-size-type documentation.

Does this seem reasonable?

[mdgood]

@mscuthbert, the rationale for not allowing cue notes to have tie elements is that the cue element indicates a silent note. You can make a regular, playing note cue-size, but not vice-versa. This is probably something we should re-examine in MNX. For MusicXML 3.1 though, maybe bring issue #67 into scope would help?

[mscuthbert]

That makes sense to me given that the cue element implies silence and not optionally silent. I think that there are uses for optionally silent cued elements where playback indications are important. In many band scores, it'd be common to want to prepare multiple playback formats, such as with the English Horn cues played in the saxophone and without. But I think that a change like this might be better to wait for a larger rethinking of cue parts for a later revision (such as, linking by reference to the part to be cued, for linked changes, etc.) Happy new year!

[webern]

In general, I also find the restriction against ties to be strange for cue notes. As I understand it, a grace note cannot have a <duration>, a cue note cannot be <tied>, and a normal note has both <duration> and <tied>.

To me, the complexity of this arrangement seems more detrimental than any nonsensicality that might occur in practice by removing the restrictions. For example, if all notes had both the <tied> and <duration> elements, then <grace> and <cue> simply become properties of a note. This would be simpler, in my opinion, for implementations.

I assume that this solution might be impossible with backward compatibility and the constraints of xsd, but I wanted to chime in as we consider MNX.

In general my preference is for simplicity of implementation over absolute correctness. For example, in designing MNX I would ask, "is it really harmful to the musical semantics to allow a cue note to be tied?", my answer would be "not really." Then I would ask, "Would the restriction of making a cue note un-tie-able add undue complexity to implementations?" In this case, I would answer yes because it adds a new choice, a new group, etc.

[mdgood]

To clarify, a cue note can have a <tied> element within the <notations> element, but it cannot have a <tie> element. The <tie> element is for playback, the <tied> element for appearance. I agree that we should revisit the definition and restrictions on cue notes in MNX.

[mdgood]

Pull request #177 addresses this issue. I needed to change the "grace cue" size value to "grace-cue" to get this working well with both the DTD and XSD.

[mdgood]

Issue #229 and pull request #230 fixed an issue in XSLT conversion to MusicXML 3.0.