Ten Years at MakeMusic

MakeMusic logoThis week marks my tenth anniversary at MakeMusic. It was ten years ago when MakeMusic announced it had completed the acquisition of Recordare’s assets, and I joined the company as Director of Digital Sheet Music.

Five years ago I took a look back at my first five years with MakeMusic. It was a tumultuous time for the company, with two changes of ownership, three CEOs, and a move from Minnesota to Colorado. During that same time MakeMusic put together the pieces that would guide the next five years. Acquiring Weezic led to the launch of a web-based version of SmartMusic. Finale v25 was released as a modernized 64-bit application with a forward- and backward-compatible file format. MusicXML development was transferred to a standards organization at the W3C Music Notation Community Group. Alfred Music also joined Peaksware during this time, bringing music publishing and music notation software under the same ownership.

What have I been doing the past five years? For the most part, it’s been spent building on the structures put in place the previous five years. I’ve kept the same title as Vice President of MusicXML Technologies, and the company moved just nine miles south, from Boulder to a larger building in Louisville, Colorado. I have been working at home in California since starting Recordare in 2000, so the pandemic has affected my work much less than many other people.

Most of my focus has been on getting repertoire into SmartMusic as quickly and accurately as possible. Bringing tens of thousands of pieces of educational and concert music into SmartMusic has required improvements everywhere: in our Finale software, in the MusicXML format itself, and in our SmartMusic software and tools. 


During the past five years, MakeMusic released two major versions of Finale: versions 26 and 27. Finale v27 was especially significant with its support for the SMuFL Standard Music Font Layout, with thousands more notation symbols available than ever before.

Having these symbols easily available means that customers need to use Finale’s Shape Designer much less often. When transferring digital sheet music from notation editors like Finale to interactive applications like SmartMusic, shapes and graphics are notoriously problematic. They are defined in the program as a set of instructions for how to draw the shape. There is nothing that indicates semantically what the meaning of the symbol is. This limits the accuracy with which music transfers from one application to the other.

With SMuFL support built-in, together with greatly expanded music notation fonts, the Shape Designer can be saved for special-purpose graphics that do not have standardized musical semantics. This takes care of one of the major problems in transferring music from Finale to other applications.

In addition, since SMuFL is a standardized layout for music fonts, it makes it much easier to switch fonts in your document and have everything work right – including MusicXML export. With older music notation fonts, custom fonts were difficult to support because you didn’t know what symbol a particular character represented. SMuFL fonts all have the same layout, and also let apps know that they conform to the SMuFL standard.

Naturally, MusicXML support improved with each Finale major and maintenance release. Version 25.4 added MusicXML 3.1 support and Version 27 introduced MusicXML 4.0 support, but each release has come with noticeable improvements. The cumulative effect of all these small improvements over the years becomes really significant. The care taken in our MusicXML export is one reason why Finale is the notation editor of choice for so many companies developing content for their own interactive sheet music apps.

W3C Music Notation Community Group

W3C Community Groups logoFive years ago, the W3c Music Notation Community Group was about one year old and had not released any Community Group Reports. Things have really picked up since then! In the past five years the group has released four reports:

I have served as editor for both the MusicXML 3.1 and 4.0 Community Group Reports. Both releases were big steps forward for MusicXML. MusicXML 3.1 added much better support for SMuFL fonts and changed the standard file extension from the generic .xml to the easily identifiable .musicxml.

I am particularly happy with the MusicXML 4.0 release. It addresses many longstanding issues, including standardizing the connections between scores and parts, and fully supporting concert scores with transposed parts.

However the most significant improvement in version 4.0 may be having the entire specification available as a W3C Community Group Report on the W3C site. This includes examples for every single element in the MusicXML 4.0 format. When MakeMusic acquired Recordare, we finally had the technical writers to put together an online specification at the MakeMusic site. But this was based on proprietary software that could not be easily moved over to the W3C site, nor was it easily updated when our writers changed. When MusicXML 3.1 was released, the MakeMusic documentation did not update with it, causing many developers to miss out on the new 3.1 features.

Adrian Holovaty, one of the Community Group co-chairs, developed an open source Django-based app for creating both the MusicXML and the MNX specifications. While this system automatically generated much of the text content from the MusicXML 4.0 schema definition, the examples had to be transferred manually. We also had to create new examples for all the new features from versions 3.1 and 4.0. The documentation system made this as easy to do as we could, and MakeMusic gave me the time needed to transfer everything over and make it complete.

The easier it is for developers to implement MusicXML, the better their exchange software will be, and the easier it will be for MakeMusic to get music from all sorts of different applications into SmartMusic. Ten years ago there were over 150 applications supporting MusicXML; now that number stands at over 260. One of the main reasons I joined MakeMusic was that the company really understood how standards can improve business, and that remains true today.

Scoring Notes podcast screenshot

Last March I was invited to talk about MusicXML on the Scoring Notes podcast with Philip Rothman and David MacDonald. Tune in there to hear more about MusicXML’s history, and the state of development as we were finishing up work on MusicXML 4.0.


SmartMusic LogoMusicXML import improvements in SmartMusic were largely handled by my colleagues. My SmartMusic projects included adding MusicXML export to SmartMusic’s Compose and Sight Reading Builder apps, and automating part of the production process for our Repertoire Development team.

As we made the transition from classic SmartMusic – the original version of SmartMusic for desktop and mobile platforms – to our new web-based SmartMusic, repertoire needed to be developed for both versions. The repertoire was developed first for classic SmartMusic and then transferred over to the web. Given the speed with which we launched web-based SmartMusic for the 2016-2017 school year, the tools for this transfer were not as good as they could have been.

Speeding up this process for our team gave me a chance to use Contextual Inquiry for the first time in years. It also gave me my first chance to develop in Python – probably the world’s most popular programming language these days. The team estimated that these Python scripts reduced average transfer time from 1 hour to 5 minutes. This allowed them to get more content into new SmartMusic, and also made it much easier to improve existing content.

With last year’s retirement of classic SmartMusic, the team no longer uses these scripts and instead uses new tools for creating content directly for the web. It was well worth it though for the improvements to our repertoire library they made possible over the previous few years.

My main focus now is making it easier to get music from Sibelius into SmartMusic. We are doing that by updating our Dolet for Sibelius plug-in for the first time in five years. Beta test for this version began yesterday! The new version exports MusicXML 4.0 files and takes advantage of features added to Sibelius’s ManuScript plug-in language over the years.

Even though Sibelius has its own built-in MusicXML export, many musicians have told us that the Dolet plug-in provides better results. We believe those results are significantly better in this new version, and look forward to what our beta testers have to say as they test the exported MusicXML files in many different applications.

So the past five years have been busy! These ten years at MakeMusic have really gone like I had hoped. I have been able to work with great teams to push forward the state of the art in digital sheet music, both with our apps at MakeMusic and with the standards developed by the open, inclusive community at the W3C Music Notation Community Group. I can’t wait to see what comes next!

This entry was posted in Finale, Music Business, MusicXML, SmartMusic. Bookmark the permalink.