MusicXML - On the duration element and the attack and release attributes
Dealing with the MusicXML duration element, and the note attributes attack and release, can be mystifying. Although the MusicXML documentation is very specific on the low-level syntax in this area, it does not give much guidance as to the higher-level "grammar". As a result, the developers of various music notation programs have adopted a panoply of different interpretations. The result is that successful interchange of scores between disparate programs via MusicXML is hard to achieve.
Based on an extensive study of the MusicXML documentation, informed by various observations made by Michael Good, I suggest that MuseScore adopt the following plan:
GENERATING A MusicXML FILE
Each element should contain not only the obligatory duration element but also the optional type element. The notation symbol should be encoded into the type element. The duration element should always give a value corresponding to the time value of the notation symbol.
It may seem odd (and wasteful) that duration is thus consigned to merely repeat, in a different form, the indication given by type, but that is an artifact of the historical evolution of this area.
If the play duration has been set to other than that implied by the time value of the note, or if the play start time has been offset, these "customizations" should be described by the attributes attack and/or release.
INTERPRETING A MusicXML FILE
If the note element does not include a type element, the notation symbol should be as suggested by the value of duration.
If the element includes a type element, the notation symbol should be as that element indicates.
In that event, philosophically, the value of should be taken as the musical duration of the note. The main significance of this is that the musical duration tells how long (in musical time) it is to the beginning of the "reign" of the next note.
Except in a special case, we should expect duration to describe the same musical duration as implied by the notation symbol specified by type.
The "base" play duration should be the same as the musical duration. If the note element contains an attack and/or release attribute, the start or end times of the play duration should be varied from those of the "base" play duration accordingly.
But there are two flies in this ointment:
- The "special case" mentioned is that of the infamous notes inégales, of which the "swung eighths" construct is the most common modern example. The MusicXML documentation tells us that in this case, the duration elements should reflect the intended "swing" pattern, duration for the first note of a pair being greater than the duration implied by the notation, and duration for the first note of a pair being greater than the duration implied by the notation. It is assumed that, absent an attack or release attribute, the play durations would follow themusical durations.
Michael Good tells us, though, that this implementation of "swung eighths" is hardly if at all followed today. Rather, that is done this way: The values follow the time values of the notes. The "warping" of the play durations for the "swing" is done wholly by way of the "attack" and "release" attributes.
- Some applications (notably Overture) encode duration to give the play duration.
That is not consistent with the best interpretation I have of the probable intent of the MusicXML standard, but it is a fact.
Putting these two together, in a practical frame of mind, leads to this plan:
If the element does not include a type element, the notation symbol should be as suggested by the value of duration.
If the note element includes a type element, the notation symbol should be as that element indicates, and the duration element should be ignored.
In either case, the musical duration should be considered the same as implied by the notation symbol.
The "base" play duration should be the same as the musical duration.
If the note element contains an attack and/or release attribute, the start or end times of the play duration should be varied from those of the "base" play duration accordingly.
Best regards, and stay safe.
Doug
Comments
Now, where are we now, in MuseScore 3.6?
GENERATING A MusicXML FILE
MuseScore provides each note element with a type element and a duration element. Good.
The type element reflects the symbol type of the note (quarter note, eighth note, etc.) Good.
The *duration element has the value corresponding to the note symbol, regardless of any "adjustment" to the play times. Good.
If the play start and/or end time has been adjusted from the "base" value implied by the note symbol, there is no indication of this in the MusicXML code by way of the note attributes attack and/or release. Not so good.
INTERPRETING A RECEIVED MusicXML FILE
A. If there is no type element, the symbol for the note is deduced from the value of the duration element. Good
B. If there is a type element, the symbol for the note is made as type indicates. Good.
C. In either case, the musical duration of the note is made per the duration element. This is consistent with the apparent philosophy of the MusicXML language, but as I discussed above, is neither useful in current practice nor accommodating of the questionable Overture practice. Thus I consider that to be not so good.
D. The "base" play time is that indicated by the note symbol (not the musical duration). If there is a type element, and the duration element indicates a different time, this leads to a very odd result: if duration is less than the time implied by the note symbol (from type), the played note will hang into the next note's musical time.
In addition, if the sum of the duration values in a measure is not the same amount of musical time as indicated by the time signature, MuseScore will give an error message when importing the MusicXML file.
Of course, if the program generating the MusicXML file plays by the rules I propose, duration will always be the same as type, and these curiosities will not occur.
E. The note attributes attack and release are ignored. Thus, if we have an orthodox indication of customization of note start and/or end play time, that is not reflected in the reconstructed score.
Best regards,
Doug
In reply to Now, where are we now, in… by Doug Kerr
Let me extract from my lengthy discussions above what I suggest as MuseScore's behavior with regard to the MusicXML element duration and related matters.
When generating a MusicXML file
• Each note element should include the optional type subelement, which should indicate the "symbol" to be used for the note (quarter note symbol, half note symbol, etc.).
• The mandatory duration subelement in each note element should give a duration that is the same as implied by the note symbol described by type.
• If the intended play period of the note does not match the musical time period implied by type, the attributes attack and/or release should be provided to describe the departure of the play start time and/or end time from those implied by type.
When interpreting a MusicXML file
• If there is a type subelement in a note element, the symbol for the note should be as the type element implies.
• If there is no type subelement in a note element, the symbol for the note should as implied by the duration subelement.
• The musical time allocated to a note should be as implied by the note symbol. (That means the musical time until the start of the "realm" of the next note.)
• The "base" play period of the note should be as implied by the value of the duration element. [Note 1]
• If the note element includes an attack and/or release attribute, the start and/or end times of the play period should be adjusted accordingly from those of the "base" play period.
Note 1: This rule is actually inconsistent with the underlying plan from which this protocol is based (which I have derived from the MusicXML documentation and other information). Under that plan, if there is a type element, the duration element should be ignored. But the rule I gave is a pragmatic one, intended to have MusicXML respond appropriately to a MusicXML file in which the sending program, inappropriately in my opinion, has used the duration element to describe the intended play duration of the note. A program that is often used as the source of MusicXML code that will be imported into MuseScore (Overture) currently does that.
Doug