Version 4.0

Released June 2021

Packaging Changes

• MusicXML 4.0 specifies a standard way to represent both score and parts in a single compressed .mxl file. (Issue 278)
• MusicXML 4.0 now contains a standard XML catalog to make local validation easier. (Issue 259)
• MusicXML 4.0 now contains W3C XML Schema versions of the container and sounds document definitions, replacing the deprecated DTD versions. (Issue 401)

Schema Additions

New Elements

• The <assess> element specifies how default assessment should be overridden for individual notes. (Issue 294)
• The <bass-separator> element indicates that text, rather than a line or slash, separates the bass from what precedes it. (Issue 307)
• The <concert-score> element indicates that a score is displayed in concert pitch. (Issue 39, Issue 279)
• The <first> element represents the first of two consecutive notes in a swing ratio. (Issue 283)
• The <for-part> element is used in a concert score to indicate the transposition for a transposed part created from that score. (Issue 279)
• The <instrument-change> element represents a change to the virtual instrument sound for a given <score-instrument>. (Issue 293)
• The <line-detail> element specifies the appearance of a line in the staff. (Issue 305)
• The <listen> element specifies different ways that a score following or machine listening application can interact with a performer. It represents interactions that are specific to a note. (Issue 294)
• The <listening> element specifies different ways that a score following or machine listening application can interact with a performer. It represents interactions that change the state of the listening application from the specified point in the performance onward. (Issue 294)
• The <note> element may now contain multiple <instrument> elements. (Issue 277)
• The <numeral> element represents the Roman numeral or Nashville number part of a harmony. It requires that the key be specified in the encoding. (Issue 295)
• The <numeral-alter> element represents an alteration to the <numeral-root>. (Issue 295)
• The <numeral-fifths> element specifies the reference key for the <numeral> in the same way as the <fifths> element. (Issue 295)
• The <numeral-key> element is used when the key for the <numeral> is different than the key specified by the key signature. (Issue 295)
• The <numeral-mode> element specifies the scale that is used to interpret the <numeral-root> element values. (Issue 295)
• The <numeral-root> element represents the Roman numeral or Nashville number as a positive integer from 1 to 7. (Issue 295)
• The <other-listen> element represents other types of listening control and interaction that are specific to a note. (Issue 294)
• The <other-listening> element represents other types of listening control and interaction that change the state of the listening application from the specified point in the performance onward. (Issue 294)
• The <part-clef> element is used for transpositions from concert scores that also include a change of clef, as for instruments such as bass clarinet. (Issue 55)
• The <part-link> element allows MusicXML data for both score and parts to be contained within a single compressed MusicXML file. It links a <score-part> from a score document to MusicXML documents that contain parts data. (Issue 278)
• The <part-transpose> element specifies the transposition for a transposed part created from the existing score file. (Issue 279)
• The <player> element allows for multiple players per <score-part> for use in listening applications. (Issue 294)
• The <second> element represents the second of two consecutive notes in a swing ratio. (Issue 283)
• The <straight> element specifies that no swing is present, so consecutive notes have equal durations. (Issue 283)
• The <swing> element specifies whether or not to use swing playback, where consecutive on-beat / off-beat eighth or 16th notes are played with unequal nominal durations. (Issue 283)
• The <swing-style> element describes the style of swing used. (Issue 283)
• The <swing-type> element specifies the note type, either eighth or 16th, to which the <first> to <second> ratio is applied. (Issue 283)
• The <sync> element specifies the style that a score following application should use the synchronize an accompaniment with a performer. (Issue 294)
• The <wait> element specifies a point where the accompaniment should wait for a performer event before continuing. (Issue 294)

New Attributes

• The above attribute has been added to the <double> element. (Issue 368)
• The arrangement attribute has been added to the <bass> and <harmony> elements. (Issue 307)
• The after-jump attribute has been added to the <repeat> element. (Issue 322)
• The halign and valign attributes have been added to the <figured-bass> element. (Issue 362)
• The multiple-rest-always and multiple-rest-range attributes have been added to the <measure-numbering> element. (Issue 310)
• The offset attribute has been added to the <release> element. (Issue 203)
• The placement attribute have been added to the <figured-bass> element. (Issue 336)
• The print-object attribute has been added to the <metronome> element. (Issue 355)
• The scaling attribute has been added to the <staff-size> element. (Issue 305)
• The shape attribute has been added to the <bend> element. (Issue 306)
• The smufl attribute has been added to the <effect>, <membrane>, <metal>, <timpani>, and <wood> elements. (Issue 403)
• The smufl attribute has been added to the <wavy-line> element. (Issue 397)
• The staff attribute has been added to the <measure-numbering> element. (Issue 23)
• The system attribute has been added to the <direction>, <ending>, <harmony>, and <measure-numbering> elements. (Issue 37)
• The text attribute has been added to the <inversion> element. (Issue 295)
• The type attribute has been added to the <level> element. (Issue 288)
• The unbroken attribute has been added to the <arpeggiate> element. (Issue 281)

New Values

• The smufl-accidental-glyph-name type used by the smufl attribute of the <accidental>, <accidental-mark>, <accidental-text>, and <key-accidental> elements now allows SMuFL accidental glyphs from the Medieval and Renaissance accidentals and Kievan square notation ranges. (Issue 330)
• The part name value has been added to the list of standard <credit-type> element values. (Issue 282)
• The inverted-bracket value has been added to the enclosure-shape type, used by the enclosure attribute. (Issue 308)
• Eight new sound IDs have been added to the sounds.xml file for use by the <instrument-sound> element. They are wind.flutes.whistle.tin.c (Issue 289) and drum.tabor, drum.tamborim, pitched-percussion.handchimes, pluck.cavaquinho, wind.reed.clarinet.d, wind.reed.clarinet.g, and wind.reed.clarinet.piccolo. (Issue 363)
• Element content for the <ipa> element has been updated to IPA 2015 symbols represented in Unicode 13.0. (Issue 345)
• The highest value for the number-level type, used by the number attribute, has been raised from 6 to 16. (Issue 297)
• The discontinue value has been added to the pedal-type type, used by the type attribute of the <pedal> element. (Issue 302)
• The resume value has been added to the pedal-type type, used by the type attribute of the <pedal> element. (Issue 335)

Removed and Deprecated Features

• The DTD versions of the MusicXML definitions have been deprecated in favor of the XSD versions. This includes the midixml DTD and XSL files, which will not be replaced with XSD versions. (Issue 401)
• Empty <multiple-rest> elements are no longer allowed. This was a mistake in the original definition of the element. (Issue 249)
• The <function> element is deprecated as of MusicXML 4.0. Use the <numeral> element instead. (Issue 295)
• The none value in the clef-sign type used by the <sign> element is deprecated as of MusicXML 4.0. (Issue 304)

Documentation Changes

• The W3C Music Notation Community Group Report for MusicXML 4.0 now includes complete documentation. Previously this was only available for MusicXML 3.0 on MakeMusic’s musicxml.com site and had not been updated for Version 3.1. (Issue 353)
• Help has been added for working around common code generation issues. (Issue 280)
• The <arpeggiate> element documentation clarifies how to export the length of an arpeggio line. (Issue 62)
• The <beat-repeat> and <measure-repeat> element documentation clarifies the behavior of the type attribute. (Issue 287)
• The <bend-alter> element documentation clarifies the meaning of the element content when there are multiple bends on a single note. (Issue 204)
• The <chord> and <duration> element documentation clarifies the behavior of chords with notes of different durations. (Issue 106)
• The <defaults>, <measure-layout>, <page-layout>, <staff-layout>, and <system-layout> element documentation clarifies the behavior when layout elements are missing from the <print> element. (Issue 53)
• The <diatonic> and <octave-change> element documentation clarifies the representation of transpositions of an octave or more. (Issue 333)
• The <dynamics> element documentation clarifies how the relationship of the placement attributes in the and <direction> elements. (Issue 43)
• The <ending> element documentation now describes the number attribute correctly. (Issue 291)
• The <kind> element documentation clarifies how to represent suspended chord symbols. (Issue 352)
• The <kind> element documentation clarifies how to represent N.C. chord symbols. (Issue 349)
• The <level> element documentation clarifies the purpose of the element content. (Issue 146)
• The <line> element documentation clarifies that the element is only needed with G, F, and C signs. (Issue 351)
• The <lyric> element documentation clarifies how lyrics are aligned. (Issue 261)
• The <measure-repeat> element documentation clarifies that the actual music should be repeated in each measure. (Issue 254)
• The <notehead> element documentation now specifies the treatment of the Note name noteheads supplement range added in SMuFL 1.4. (Issue 382)
• The number-level data type documentation clarifies that different values are used to distinguish elements that overlap in MusicXML document order rather than musical score order. (Issue 8)
• The <offset> element documentation clarifies the current musical location at the end of a measure. (Issue 28)
• The <rehearsal> element documentation clarifies that it can be used to represent section names. (Issue 311)
• The staff-type data type documentation now describes the different options more completely. (Issue 292)
• The staff-type data type documentation now encourages the use of an alternate <staff-type> element where appropriate (Issue 205)
• The documentation for the start-stop, start-stop-continue, start-stop-single, and tied-type data types clarifies that multiple elements with the same tag on the same note should appear in musical score order. (Issue 8)
• The <system-layout> element documentation clarifies usage within a <print> element. (Issue 339)