On the MuseScore element <duration>

As with much of the MusicXML language, it is not easy to discern from the MusicXML "specification" and the supporting documentation just what is the "intent" regarding the element duration. And I have not had the benefit of any conversation with such experts as Michael Good, the godfather, and current principal keeper, of the language.

But from extensive contemplation I conclude that, for practical purposes, the "intent" is:

• The element duration dictates, in numeric form, the time value ("quarter", "eighth", etc.) of the note).

• If present (it is optional), the element type also dictates (in this care in enumerative textual form) the time value of the note. That is, properly the two elements should dictate the same time value.

Of course, in the latter situation (certainly the most common today), this is redundant. But I conclude that this is the result of the evolution of the language.

Now, what if the value of duration is not consistent with the value of type? Well, they should be consistent.

I'm sure this is a somewhat discomforting conclusion.

As of version 3.5.2, it seems that MuseScore's reaction to duration and type in a MusicXML note element is this; I presume here that both those elements are present:

• The value of type dictates the time value ("quarter", "half", etc.) of the reconstructed note.

• The value of duration dictates the allotment of musical time to the note. This in effect means how much musical time there is from the start of the "era" of one note to the start of the "era" of the next note.

• The sounding eras of the notes begin at the start of the note's era, and the duration is as indicated by the note's time value.

If in a particular case, the values of duration are not consistent with the values of type:

• Usually MuseScore will give an error message.

• If we proceed, an odd structure of the measure(s) is created. (I will not describe that in detail; the whole story is rather complicated, and a bit ugly.)

It is hard to tell what sort of plan this behavior is meant to implement. In any case, a sensible result only obtains if, for each note, the values of type and duration are consistent.

I recommend that the behavior of MuseScore upon the import of a MusicXML file be made as follows with regard to this aspect of note elements:

• If there is no type element, the time value of the note should be as implied by the value of duration.

• If there is a type element, the time value of the note should be made to follow that, and the duration element should be ignored. [Yes, that is shocking!]

• The musical time allocated to a note should be equal to its time value.

• The base play era should begin at the start of the note era and have the same duration as implied by the note time value.

• If there is an attack attribute and/or a release attribute for the note element, they should be honored to shift the start time of the play era and/or the end time of the play era, respectively.

I will discuss later my recommendations regarding the generation of MusicXML code.

If the above were adopted, would that lead to the general ability to interchange scores from other notation programs to MuseScore and end up with a score that would play the same as it did in its program of birth? Not unless other programs did what I recommend.

Would there be a different scheme that MuseScore could adopt that would allow such interchange on a broad basis? No. Unless we limit ourselves to scores in which all notes are expected to start at the nominal time and play for "100% of face value", in which case MuseScore can receive those successfully now.

Just sayin'

Best regards, and stay safe.

Doug