MusicXML representation of "additional" staff

There are numerous cases in the usage of music engraving software, such as Finale, where music symbols are graphically placed in order to generate a particular semantic meaning, but the engraving software and/or the MusicXML export from it do not or cannot represent it.

A case in point is the example of the “additional” clef used below (from "Written vs. Sounding Pitch” by Donald Byrd). In order to create a more compact visual notation, a single F Clef is used within a larger G Clef context.  Most importantly, it is meant to semantically apply only to one particular note, and not any other notes that are played at that same time on that clef, or afterwards.  It is this restriction that causes problems with MusicXML, in that clef symbols apply at a particular time in a measure, and all notes played at that time on that staff would be affected by it.

In Finale, for example, one would have to essentially “paste-up” this extra clef in order to make it appear correctly from a visual perspective, but it would take some fooling around with the note itself to get the proper note value to sound, I would imagine.  In such a case, there is a disconnect between the visual and structural or semantic representation.  It seems likely that there are other such cases.

The problem is exacerbated with MusicXML export from Finale, because if Finale itself does not make the connection between the visual and semantic representations, it is unlikely to be able to express it in MusicXML properly.

And lastly, I don’t believe that there is a good way to express this scenario in MusicXML, and thus the core of this posting. While MusicXML allows for a clef with an “additional” property to be placed at a specified location, all this does is propagate the “visual” component of this clef, and not the semantic one.  Given the lack of ability to have a clef in MusicXML apply to one of many notes sounding at one time on a staff, we should at least have a recommended “best-practice” for how to represent this use case in MusicXML.  Engraving applications could then generate the appropriate MusicXML source when they recognize this situation graphically.

Best regards,

Evan Brooks