There are probably as many reasons to share a piece of sheet music as there are musicians to share one with. Likewise, there seems to be an endless supply of apps to handle music notation in one way or another. Perhaps the key musical challenge for the digital age, then, is how to capture as much of the musical meaning that a human would be able to interpret from a notation document in a format that a wide variety of software applications can also semantically understand.
For nearly two decades, the vision for this level of computer notation interchange has been a manifest reality in the MusicXML standard, originated by Michael Good at Recordare, which in 2011 became part of MakeMusic. As an active (read: highly in-demand and thus extremely busy!) MakeMusic developer and VP of MusicXML Technologies, Michael continually advances our ability to convey and interpret the practical musicality encoded by notational symbols and their digital representation. I asked him if he’d write me a bit of a retrospective on MusicXML, the state of the technology today, and where it might be headed.
You’ve had quite a career in a diverse range of roles. What experiences brought you to the place where you saw the need for MusicXML?
The first 20 years of my software engineering career was spent making computers easier to use. There was no music software industry when I entered the job market. MIDI hadn’t even been invented yet! Around 1999 we were seeing the first wave of digital sheet music companies like Sunhawk. That was exciting, but I quickly discovered that you couldn’t move sheet music from one app to another, say from Finale to Sunhawk. You could use PDF, which could display music without playing it, or you could use MIDI, which could play music but not display it very well.
We clearly needed a digital sheet music standard that could both display and play music notation. I was at SAP at the time and we were using XML to communicate between our R/3 system and other application software. I thought, why couldn’t XML do the same thing for sheet music? My bachelor’s thesis at MIT had been on a computer format for music notation, so I discussed this thought with my thesis advisor, Barry Vercoe, to see if I was missing anything. He liked the idea and advised me to meet with Walter Hewlett, Eleanor Selfridge-Field, and David Huron, the leading academic experts in this area. At that point I left SAP to start my own company, Recordare, to develop MusicXML as a standard format.
What is it about MusicXML that has made it such a widely-accepted standard?
By 2000, many people had tried to create a standard music notation format but none of them really caught on. I tried to learn from those experiences to give MusicXML several advantages.
For one, I was working on this full time: my background as a professional software engineer and serious amateur musician was ideal for the job. I applied what I knew about usability to make the format accessible to developers and musicians. For instance, while I had a strong technical base in XML that was accessible to developers, each data type has a name taken from a musical concept, not a cryptic computer abbreviation. The basic structure was based on Walter and Eleanor’s work on MuseData, including ideas from David’s work on Humdrum. It was important to build on the best of the prior art.
The key lesson from previous attempts at a music notation standard was that no matter how nicely MusicXML was designed, nobody would care unless we had two-way exchange with either Finale or Sibelius. That I would have to build myself; at that point, Finale had the only plug-in technology for third-party developers that made a two-way translator possible, so that was what I had working first.
Once I had a Finale plug-in available, I could convince Graham Jones to add MusicXML export to his SharpEye Music Reader product. SharpEye was the best music scanner on the market back then, so its MusicXML export attracted Coda to include MusicXML in Finale 2003 for Windows (later appearing in Finale 2006 for Mac). Things snowballed from there!
Do your interactions with Finale development also benefit MusicXML?
Absolutely. Now that MusicXML enables accurate sharing of digital sheet music, musicians demand greater and greater accuracy. Often that requires adding new features to the MusicXML format. We can test out many new features by implementing them in Finale, then finding another app to implement it so we know the exchange works correctly. We want to be careful not to bias the format towards Finale’s particular way of doing things.
What was the advantage to transferring development of the MusicXML spec to the W3C Music Notation Community Group, and what progress has been made since?
When I was starting out at Recordare, people in the music products industry gave me two invaluable pieces of advice. One was to not charge anything for the MusicXML format, or nobody would use it. The other was to not move to a standards organization too soon, as that could slow our progress at a time when we needed to move very quickly and opportunistically. PDF was a more appropriate model, as a free standard format maintained by a single company. This arrangement worked well, as most companies viewed Recordare as a neutral, independent third party.
When MakeMusic purchased Recordare’s assets in 2011, this model no longer made sense, because MakeMusic was too much of a competitor to other companies. Joe Berkovitz from Noteflight encouraged me for years to transfer MusicXML over to a W3C Community Group. When Steinberg agreed to transfer their SMuFL music font standard as well, we knew the time was right.
MusicXML now has an open organizational home that is appropriate for its more mature status. After MusicXML was moved to the W3C, we were able to release MusicXML 3.1 in December 2017 with 65 improvements. This was the first MusicXML update in 6 years. We are now collecting issues for a possible MusicXML 3.2 release.
Why was MusicXML chosen as a preferred format for uploading content into MakeMusic’s upcoming digital sheet music sharing and practice solution?
What else would you use? Under the hood, Finale and MusicArchitect are very different music notation technologies. Many developers have told us that Finale has the world’s best MusicXML export. MusicArchitect has perhaps the best MusicXML import of any web-based platform. MusicXML is the way that these two distinct programs can communicate in musical ways to both display and play the music, both with Finale-created documents and MusicXML files created by other programs.
How has your work on that project influenced what we might see in new features for a future version of MusicXML?
One big thing that has come up from this work is the need to be able to transfer parts together with scores between applications. We have been able to do that within MusicXML 3.1, but we want to make this a real, documented feature that works well among many different applications. We would also like to improve MusicXML’s support for scores in concert pitch.
Another idea for MusicXML 3.2 is to better support applications like SmartMusic that listen to performers as they are playing from their part. MusicXML could also do a better job of clarifying and documenting many details for application developers. Note: a full list of current issues for MusicXML 3.2 can be seen at the W3C GitHub repository: https://github.com/w3c/musicxml/milestone/2.
Anything else you’d like to tell our Finale blog readers?
When MakeMusic acquired Recordare, one of the main reasons was to be able to move SmartMusic to new technologies that would work better for web and mobile devices. The upcoming sharing and practice features are a logical extension of both that project and the dreams that led me to start Recordare 20 years ago. It is very rewarding to see all this work come to fruition, and we look forward to seeing musicians’ reactions to the new features!