What is the <voice> child of <forward> good for?

[lemzwerg]

AFAICS, the <voice> child of <forward> is completely redundant, since for <note> it is always necessary to specify <voice> explicitly – MusicXML doesn't have a feature to automatically assign something to a given voice based on previous elements. Please correct me if I'm wrong.

So: why does this child exist besides being informative, and is there an example where it is really needed?

[infojunkie]

It's a confusing topic...

• Why doesn't backup have a voice?
• I note that voice is optional in note, what is its default? "1" ?
• What would it mean for forward to have a voice but different from the following notes?

[lemzwerg]

• Regarding <backup> not having a <voice> child, I think that the assumption is that after <backup> a new voice starts. In the documentation you can read that <backup> is 'generally used to move between voices and staves. Thus it does not include <voice> or <staff> elements.' Of course there are counterexamples: Dorico version 5.1.70.2200 produces MusicXML that contains stuff like the following, all within the same voice and staff:

<note>
<backup>
<harmony>
<forward>
<note>

• I think there isn't a default for <voice>. If it is missing, it should probably be treated as a 'voice without <voice>' (for example, by using an empty voice ID).

• I have no answer for your last question 🙂

[infojunkie]

• Your answer about backup convinces me, thanks
• If no-voice is the default, then it should be invalid for a measure that has voices to also include notes without voices. Agreed?
• I guess the answer would depend on answering your original question

Since MuseData seems to be the inspiration for the original design of MusicXML, I'll read more about MuseData over the next period, hoping to get some clarity about the design choices.

[lemzwerg]

If no-voice is the default, then it should be invalid for a measure that has voices to also include notes without voices. Agreed?

Basically, I agree with you. However, there is not a single word in the standard that goes into this direction. I think it's too late to make this particular situation invalid. Instead, I suggest to add a remark that <note> elements without a <voice> child are assigned to the empty voice ID.

[mdgood]

Any time you wonder if something should be made more restrictive in the MusicXML schema, the answer is probably no. In part that's because it's too late, as Werner says. But it's also because MusicXML is representing sheet music as it appears on the page, whether or not that is convenient for software applications.

Voices for instance are an interpretive concept that people and apps layer onto the music in a score. It's reasonable for a MIDI-type application to not use them at all. It's reasonable for an analysis application to use them only on notes where there are multiple voices, such as when a single line splits in two.

The forward element has a voice element because it's pretty much an invisible rest. The backup element does not have it because it is usually marking a change between voices, for apps that use voices.

Schematron and similar technologies can catch things that are incorrect that XSD validation cannot, and that can be very helpful. But it's important not to be overly restrictive here either, even if it's tempting to possibly make things more convenient for some apps.

[infojunkie]

Any time you wonder if something should be made more restrictive in the MusicXML schema, the answer is probably no. In part that's because it's too late, as Werner says. But it's also because MusicXML is representing sheet music as it appears on the page, whether or not that is convenient for software applications.

Yes, I agree with this principle and will make sure to uphold it.

The forward element has a voice element because it's pretty much an invisible rest. The backup element does not have it because it is usually marking a change between voices, for apps that use voices.

Thanks, that helps explain it.

[lemzwerg]

The forward element has a voice element because it's pretty much an invisible rest.

Thanks, too. I suggest to mention this in the documentation.

However, I still think that <voice> in <forward> is redundant, because to correctly typeset a MusicXML measure you must resolve everything into musical time steps – there is no guarantee whatsoever that elements with a <voice> child follow an increasing (or descending) order within a measure. After having time steps, both <backup> and <forward> are no longer needed, and per-voice invisible rests can be easily identified by 'jumps' (i.e., time-wise discontinuities) between <note> elements in the same voice.