Michael Good and Geri Actor
Reprinted with permission from Proceedings Third International Conference on WEB Delivering of Music (Leeds, UK, September 15-17, 2003), IEEE Press, Los Alamitos, CA, p. 153. Copyright © 2003 by The Institute of Electrical and Electronic Engineers, Inc. All rights reserved.
The MusicXML format is designed to be a universal translator for programs that understand common Western musical notation. We have made significant progress towards this goal, with over a dozen programs supporting MusicXML as of June 2003. We describe some of the ways that MusicXML has been used for file interchange, and will demonstrate several scenarios at the conference.
Many people have recognized the great potential of XML technology to at last produce a universal interchange format for common Western music notation . MusicXML has delivered on this potential, with more support than any music notation format since MIDI.
Figure 1 illustrates the state of software support. The MuseBook, SCORE, NIFF, JMSL, MIDI, and Middle C boxes represent prototypes or product announcements. The other boxes represent publicly available software.
Before the first MusicXML products were shipped in 2001, each major notation program could be used with only one scanning program, except via MIDI files. Finale could only read files produced by the SmartScore product family, while Sibelius could only read files produced by the PhotoScore family. Files from one of the best music scanners, SharpEye Music Reader, could only be read via MIDI import into these programs, or by programs such as MusicEase that built a special SharpEye translator.
Things changed once SharpEye released its first version supporting MusicXML export in September 2001. Using Recordare’s Dolet plug-in, Finale could now read SharpEye’s MusicXML files as well as SmartScore files. Finale is one of nine programs that can now import SharpEye’s MusicXML files. No longer are users of music notation programs locked into a single scanning solution, or vice versa. Scanning companies, including new players like Middle C, can focus more on scanning innovation and less on supporting multiple file formats.
Our initial targets for MusicXML support were Finale and Sibelius. Providing access to either of these popular programs would make MusicXML more attractive to other music software developers. Since only Finale had a plug-in development kit capable of full-featured two-way translation, that became our first product. Our Dolet for Finale plug-in shipped in April 2002, and Finale 2003 for Windows includes a light version of this plug-in.
Providing full-featured two-way translation for Finale has many advantages for interchange. As expected, other programs such as Igor Engraver added MusicXML import so they could read Finale files more easily than if they had to program directly to Finale’s file format.
More importantly, specialized programs have added MusicXML export so they do not have to develop their own advanced notation display functions. The JMSL algorithmic composition program, the Virtual Composer program on the Macintosh, and the Plaine and Easie translator for RISM incipits are examples.
As with scanning, lowering the barrier to entry for notation display can help spur other types of music software innovation. We look forward to seeing the new types of music use enabled by MusicXML interchange.
G. Castan, M. Good, and P. Roland, “Extensible Markup Language (XML) for Music Applications: An Introduction”, The Virtual Score, MIT Press, Cambridge, MA, 2001, pp. 95-102.