Interviews

Interview by Jari Williamsson, January 2005

What is your background?

I started piano at 5 and switched to trumpet at 10. I was one of the better trumpet players in our high school and dabbled in composition. But a couple of summers at the National Music Camp in Interlochen made it clear that I would be happiest as a professional in another field. So I went to MIT, got my B.S. and M.S. degrees in computer science, and played trumpet in just about every group there. You can still hear my section trumpet playing in the MIT Symphony Orchestra CDs out on Vox, including my favorite recording of Howard Hanson's Piano Concerto, with Eugene List as soloist.

My bachelor's thesis was done at the MIT Experimental Music Studio, one of the groups that later became part of the MIT Media Lab. That software became part of the Csound package. My master's thesis took me into the area of making computers more usable, where I stayed professionally for 20 years: first at DEC, then at a virtual reality startup, then moving from Boston to California to join SAP. Five years ago, I went back to music software in starting Recordare.

Musically, I switched from trumpet to voice over 15 years ago. I currently sing with choruses in the Silicon Valley area south of San Francisco, including the Stanford Symphonic Chorus, West Bay Opera, and the Cabrillo Festival of Contemporary Music in Santa Cruz.

Did you use Finale before the development of MusicXML?

I started using Finale at version 3.7 for my own compositions.

How did the MusicXML project start?

MusicXML was designed in response to the opportunities posed by Internet music publishing. When Recordare was started in 2000, companies like Sunhawk were already started in the Internet music publishing business.

But all you could do with digital sheet music available for sale in 2000 was 1) print it out or 2) use it in a proprietary music player like Sunhawk's Solero system. These limited uses did not compare well to the flexibility of digital audio available in CD or MP3 format, nor to the availability of Web sites in HTML format.

So while Recordare was started as an Internet music publishing company, most of my time has been spent creating and evangelizing the MusicXML format, together with our MusicXML plug-ins for Finale and Sibelius. We're getting very close to having all the software in place to make our dream of musician-centered Internet music publishing really come alive.

When did you start the development of MusicXML? When was the first version released?

MusicXML development started soon after Recordare was founded in early 2000. It started beta test in 2001, and later that year SharpEye Music Reader became the first commercial product to support it. Finale for Windows started supporting MusicXML 0.6 in Finale 2003. We took a long time to get to version 1.0 because that was our cutoff for making incompatible changes. In 2003 we got some good experience with sequencers, recognizers, and other different types of music programs. MusicXML 1.0 shipped in January 2004.

How would you describe the MusicXML plug-in development route? Where were the largest pitfalls along the way?

MusicXML was developed iteratively with the Finale plug-in, together with some other translation prototypes that we built for diverse formats like NIFF and MIDI. We had difficulty getting started with Finale development due to not understanding the need for 1-byte alignment in C++. Once that was fixed, development was pretty smooth. There was just a lot to do to get good results.

With which tools was the MusicXML plug-in developed?

Version 1 was developed primarily in Visual Basic 6.0, with a large C++ layer for interaction with the Finale PDK. To move to Macintosh OS X, Version 2 was rewritten in Java 1.4, with another large JNI C++ layer for interaction with the Finale PDK. We find that the productivity advantages of writing in memory-managed languages like Visual Basic and Java are so huge that the extra work to make it possible really pays off. This is especially true when you have great development tools available like IntelliJ IDEA for Java programming.

How has MusicXML evolved during the years?

MusicXML started as an XML version of Walter Hewlett's MuseData format, with the addition of key concepts from David Huron's Humdrum format. These were the two leading academic formats for music notation representation and were based on a lot of musical and application experience.

But MusicXML soon had needs that neither MuseData nor Humdrum had addressed. Interchange between programs required more explicit formatting information that either of those programs provided. And of course guitar tablature and other pop music notation is much more important in the commercial world than in academia. So MusicXML's evolution has been driven by the needs of our users - their work and the repertoire that they want to represent in MusicXML format.

How is MusicXML evolving today?

We've just started work on MusicXML 1.1, with the goal of making MusicXML a better distribution format, not just an interchange format.

We plan to add many long-requested formatting features to MusicXML, and come up with a standard compressed version of the format. We are also looking at the possibility of defining a standard container format for MusicXML that could include digital rights management capabilities. But to some extent, the desire for interchange and rights management are conflicting goals. An interchange format wants to be read everywhere, while rights management wants to control use. We will see if we can make some progress there in the 1.1 time frame.

Wouldn't this be almost identical to some aspects of PDF files? PDF files can usually be read/shared by anyone, but they can also be restricted in various ways?

Indeed, PDF files are a leading candidate to be the recommended container for MusicXML files. But for now, current digital rights management schemes for PDF files are oriented towards enterprise applications, not consumer applications for selling small digital sheet music files.

Consumer-friendly DRM schemes like those used in the iTunes Music Store are not yet available for digital sheet music, at least not at prices that are economical for most composers and sheet music publishers. We will see what develops.

Is there anything like CSS (“Cascading Style Sheets”) existing or planned for MusicXML (where the style is separated from the contents)?

In our current plug-ins, your open Finale file serves the purpose of a CSS template. MusicXML files are imported using as many of your document defaults as possible. This is different from the easier approach used by some other importing plug-ins that hard-code things to an unchangeable default document. It's more work for us, but it works much better for our customers overall.

Separating style from content often sounds better in theory than it works in practice. In music notation, formatting conveys meaning, intentionally or unintentionally. MusicXML generally puts the "logical" or "content" aspects of music into XML elements, and details specific to an individual performance or engraving into XML attributes.

How accurate is MusicXML?

The accuracy is a function of both the format and the software. MusicXML software provides the most accurate interchange that has ever existed for computerized music notation programs. If you are trying to capture pixel-perfect page images or bit-perfect audio recordings, MusicXML won't do that, but no other interchange software will do it either.

Which elements will we never see supported in the MusicXML file format?

MusicXML represents common Western music and common Western music notation. So I don't expect we will see elements outside of that domain, such as football statistics, in MusicXML!

I also do not expect to see elements for representing very different musics in MusicXML. MusicXML's success is in part due to its musician-centered modeling of music notation, and the general lack of artificial concepts needed by computers but not by musicians. Once you get outside of a common musical practice, you lose the ability to keep things in musician-friendly terms.

Transferring documents to older Finale versions is an obvious way Finale users can use MusicXML. In which other ways can Finale users use MusicXML?

There are some 40 applications supporting MusicXML, so there are lots of possibilities! Two popular uses are to scan music into Finale and to transfer music from Sibelius into Finale.

But it's being able to work with some of the innovative new music programs out there that is really exciting. You can then create musical scores for great new programs like the MuseBook Score by exporting a Finale file into MusicXML format. The MuseBook Score listens to your acoustic piano or MIDI keyboard and follows along in the MusicXML score, animating notes and turning pages for you automatically. It's just the start of a great new set of applications made possible by a standard music notation format. If you want to hear a computer try to sing your Finale songs, import the MusicXML into Myriad's Harmony Assistant and let their Virtual Singer have a shot at it! In the other direction, people using the algorithmic composition program JMSL are thrilled to now be able to transfer their scores directly into Finale, saving months of drudgery in some cases.

I notice that many 3rd party products that support MusicXML files only do so in one direction (usually import, but no export), which I find very odd for a file interchange format. Do you actively promote the importance of both import/export support of MusicXML files?

It's not true that usually products that support MusicXML in one direction only do so for import. As of today:
- 14 products support both directions
- 15 products support export only
- 13 products support import only

Naturally we promote the importance of both import and export. But software developers, whether companies or individuals, will only implement features that help with particular business or technical problems. MusicXML is designed so that it can be implemented in stages, not requiring an "all or nothing" approach. This is part of its popularity with developers.

Sometimes two-directional support does not make much sense. Scanning programs like SharpEye Music Reader and PhotoScore Professional have no need to read in MusicXML files. They just need to write MusicXML so other programs can read their scanning results. The same is true for an algorithmic composition program like JMSL, or translators from a legacy library format like Plaine and Easie. Playback-oriented programs like MuseBook Score, capella playAlong, and the Xenoage MusicXML Player for MIDI have little need to write MusicXML files, just to read them.

The key choice is whether it is more important for your program to be able to read files from other programs, or for other programs to be able to read your files. Ideally you would usually do both, but often you don't have the resources to do both right away. Different products have different priorities. The number of programs supporting MusicXML continues to increase rapidly, as does the direction and quality of the support.

Are there any tools available so users can manipulate MusicXML files directly?

MusicXML files are text files, so you can always manipulate MusicXML within your favorite Unicode-friendly text editor. Right now, Finale is probably the best MusicXML authoring tool out there. There's not yet a commercial native MusicXML editor. But you never know what the future may bring.

Currently, you’re bundling a MusicXML file version of the music with each "Finale Plus" package on your music publishing site. Do you plan to use MusicXML in more ways in the future?

Oh yes, but the most exciting new things are confidential at the moment!