Iterative design and evolutionary delivery techniques have been used since the 1980s to produce more usable and useful computer systems (Gilb 1988, Good 1988, Gould and Lewis 1985). With MusicXML, we have found that these techniques can also be successful in XML language design. By building software to use the language together with the language itself, we were able to discover and fix the technical problems that would impede adoption – either by making certain music exchange impossible due to gaps in the format, or by making it difficult due to suboptimal design and implementation decisions.
Since MusicXML was designed for interchange between many different types of applications, our first prototypes concentrated on making sure that we could handle applications that focused in very different areas. SMDL’s concepts of logical, visual, gestural (performance), and analytical domains were helpful for this purpose. We built prototypes in Visual Basic 6.0 for each domain that was supported by commercial applications:
We also built two analysis prototypes that worked off of data in the logical domain. These were small Visual Basic programs that showed note duration distributions on a histogram and pitch/duration correlations on a scatterplot.
Once we had successful implementation experience with these prototypes, we moved on to a deeper implementation experience with a real commercial application: a prototype translator from Finale’s ETF format into MusicXML.
While MusicXML started being used in commercial applications with MusicXML 0.5 in 2001, version 1.0 did not ship until January 2004. This delay was to give us plenty of time with different applications so we could be sure that we would not need to make any incompatible changes to MusicXML 1.0 in a future release. MusicXML 1.1 is a strict superset of MusicXML 1.0, and likewise MusicXML 1.2 will be a strict superset of MusicXML 1.1. We feel it is crucial to preserve developer investment in their MusicXML software, and extensive experience with a wide range of music software was crucial to giving us the confidence that MusicXML was sufficiently mature and stable to guarantee this level of future compatibility. MusicXML 1.0 was released after the developer community included people working on diverse applications such as digital music stands, sequencers, algorithmic composition, and tablature editing – not just standard music notation editing and music scanning. By the time MusicXML 1.0 was released there were implementations on Windows, Macintosh OS 9 and OS X, and Linux, using languages such as C, C++, Visual Basic, Java, and ManuScript (a Sibelius-specific derivative of Simkin).
As mentioned earlier, the Macintosh operating system is very popular in the music market. This is especially true for high-end professional users who are natural early adopters. Yet most of our early software development was for Windows only, using the same mix of Visual Basic 6.0 and Visual C++ 6.0 that I had used in my previous position at SAP. Given the universal failure of past efforts at standard symbolic music formats that went beyond MIDI, I wanted to minimize risk from extra factors such as switching development platforms and programming languages at the start of the project. The start of a high-risk project did not seem like a good time to learn a new development environment.
We also did not fully understand the extent of the Macintosh’s dominance of the high-end music market until we demonstrated MusicXML at the industry’s large NAMM trade show in 2002. This convinced us that we had to do a substantial rewrite of our production software from Visual Basic into Java. Our initial Windows-only approach maximized our chances of initial success, but then slowed adoption of MusicXML until our own software was cross-platform. We did get the important advantage of avoiding most of the development costs associated with the transition from Macintosh OS 9 to OS X. Due to the lack of a modern Java version on Macintosh OS 9, Finale’s MusicXML support on Macintosh is for OS X only.