Michael D. Good
MakeMusic, Inc., USA
Reprinted with permission from Structuring Music through Markup Language: Designs and Architectures, Jacques Steyn, ed., IGI Global, Hershey, PA, 2013, pp. 187-192. Copyright © 2013 IGI Global.
ABSTRACT
MusicXML is a universal interchange and distribution format for common Western music notation. MusicXML’s design and development began in 2000, with the purpose to be the MP3 equivalent for digital sheet music. MusicXML was developed by Recordare and can represent music from the 17th century onwards, including guitar tablature and other music notations used to notate or transcribe contemporary popular music. MusicXML is supported by over 160 applications. The development and history of MusicXML is described in this chapter.
PURPOSE
MusicXML is a universal interchange and distribution format for common Western music notation. It is designed so that a single XML file can be used by a wide range of music software applications. These applications include the display and editing of music notation, the playback and editing of a performance of a musical score, musical analysis, and music retrieval.
MusicXML’s design and development began in 2000, when Internet audio applications were coming into widespread use. Digital sheet music retail sites like Sunhawk were also starting to appear. However, there was no standard format for music notation that compared to the MP3 format for audio. Instead, each application had its own proprietary format. The only way to share sheet music files between applications was with Standard MIDI Files. But MIDI loses a great deal of information when representing music notation (Selfridge-Field, 1997). MusicXML was designed to be the MP3 equivalent for digital sheet music.
MusicXML represents music from the 17th century onwards, including guitar tablature and other music notations used to notate or transcribe contemporary popular music. Since MusicXML was being developed by Recordare, a commercial company, the focus was relentlessly practical. The format needed to support a wide range of Western music of commercial and artistic interest, in a way that was practical for contemporary music notation applications to use.
MusicXML does not represent earlier Western music in its original notation, nor does it represent non-Western music. Most performers who read Western sheet music cannot read early or non-Western music. MusicXML reflects these commonalities and boundaries of musician experience. This makes the markup much more musician-friendly than is possible in more abstract, general-purpose languages. This is important for getting a format widely implemented, as most music notation software developers are musicians themselves (Good, 2006a). Over-abstraction was a fundamental reason why the earlier Standard Music Description Language (SMDL) format (Sloan, 1997) was never adopted.
DESIGN APPROACH
MusicXML models common Western music notation using concepts and vocabulary that are familiar to Western musicians. The basic organization of musical structure comes from the MuseData format (Hewlett, 1997), with additional ideas from the Humdrum format (Huron, 1997). MusicXML extended these designs to support popular as well as classical music, including tablature, guitar chord diagrams, and percussion notation.
Our initial implementations confirmed that MuseData was indeed a good starting point for MusicXML’s design. The basic musical organization mapped smoothly to the music representation of popular music notation editors such as Finale and Sibelius. MusicXML’s element and attribute names are based on the English-language musical terms used in the USA. This makes the format easier to read and understand than those that use either non-musical names or cryptic abbreviations, making the format better suited for archival use.
MusicXML primarily models a document — a musical score — rather than an abstraction of a document. Different aspects of music — the musical structure, the appearance of a particular score engraving, and the interpretive details of a particular musical performance — are all included in a single unified document, mirroring how contemporary music software works. The integration of appearance is especially important, since appearance conveys semantic meaning in musical scores. MusicXML places the musical data in XML elements, and places the visual and performance information (based on MuseData’s print and sound suggestions) in XML attributes or special-purpose XML elements. This element / attribute distinction follows commonly accepted best practices for XML language design (Harold, 2004).
To illustrate, Box 1 shows how MusicXML can represent a staccato middle C. The formatting data assumes standard positioning in the treble clef, and the duration value assumes a definition of 4 divisions per quarter note.
Box 1.
<note release="-1">
<pitch>
<step>C</step>
<octave>4</octave>
</pitch>
<duration>4</duration>
<voice>1</voice>
<type>quarter</type>
<stem default-y="-15">up</stem>
<notations>
<articulations>
<staccato placement="below"/>
</articulations>
</notations>
</note>
Note how basic musical concepts are represented as elements, with print and sound suggestions represented as attributes. Since what is notated does not always match what is performed, MusicXML has separate elements to capture this duality. For instance, the <type> element represents what is notated, while the <duration> element represents what is performed. The default-y attribute for the stem element indicates that the upstem should end one and a half spaces below the top line of the staff. The release attribute for the note element indicates that the played duration should be one division shorter than indicated by the value in the duration element—equivalent to shortening by a sixteenth note in this example.
MusicXML’s approach based on musical semantics differs dramatically from the approach of the earlier Notation Interchange File Format (NIFF—Grande, 1997). NIFF’s graphical format primarily defines notes by their placement on the staff rather than by their musical pitch. This makes NIFF difficult to match to the data structures of contemporary notation programs, or any programs that need to play music as well as display it (Good, 2006b). NIFF’s adoption was thus largely limited to export from music scanning programs, which could use the graphical approach more easily.
Iterative design and evolutionary delivery (Gilb, 1988; Gould & Lewis, 1985) were also critical components of MusicXML’s design approach. MusicXML 1.0 was the 15th iteration of the format as delivered over an initial 4-year development period. MusicXML 1.1, 2.0, and 3.0 have provided further iterations since the version 1.0 release. The MusicXML format was designed in parallel with the software that used it, such as our Finale and Sibelius plug-ins. This continuous design, development, and testing ensured that MusicXML was a practical format to exchange music notation between leading notation applications like Finale and Sibelius, as well as a wide variety of music applications in other domains.
HISTORY
The design and development of the MusicXML format started with the founding of Recordare in January 2000. This design work was preceded by meetings with several experts in the area of computer music formats. Prof. Barry Vercoe of MIT recommended MuseData and Humdrum as starting points for developing a standard format for common Western music notation. Profs. Vercoe, Selfridge-Field, and Huron all provided important early guidance and encouragement in starting the MusicXML project.
MusicXML was introduced in Version 0.1 form at the first International Symposium on Music Information Retrieval (ISMIR—Good, 2000). This initial version was basically an XML version of the MuseData format. MusicXML’s capabilities soon moved beyond MuseData and Humdrum, adding features to support notation of popular music more completely than was possible in either previous format.
MusicXML’s design and development have always proceeded together with implementations to test and refine the language’s design. As of ISMIR 2000, the software included full import and export of MuseData files, partial import of NIFF files and Finale’s Enigma Transportable Files, and partial export of Standard MIDI Files. However, we knew that the format had no chance of being adopted unless it could both read and write files from one of the two dominant music notation editors in the first decade of the 21st century: Finale and Sibelius.
Since creating a standard music notation interchange format would lower the barriers to entry in the music notation software market, these market leaders had little incentive to help Recordare with this project. We would need to create these initial implementations ourselves. Finale and Sibelius both provide plug-in development kits that allow third-party developers to create software for these applications. It quickly became apparent that only Finale’s kit was sufficient for building a two-way MusicXML import/export plug-in, so that is where we focused our implementation efforts.
Once we had a working Finale plug-in ready to test outside of Recordare in May 2001, we started approaching third-party software developers. Graham Jones from visiv had particular incentive to support the MusicXML format. His SharpEye music scanning program was generally considered to be more accurate than the competition. However, since it could only communicate to Finale and Sibelius using MIDI files, much of that advantage was lost. By using the MusicXML format, Finale users could take full advantage of SharpEye’s enhanced scanning capabilities.
In September 2001, SharpEye Music Reader became the first commercial program to support the MusicXML format, with SharpEye version 2.15 supporting MusicXML version 0.5. Recordare developed the Finale plug-in for MusicXML import and export that was first released in April 2002. The makers of Finale then saw that supporting the MusicXML format would improve how music scanning worked for their customers. Finale added MusicXML support in its Windows version in Finale 2003. Mac OS X support was added in Finale 2006, with Mac Universal Binary support added in Finale 2007. Recordare also developed a plug-in to export MusicXML files from Sibelius that was first released in August 2003.
Despite the initial successes with SharpEye and Finale, we waited to release a version 1.0 of the MusicXML format until we had enough experience with a variety of applications to be sure that we would not need to make incompatible changes later. Version 1.0 of the MusicXML format was released in January 2004. Version 1.1 added 70 new features, especially in the area of music formatting, and was released in May 2005. Version 2.0 added 95 further new features, included a compressed zip-based multimedia format, and was released in June 2007. These MusicXML definitions all used Document Type Definition (DTD) technology. A W3C XML Schema Definition (XSD) version of the MusicXML 2.0 format was released in September 2008. Version 3.0 includes improved virtual instrument support and was released in August 2011.
Figure 1 charts the status of MusicXML implementations as of October 2012. Applications on the left side of the chart are shipping; applications on the right side of the chart are in beta or prototype stage. Applications on the top of the chart both read and write MusicXML files; applications in the middle write MusicXML files, and applications on the bottom read MusicXML files.
Figure 1. MusicXML implementations as of October 2012
As of October 2012, MusicXML is now supported by over 160 applications, including all the market leaders in music notation editing and music scanning; major players in music sequencing, electronic music stands, and Internet sheet music sales; and research applications in areas such as music analysis, automatic composition, and visualization.
The MusicXML developer community has been actively involved in the ongoing iterative design and development of the MusicXML format since we began a developer email list in 2001. Many of the best ideas that have moved MusicXML beyond its MuseData/ Humdrum roots have come from other developers in the community. The design of Version 1.1’s formatting features, for instance, benefited from the work of Curtis Morley and the musicRAIN team, as well as proposals by Doill Jung of AMuseTec. Other major contributors include Geri Actor, Don Byrd, Didier Guillion, Bernd Jungmann, Mark Maronde, Mark Olleson, and Christof Schardt.
Around 2000, many formats were proposed for representing common Western music notation in XML format. Only MusicXML is in widespread use by different software applications. Further information about the MusicXML format is available from MakeMusic, Inc. (2012). Recordare’s MusicXML assets were acquired by MakeMusic in November 2011.
MusicXML has become the standard interchange file format for common Western music notation. It is also becoming more popular for distributing sheet music over the Internet, as shown by Wikifonia, Sheet Music Digital, and other websites. At the end of its first decade, MusicXML is well on its way to becoming the digital sheet music equivalent of the MP3 format.
REFERENCES
Gilb, T. (1988). Principles of software engineering management. Reading, MA: Addison-Wesley.
Good, M. (2000). Representing music using XML. In Proceedings of Music IR 2000. Retrieved January 11, 2010, from http://ismir2000.ismir.net/posters/good.pdf
Good, M. (2006a). Lessons from the adoption of MusicXML as an interchange standard. In D. Megginson (Ed.), Proceedings of XML 2006. Retrieved January 11, 2010, from http://2006.xmlconference.org/proceedings/46/presentation.pdf
Good, M. (2006b). MusicXML in commercial applications. In Hewlett, W. B., & Selfridge- Field, E. (Eds.), Music Analysis East and West (pp. 9–20). Cambridge, MA: The MIT Press.
Gould, J. D., & Lewis, C. (1985). Designing for usability: Key principles and what designers think. Communications of the ACM, 28(3), 300–311. doi:10.1145/3166.3170
Grande, C. (1997). The Notation Interchange File Format: A Windows-compliant approach. In Selfridge-Field, E. (Ed.), Beyond MIDI: The Handbook of Musical Codes (pp. 491–512). Cambridge, MA: The MIT Press.
Harold, E. R. (2004). Effective XML. Boston, MA: Addison-Wesley.
Hewlett, W. B. (1997). MuseData: Multipurpose representation. In Selfridge-Field, E. (Ed.), Beyond MIDI: The Handbook of Musical Codes (pp. 402–447). Cambridge, MA: The MIT Press.
Huron, D. (1997). Humdrum and kern: Selective feature encoding. In Selfridge-Field, E. (Ed.), Beyond MIDI: The Handbook of Musical Codes (pp. 375–401). Cambridge, MA: The MIT Press.
MakeMusic, Inc. (2012). MusicXML overview. Retrieved May 12, 2012, from http://www.makemusic. com/musicxml/
Selfridge-Field, E. (1997). Describing musical information. In Selfridge-Field, E. (Ed.), Beyond MIDI: The Handbook of Musical Codes (pp. 3–38). Cambridge, MA: The MIT Press.
Sloan, D. (1997). HyTime and Standard Music Description Language: A document-description approach. In Selfridge-Field, E. (Ed.), Beyond MIDI: The Handbook of Musical Codes (pp. 469–490). Cambridge, MA: The MIT Press.