Michael Good, the inventor of MusicXML [transcript]


A long-standing request that our readers and listeners have made is to have access to transcripts of our most popular podcast episodes.

Here, in celebration of Michael Good’s upcoming retirement, and to honor his impact and legacy to our field, we are pleased to provide a transcript of our podcast episode “Michael Good, the inventor of MusicXML”, which first aired on March 13, 2021 and subsequently re-aired on February 22, 2022.

Michael Good, at a meeting of the W3C Community Group at the 2018 NAMM Show

Michael, is, as the title of the episode says, the inventor of the MusicXML interchange format for music notation, and is currently the vice president for MusicXML technologies at MakeMusic and co-chair of the W3C Music Notation Community Group, positions he will be retiring from in January 2023.

Below, enjoy a live transcript where you can listen and follow along (just press the play icon), or below that, a more static readable format.


Philip: Welcome back everybody to another Scoring Notes podcast, where we talk all about music notation software and related technology. And this one is a rerun, but with a quick update.

I’m back with David MacDonald, my cohost. Hi David.

David: How’s it going, Philip?

Philip: It’s going great. So we had a discussion with Michael Good, the inventor of MusicXML, just a little less than a year ago. And it went really well. MusicXML, as you know, and many of our listeners know, is the interchange format that many hundreds of applications, music applications, including all the ones that we speak about on this program, use to exchange musical information with each other.

And we thought we would re-air the interview that we had with Michael, because he talks all about how MusicXML came to be in light of the fact that there have been a couple of important updates to MusicXML in the year or so. That’s passed since we talked to Michael.

David: Yeah, MusicXML. One of the things that might not be obvious, because it is not itself a product that you buy, but it is in active development and changing all the time. New products are coming out to support it, and being updated to support the new features and standard of MusicXML, and so we’ve had some news in that arena.

Philip: Absolutely. The first of those is that MusicXML 4.0, which Michael actually talked about, that was to come at the time that he spoke with us, has now been released. It was released, pretty much concurrently, with Finale version 27 in June of 2021. And there are a lot of new features in MusicXML 4.0, or four point zero, if you like.

Some of the biggies are things like concert scores with transposed parts, the relationships between the score and parts, there’s a standard way to combine the score and parts in a single compressed dot MXL file. There’s score-following assessment tools, which was a very important part of the Finale version 27 update. Swing playback, Roman numerals, Nashville numbers.

And crucially, I think for a lot of people that rely on MusicXML, the complete documentation is now on the W3C site, including examples of every MusicXML element. And that is the consortium…

David: The World Wide Web Consortium. They define how web pages can be, or should be structured, so that your browser can read them whether you’re in Safari or Firefox or Chrome, or whatever you’re using. And they also maintain a lot of other technical specifications that are adjacent to that sort of thing, such as the MusicXML standard.

Philip: Exactly. Yeah. And specifically the Music Notation Community Group, of which MusicXML and SMuFL are now under the purview of that Community Group. And so there’s a lot of good stuff in MusicXML 4.0,

And then the other important development is that for the first time in six years a plug-in, specifically the Dolet plug-in — which used to be, you know, sold by Recordare, which was Michael Good’s company at the time — is now a free plug-in that you can get to use in Sibelius. Even though Sibelius has its own way of exporting MusicXML, the Dolet plug-in does things in a different way. And, so depending on what type of result you’re trying to get out, you might get a lot better results using the Dolet plug-in.

And that has been updated for the first time in almost six years. The last time it was updated was April 2016. So that came out fairly recently, January 20th, 2022. And there’s a lot of new stuff in what is called Dolet 8. The previous version was still at 6, so they skipped right over Dolet 7.

Dolet 8, of course, adds MusicXML 4.0 support, including a lot of 3.1 features that were not available in the last Dolet version of the plug-in. And many of those features include some of the same features that I just mentioned.

The other important thing, and this is specifically Sibelius-related. They support a lot of the ManuScript changes that Sibelius has made over the past five years. ManuScript, of course, being the plug-in language that Sibelius relies on for plug-ins. And you can look at Scoring Notes to see the full list of those.

So David, some really cool things in the world of MusicXML. This was a fun interview with Michael. He’s a great fellow. A tremendously important person in our field, and we’re excited to re-share this interview with you right after the break.

David: Enjoy.

Philip: Okay, welcome back everybody to another Scoring Notes podcast. I’m Philip Rothman and once again, I’m joined by my co-host, David MacDonald.

David, how are you?

David: I’m doing great. It’s good to see you again, Philip.

Philip: Yeah, it’s great to see you too, David. Happy “almost spring”.

David: Almost spring. It’s approaching 70 here, so it’s, it’s getting good. Yeah.

Philip: That’s a good omen of things to come. You know, we are coming on spring, you might recall that we actually started this podcast in the spring of last year.

David: Wow. Yeah, I didn’t put that together.

Philip: And, I was just wondering, David, since it is almost spring, we played a little game a couple of weeks ago, you might recall.

David: I recall.

Philip: So I have a little bit of a quiz for you this week instead of a game. Do you have any idea how many episodes we’ve actually done to date?

David: 34.

Philip: That’s not a bad guess. We’ve actually done 42. 42 episodes. Yeah. Which is pretty remarkable.

David: That is pretty good.

Philip: So the second part of this quiz… I’ll give you a point for that one.

David: Very generous of you.

Philip: The second part of the quiz, though, is: In what percentage of those episodes have we talked about MusicXML?

David: In what percentage? Oh gosh, I would guess it’s darn near a hundred. I’m going to say a hundred percent.

Philip: I’m going to play a little montage, if you will, to give you a sense of it. And we’ll see if you are proven correct.

David: Oh gosh.

Philip: Okay.

FX: They can be MIDI files. They can be MusicXML. They can be native notation files.

There’s even a MusicXML version of The Rite of Spring on MuseScore.com

With the MIDI file or with a MusicXML file, because those are different kinds of data…

You can export, like, whatever, XML…

Using MusicXML in the process.

Actually, its MusicXML output was impressive.

All kinds of applications make MusicXML, including Sibelius.

But it also helps that MusicXML has a very tight relationship with Finale.

I know more about MusicXML than I ever thought I would in the world, ever.

I guess MusicXML, you know, is the quick answer…

But it also does the MusicXML output.

Obviously MusicXML has been supported by hundreds of different applications of all different stripes…

There’s a really, really good MusicXML importer…

And so MusicXML itself has recently adopted various bits of SMuFL…

That lets you either tweak the MusicXML that you’ve imported…

Michael Good of MakeMusic, and MusicXML fame.

Philip: If it’s not a hundred percent, it’s darn well close.

David: It’s pretty darn close.

Philip: Yeah. Well, we have of MusicXML fame with us today, Michael Good is here, everybody. It is a crying shame that we haven’t invited you on sooner than that, but maybe we just had to lead up to that point with everybody speaking about it.

So, Michael Good, the inventor of MusicXML, welcome to Scoring Notes.

Michael: Thanks so much, Philip. Thanks so much, David. Great to be here, and I can view the delay as waiting for the headliner to come on.

David: Yes, everything else was just an opening act for this.

Philip: Yes, that’s right.

Michael: I did notice that both of my Notation Community Group co-chairs were invited before me. So…

Philip: You are observant, Michael. Yes, that was Daniel Spreadbury and Adrian Holovaty, the last two practitioners of MusicXML on the podcast before we got to you, and Daniel teed you up so nicely with his intro there, I couldn’t have said it any better myself. But yes, the three of you as the triumvirate, and we have already had Daniel and Adrian on the show.

David: This is what’s known in podcasting is hitting for the cycle. I think.

Philip: Yes, yeah.

Michael: It is such a delight to work with them in the Community Group. So much fun.

Philip: Oh, you guys are just doing tremendous work. I am so eager to talk to you, and I know David is as well, about everything to do with what we’ve been talking about on the podcast and the decades of experience that the three of you have had, and others in that working group, really making the tools that we use every day and are the beneficiaries of.

And it reminded me of a time, not too long ago, at NAMM — at the NAMM Show. And for the past couple of years, I’ve hosted a little gathering, this was of course before the pandemic, where an opening night reception and a bunch of us get together in the music notation corner of the universe.

I was talking with a developer, and I honestly can’t remember who it was or what the app was, but we were just introducing people and introduced himself and he asked you, “Oh, well, what, what is it that you do?”

And in your very characteristically humble way, I think kind of maybe hemming and hawing, and I just had to say, “Look, man, this is the guy that makes what you do possible.” You know, I’m sure, Michael, you would say that you’re building the shoulders of giants, but nevertheless, as evidenced by that opening montage, and it was quite tongue-in-cheek, but really.

In all seriousness, it is something that we rely upon without even thinking about it. We just I think it was actually our last guest, Dan Kreider, said that we tend to disembody the people that create these tools and create these conventions. But no! There was a guy, his name is Michael Good and he created MusicXML. So he’s here.

I’m going to stop talking. And, with maybe just the requisite introduction to say that, michael, you are the vice president of MusicXML technologies at MakeMusic.

Michael: Yes, that’s correct. Before that he was the founder of Recordare, which was really the originator of the MusicXML and Dolet product.

Philip: So, give us a little background, to the point of really understanding a little bit about how this standard, which we take for granted so much, came to be. Like, David have we — I don’t even know if we’ve actually said on the podcast what MusicXML actually is.

David: We have maybe, like, tried to give a four to eight word definition of it, but I think it would be really useful to hear Michael’s definition of it, because I think we only understand it at a very surface level.

Philip: Agreed. Michael, what is MusicXML, anyway?

Michael: MusicXML is the standard interchange format for music notation applications. So if you want to get sheet music, music notation, from one application to another music, MusicXML is what you use do that. That was its goal starting out, and we’ve actually accomplished that.

Thanks to the interest of the community, we have over 250 applications these days that are supporting MusicXML in some form or another.

Just about every serious music notation application has some form of MusicXML support in it.

Philip: So, why would we need something like MusicXML?

Michael: Back in the old days, in the previous century…

Philip: Yeah!

Michael: …the best thing that you had for going back and forth between different programs with music notation was MIDI. And MIDI was never designed for music notation, and it’s actually quite a tribute to MIDI’s strength and the cleverness of the engineers that it was actually able to be used, as well as it was, for music notation.

But it wasn’t meant for that. It’s meant for performance between electronic instruments and originally, you know, very much a keyboard oriented model. There’s a lot of information you need for notation that just isn’t in MIDI. You cannot tell the difference between a C-sharp and a D flat. It’s just, whatever note number that is there.

It doesn’t recognize enharmonics, it doesn’t have notes, really. It has a note on, and it has a note off, but it doesn’t have a unified concept of a note that has a quarter note value or a 16th note value. So you have to interpret that, which gets challenging because performances, unless you’re doing to a click track, they’re not so quantized.

And so, things flow and it’s hard to guess what the actual symbolic notation is behind the performance that you’re doing. And so a lot of what MIDI import is, is guessing for putting it into music notation. And there are some apps like Digital Performer that do a particularly good job of guessing, but it’s nowhere near as good and robust as having something that is custom-built for the purpose of music notation interchange.

Which is not to say this was a new idea with me. I mean, there were tons of prior attempts at using notation interchange formats, but nobody ever implemented it because it was just ridiculously complex and nobody could figure it out.

David: What would you say is the thing that sets MusicXML apart from some of those other formats?

Michael: It’s designed for the purpose of music notation interchange, and it was designed together with the implementations to make it practical. One of the things that somebody said really made the difference was, my relentless practicality in doing the

David: So when you say designed with the implementations, you mean designed with the applications in mind who would use it, as opposed to designed as an abstraction.

Michael: Designed with the actual implementations for those applications. So it started off with me doing all, that, early on a MuseData converter. MuseData, being one of the academic formats that MusicXML 1.0 was based on. And doing a MIDI output and early stabs at trying to get to Finale and Sibelius, it didn’t work quite well, but were enough for a proof of concept.

Philip: You were not the first person, necessarily, to try to solve this problem. You’re talking about the other types of formats, perhaps. Like you said, Michael, just a moment ago, when MIDI interprets something, it does it in a very different way. There’s no real concept of a quarter note, per se. It’s just this note value that has note on, note off at this you know, zero to 127 position and the software will do with it what it will.

I’m quite interested to understand a little bit, like, your background in terms of where you were coming from and identifying this problem. And, you know, your relentless practicality, what made you think that, first of all, it was a solvable problem? And the second part is how you would actually go about solving it, that wasn’t being achieved in the other formats that had already been.

Michael: Sure. Sort of like the origin story. So let me go back a little farther. My first attempt at music notation software was actually at my bachelor’s thesis at MIT.

I’ve heard of that school!And this was cool. And I was working in the Experimental Music Studio at MIT with Barry Vercoe, which later became part of the Media Lab.

But this was before there was even MIDI. This was years before MIDI came out. So there was no music technology industry at that point. So it was like, well, this is a lot of fun, but it’s not going to, like, pay the bills when I get out of school.

So for grad school, I switched into usability and I did usability work for the first 20 years or so of my career.

And so, fast forward to 1999. I’m working at SAP doing usability things. We had delivered the first really web-based application for the SAP enterprise products. And it was clear that what all our customers wanted, not just at SAP, but throughout the world was, for user interface, was move everything from desktop to the web. I was like, okay. That was really fun the first time, but it’s not going to be fun the next hundred times. So I’ve got to find something else to do.

Philip: Yeah, which seems inevitable now.

But of course that was a very conscious decision that had to be made at that time.

Michael: Yeah. That was where things were going, and that’s what customers wanted. And nowadays, you know, music notation is getting more and more on the web as well, which is awesome. But back then, it was like, okay, usability is going to go into this deep freeze. You know, nothing’s going to happen innovative for a long time, which is exactly what happened.

Nothing innovative happened in user interface from 2000 until the iPhone was introduced in 2007. So seven years, that would have been sheer misery to work in that field for me.

So it’s the height of the internet boom, right? And we’re starting to get, Sunhawk and folks who are doing downloadable sheet music.

I was like, whoa, this is really cool. Let me download some sheet music. Oh, wait… can I bring it into Finale? Can I do anything with it? Can I arrange it? Can I share it with someone?

No! All I can do is use it in Sunhawk.

Philip: Which is a company that we haven’t even mentioned on this show yet, but actually was one of the early purveyors of downloadable sheet music.

Michael: I didn’t hear of it till I went to my first NAMM. But Sunhawk was the one getting the press in this downloadable sheet music.

And it’s like, well, that’s really cool, but who’s going to want this unless we have a standard format to go back and forth between different notation applications. And so the goal was let’s make an MP3 format for sheet music. And, while MusicXML has been very successful at the business to business level, when music professionals are sharing things back and forth, it’s still not a consumer level MP3 format because there are all these licensing and rights and issues and creative control issues.

So that’s still something that we haven’t quite cracked yet. But even just having those, the standard to go back and forth between programs, it was clear that that needed to happen. And at SAP, where we were using this technology called XML to go back and forth between our R3 system and all these other apps.

And I was like, well, gee, you could… you could use that for sheet music, couldn’t you? So I was SAP’s representative to the MIT Media Lab at the time. On one of these meetings, I described what I wanted to do: Hey, I want to use XML and make this digital sheet music exchange format. I know people have tried this before, right? And it’s failed. So, am I missing something? Should this work? Who should I look to?

And he said, there’s no reason why it wouldn’t work.

The folks you want to look at are Walter Hewlett and Eleanor Selfridge-Field who are doing MuseData for musicology. Then they have a very good format at Stanford. And talk to David Huron, who’s at Ohio State, who’s doing Humdrum for music analysis applications. Those are the two best academic work that is doing the type of thing you want to do.

Michael: So I talked with them in late 1999. And they said, yeah, it seems like it should work.

So January 2000, I quit SAP, and the next week I started Recordare for the purpose of doing MusicXML.

And it’s the classic way you’re not supposed to start a company. It’s the “Field of Dreams” business model: Build it, and they will come. Here’s this problem. We got to solve this problem with the standard. And how do you make money on it? We’ll figure it out. If this is solving a problem, we’ll figure out a way to make money at it.

Because as somebody said a couple of years later, you know, MIDI became successful in part because there’s no royalty fee on it. If we had charged even a one penny royalty, nobody would have used it. You cannot make money on the standard. You have to make money higher up on the chain. So that was very, very good advice.

Philip: That’s great advice. And a lot of businesses have started in much the same way. A lot of successful businesses have very humble origins in that same fashion. And I want to get into the reason why XML became the way that you implemented this in a moment. But I want to first talk a little bit about the timing of it.

You know, you’re mentioning the late nineties, the early two thousands. David, when was it that you started using music notation software? I think you started using Sibelius, wasn’t it?

David: This would have been in probably the late nineties, ’98, ’99, something like that.

Philip: I remember seeing a demo of Sibelius for the first time, in my last year of grad school at Juilliard in 2000, it was. It was the spring of 2000, it was actually, it was probably Jonathan Finn came to New York to demo the software for us then.

It became clear for the first time that soon after there were going to be a lot of people working in one or the other.

And like you both have said, there have been other products throughout that have tried to do this, but really Finale was the market leader in terms ofthe first software to really take hold at a mass level. And then Sibelius became widely adopted. So you had this issue of needing to start transferring files back and forth.

And so Michael, it’s really interesting that you said if you started to charge a royalty for it, then you would have been out of business. And so you needed to actually make the standard free so that it was seen as acceptable. And probably the fact that you were not — at that time, anyway — affiliated with one or the other of these companies, kind of made you in a position to be able to pursue this as a way of the broker, so to speak.

Michael: We were like Switzerland. We were the neutral site that people would trust. I was in both the Finale and the Sibelius beta programs simultaneously, and both knew it, you know. That a secret, but that established the trust. Nobody got confidential information about the other from me. It was just to make the exchange work better between the applications.

And when I started with MusicXML, it was, if I can’t do two-way communication with either Finale or Sibelius — I don’t really care which to start — but if I can’t do it with one or the other, nobody is going to care about this.

If I can’t figure that out within a couple of years, you’re going to have to give up and do something else.

Philip: Yeah. So that was becoming evident at that time.

What was it about XML? So we toss around this phrase, XML, MusicXML. XML, of course, stands for Extensible Markup Language. MusicXML is a type of XML.

The long and short of it, as I understand it as someone knowing virtually nothing about this, I can actually open up a MusicXML file and I can see in there terms like, “note”. Musical terms… “measure”. As opposed to opening up, let’s say a Finale or a Sibelius file, which are proprietary formats, you can’t read them without the software itself, which is under lock and key.

So what was it about the XML format that made it so appealing to your concept of creating this interchange format?

Michael: Well, it was, as you say, it’s human readable. The most important thing is that XML had a lot of investment behind it from all sorts of parts of the computer industry that are way, way bigger than the music notation industry, which is like everything else, right?

So you had tons of investment, which meant there were tools to read and write XML files on whatever developer platform you wanted to use.

So you don’t have to worry about building a parser You just use the parser, or you figure, you then have to figure out, okay, this musical representation, how do I translate MusicXML’s concepts back and forth to the concepts that I have in my application and not have to worry about the “down and dirty” of the parser.

And nowadays, this is all taken for granted. You can do this with XML, you can do it with JSON, but back then this was a big deal. So it was just clear that here’s the standard that people use for exchange, and it was meant for documents. if you’re doing just data exchange, JSON works great. I mean, we didn’t have a choice 20 years ago. JSON didn’t come around until much later, but XML is really good for documents, because order matters. Order is part of the semantics of things. It’s not just a database dump. There are a lot of structuring tools that, for complex things like musical scores, it just works. You can make things support these complicated documents with complicated semantics.

David: It’s really interesting to hear you describe that, Michael. Thank you for, getting into that detail. It’s worth, I think, clarifying for anyone listening to this, what we mean when we say semantic, because that’s such a critical concept here, is that what Michael was saying is that MusicXML is describing what is there. Kind of like what Philip was saying, in terms that we understand. It’s saying what the thing means, what it is, instead of being quite so graphical. Like if you were to export a PDF file from your notation application and you open that in Preview on your Mac or Adobe Acrobat Reader or something like that, it knows what the shapes are, but it doesn’t know what a quarter note is.

Whereas MusicXML understands what a quarter note is and relies on other applications to know what that means a quarter note should look like in that place. That’s, I think, a really interesting point of MusicXML and how it gets used, and why it can be so flexibly used by a lot of different applications than something like the more proprietary formats, addition to all the licensing things that we’ve kind of touched on.

The idea of having a semantic format that is, at least in some strange nerdy way human readable. You mentioned JSON which is a more recent system of structuring data in a text file, that is JavaScript object notation, as opposed to the extensible markup language, which is super nerdy. And I apologize to everyone. but…

Philip: We’ve gone there again, David.

David: Yeah, yeah.

Michael: You told me this was nerdy.

David: We did. We did do that, didn’t we? I just want to, like, make sure that nobody’s like feeling totally left in the nerd dust behind us.

But JSON is another way of encoding semantic data that is newer. It’s interesting that you’re continuing with XML.

That’s an interesting thing to unpack why you made that decision, I don’t know. Maybe it’s only me and the whole planet that’s curious about that.

Philip: Well, there’s more than just one of us that’s curious, for sure. But to take it to something that you said, David, was, you know, we talk about these terms that we can see in a MusicXML file and understand what they mean whether it’s “pitch”, “step”, “octave”, “duration”, “stem”, “notations”, “articulations”.

We understand what those are. You know, you talked about that semantic understanding. Let’s just think of just eight eighth notes in a bar, okay? Now, in MIDI, if they are all the same eighth note, you know, with that “note on”, “note off” message, Michael, that you mentioned earlier, they’re all going to look the same and the software will bring it in, in whatever default beaming pattern, let’s say, that it is pre-programmed to do,

But in MusicXML, you can say, Oh, this, note is beamed to this note. And this note was beamed to this note. And they’re the same eight eighth notes. Maybe it’s a, three-three two, maybe it’s four and four. Maybe it’s two, two, two, two, maybe it’s two, three, two, whatever, what have you, I guess that’d be seven, my math is not so great.

But whatever it is, that has a very different meaning, each one of those, to the performer. That is really the advantage of MusicXML and that’s what mean when we talk about a semantic understanding of the data. So that’s probably why it has continued to evolve and be successful at what it has aimed to do.

Michael: Yeah, thanks. That’s a great summary of it. Use that usability experience from 20 years of usability things, it applies to doing programming languages too. Because you have to market to developers. Yeah, I mean, I said, if it didn’t work with Finale or Sibelius, nobody would care. That’s true. If it was totally incomprehensible, nobody would care either. So you want something that a developer can understand and map their concepts onto the concepts of the language and something that’s easy to work with.

I use that text formatting all the time, because when I’m adding an export feature to Finale or to the Sibelius plug-in, I do a regression test where you compare different files to see how the old version and the new version works to make sure that you’re not introducing any bugs while you’re introducing the new feature.

Wow, it is so much easier to do that, when you can compare text files and you can see that, ah, yes, I added swing notation into MusicXML 4.0. Look, it says right there. Swing in playback. Okay. It worked!

And it’s not saying swing on something that is straight eighths. Excellent. Great. It worked.

Philip: Again, I mean, every time I learn something new. And you’re talking, you’re literally talking about like the “Compare” feature in some sort of markup editor and just seeing what the differences are between the two and because it’s XML, you can very clearly do that. That’s incredible.

Let’s talk about the development side, because you just mentioned it a moment ago. And hooking it into Finale and Sibelius because that was really what made the feature… well, I don’t want to even really call it a feature.

So, you know, we separate this out. We have MusicXML, which is the standard. And then you have the product, which was your business, Recordare, and the actual plug-in that you had to purchase, and you had to buy for Finale on Mac, Finale on Windows, what have you. And so tell us a little bit about what that was like and getting people, convincing people, and getting them to use this.

Michael: Sure. I got stuck in the development of that for a while, and then went off on a side track, which I shouldn’t have done. I should have asked more people about help early in the game. But I got unstuck, and I was able to figure out how to do the Finale plug-in.\

The Sibelius plug-in I only was able to figure out thanks to some random message on a Sibelius plug-in developer mailing list about some missing feature that I don’t remember what it was… oh yeah, it was writing out a text file. It appeared that you couldn’t write out a text file from the ManuScript language. You could, it just wasn’t in the manual! Oh, okay. So…

Philip: And that actually one bit of misinformation delayed your Sibelius development.

Michael: Delayed Sibelius things by a couple of years, probably. It wouldn’t — it wouldn’t have changed the emphasis on Finale versus Sibelius because Finale’s plug-in language lets you do everything for both import and export. And Sibelius’s plug-in language really only lets you do export. You could do import, but because you couldn’t, like, create tuplets from a plug-in way back when, in Sibelius 2, 3 days. It wouldn’t be any better than MIDI. So what’s the point.

Philip: Hmm, Sibelius still hates tuplets to a certain extent.

David: Yeah. I’m sure if any of our listeners have used Sibelius for quite some time, they will remember that the early days, if you were trying to copy and paste something, if a tuplet was involved, it would just say, no, you can’t do that, because this copy-paste operation intersects a tuplet.

Michael: Yeah. So it was just, Finale had this plug-in developer kit for doing C++ plug-ins, while I did C++ with some Visual Basic for the original Windows-only version of these plug-ins. You’ve gotta be kidding.

Philip: I remember that there was a Windows version and…

David: Mashing up C++ and Visual Basic sounds like, you’re gonna cause the world to collapse in on itself.

Michael: The plug-in had to use C++ in order to load in Finale. But my boss at SAP had said, life’s too short to program in C + + plus, so we used Visual Basic a lot because Mac was in its low point around that time. So we did Visual Basic. And I thought since I was doing something hard enough anyway, I want it to just take over the tools that I already knew and could be productive with and not try to change tools at that point.

Then of course, we went to the NAMM Show where every single one of our target users at NAMM 2002 was using a Mac. Every single one. It was a hundred percent. It wasn’t 99. It wasn’t 98. It was a hundred percent.

Philip: A little bit of market research there.

Michael: Yeah. So then we rewrote it into Java because I still didn’t want to do C++. So, and to this day, the Finale plug-in is mostly with Java.

But anyway, doing this plug-in for Finale. Tried to do it with Sibelius, but couldn’t. So gave up and just focused on the Finale part for a bit.

Then we saw this music scanning product, and SharpEye version 2 came out in 2001 and you look at, and you go, wow, those results are so much better than what you could get at the time with PhotoScore and SmartScore and the versions way back then. However, if you wanted to get that SharpEye input into Finale or Sibelius — well, especially into Finale — you have to go through MIDI which, like, lost all the good stuff…

Philip: defeats the purpose. Yeah.

Michael: …that you got in the scanning program. So once I had the Finale plug-in starting to work, I contacted Graham Jones at a visit and said, Hey, why don’t you this MusicXML export, so that all that great scanning stuff that you have, we can bring it into Finale, because I can bring MusicXML into Finale and he said, well, I export NIFF. Why don’t you build a NIFF-to-MusicXML converter? And I said, no, no, we’re not doing that. Here’s this opportunity for you to do MusicXML and it’s just Finale now, but there’ll be other products later.

Well, I mean, it’s a standard software developer thing, you know, why, why should I do, if I can have somebody else do the work instead of me, this is a benefit, right? So, I mean, I would’ve been surprised if he hadn’t tried that.

So, but then, in 2001, I got to do a demo for the MakeMusic folks. Tom Carruth, who was one of the product marketers for Finale at the time. And he liked what he saw and he saw the possibilities for Finale’s backward compatibility issue where you couldn’t open a file created in a newer version in an older version.

When SharpEye came out and when SharpEye came out with MusicXML support, then the marketing folks go, oh my God, we have so much better scanning than what Sibelius can do if we have this. So that set up getting an invitation to visit, MakeMusic. It wasn’t “MakeMusic” then. It was Coda Music Technology in Eden Prairie in December 2001.

Then in 2002 we signed an agreement that MusicXML would be included as a plug-in for Windows starting with Finale 2003. And so it was shipped in the plug-ins menu. It didn’t move on to the File menu until Finale 2006, when we also had a Mac version that was finally ready by that point.

But obviously being able to get it into Finale and import and export full things round-trip. And having SmartMusic, people go, oh, okay. And people understood. And they wanted in on that and they wanted the interchangeability and I kept just marketing, marketing, marketing to all the different folks, you know, my NAMM shows for about 10 years.

Philip: And if you’re going to make a true interchange format, like you said at the outset, then it does have to be able to do both import and export. It needs to have to do both Mac and Windows. It has to work on the major platforms. And those were all pieces of the puzzle, and it didn’t happen overnight. Like you said, it was three full years before you even had a Mac version of something that was already working on Windows.

David: It’s interesting how quickly MusicXML took off in its adoption from that point. I’m sure, from your perspective, Michael, it feels like it was kind of a long slog. But hearing you tell about the initial adoption in both Finale and Sibelius, it’s remarkable how quickly it took off from that point in around 2003 to 2006, to just a few years later. I mean, it’s in most of, even like, digital audio workstations and things that we don’t usually think of as dealing with music notation, at least not particularly gracefully, and all kinds of other applications. And today, the way we use it, it’s kind of the table stakes for creating a new application that does anything with MusicXML.

Was there a point at which you saw the adoption reach a certain level where you thought, oh, wow. Now we have done, I’ve done this thing. We’ve made the relatively, you know, universally agreed upon standard.

Michael: I mean, obviously you knew, it was like 50 or 60 applications in 2004, 2005. Okay, this is good. But it was clear it was still immature. Back in late 2003, we were thinking about moving MusicXML to a standards organization. At and at NAMM 2004, got some great advice from Sean Lafleur, who was the CEO of Coda or whatever it was called in 2004. And he said, the people who are saying they are not going to use MusicXML because it’s not part of a standards group? That’s just an excuse.

They’re not doing it because of something else. If you change things, you’re not going to get them to use it. What you are going to do is that you’re going to give up speed and flexibility, and you’re not mature enough yet to do that.

So you really want to hold off on moving to a standards organization until you find things are much more mature, which was great advice.

Philip: So, meaning that, if it’s within your control, as opposed to a lot of people commenting and getting feedback and all that, you can be much more adaptable very quickly. You can be more progressive and implement new changes and roll out new things and still serve the entire community in a way that is benefiting everybody. Okay.

Michael: Especially when you’re doing large scale changes. I mean, we’ve been able to do pretty speedy releases within the Community Group, but those are for much more incremental changes.

In 2005, we got this big contract with Music Rain for their digital sheet music display, and we needed to add a ton of presentation details. Because, as we’ve mentioned, MusicXML focuses on the semantics, but it also includes, now, enough presentation details to make a very faithful version.

Michael: Well, it didn’t in MusicXML 1.0. A lot of that came in MusicXML 1.1. Huge amount of new features. And being able to do that, with a company controlled standard versus a organizational standard, especially at an organization that wasn’t as well set up for this type of thing as the W3C Community Groups are.

Philip: Right. And there are two things here that I think is probably worth just mentioning really quickly. So you’re talking about. One concept, which is an open standard, meaning that anyone can freely take the standard and implement it, royalty free, in their own software and work with it.

But the copyright to it — the actual control of it — still rests with, in this case, it’s still at the time it was Recordare, was your company. And, if it was going to be changed, you were the ones to do it. So I think sometimes people confuse the two concepts. But sometimes I think that gets a little lost in understanding how these different technologies work.

Michael: There’s open standards, open formats, open governance, I think is the main thing. We had an open standard, which you could use and change things, but it would be your own version of it.

It wouldn’t be the standard version. You couldn’t use the MusicXML name for something that wasn’t MusicXML. We had something in there in the license agreement. But you can make those changes, but you wouldn’t want to. And nobody did, because that wasn’t practical.

And again, when Recordare was doing it as a single company and not part of the big companies, that wasn’t a big deal, but in terms of David’s question about, when did it feel like done in terms of, okay, we’ve arrived at a standard format, it was really around 2011 with MusicXML 3.0. Because that was like, okay, this is a mature format. This is also really about the limit of what I can do as an independent company at the size that we are: very small. So we need to either grow internally to do more of the digital sheet music vision, or we want to get acquired.

And my goal was very much for the acquisition, cause I didn’t want to be managing a lot of people. So that’s what eventually led to the acquisition of the Recordare assets by MakeMusic, looking around in 2011 for who should we join up with.

And there was another startup company that was interested in doing an acquisition, and then Beth Sorensen who was managing Finale development, and she was pitching me on this project that eventually turned into the new file format that we did for Finale 2014. She said, well, you don’t seem so enthused about it, I thought you’d be more enthused about it.

Like, well, you know, this consulting project sounds nice, but you know, we’re talking with this other company about acquisition. And what would you think about the possibility of MakeMusic acquiring Recordare?

And it’s one of those moments in the conversation where you know you’ve hit the jackpot because you could just see all the — you could see all the wheels turning in Beth’s brain — Oh my God. I never thought he wanted to be acquired. Oh my God. I got to go back to the folks and talk about it. So that laid the groundwork.

David: I can imagine that it would be really interesting for a company like MakeMusic to have this, because they make different kinds of products that use music notation. Like Finale and SmartMusic both use music notation, but in super different ways. Finale is the notation application that we know and love.

SmartMusic, if anyone’s listening to this and has not heard of, is an educational tool that kind of listens to audio input from a student and assesses it, more or less in real time. But it has to know what the notation is and what it expects to hear based on that.

That kind of interchange, even within MakeMusic, strikes me as something that people developing that software would find really useful, not to mention the idea that they would want to be able to sell MakeMusic to somebody who uses Sibelius to make music notation, and get things over in that way as well.

Michael: Well, David, that’s exactly it. That was exactly the strategic reason for MakeMusic to do the acquisition because you had Finale and you had SmartMusic. And at the time, they were both using the same notation engine — Finale based notation engine — but it was clear that SmartMusic would have to move off the desktop into more mobile apps or web-based apps.

And that the Finale file format probably was not the best thing to use for that. So, okay, if we have a different technology for some new future SmartMusic, we have tens of thousands of pieces of repertoire in SmartMusic. How do we get them over? That’s exactly what happened. That we went from our classic SmartMusic application, which was just retired a few months ago, to the newer web-based application.

And we transferred the tens of thousands of repertoire pieces over from one to the other, making the repertoire the best of any of the assessment applications that’s out there. And that was all done via MusicXML because the underlying technology on the web-based side is totally different than the Finale side. And so you have to have that MusicXML exporting out of Finale and importing into the music architect format that is the basis behind this, the SmartMusic web-based technology.

Philip: Yeah, so really great for MakeMusic and Finale and SmartMusic. But, what about Sibelius? What about some other competitors to Finale when they say, oh, wait a second. This open standard is — hey, there’s this really nice Michael Good guy who was doing it kind of as Switzerland, as you said.

Now it’s MakeMusic. So that necessarily precipitated a change, as you alluded to a little while ago, about the governance of the standard.

Michael: Exactly.

David: Yeah, W3C. Because I think probably a nontrivial proportion of our listenership is not familiar with the acronym “W3C”.

Philip: Yeah.

Michael: Sure. The W3C is the World Wide Web Consortium. So they are the group behind all the standards that are used on the web, HTML being the main one. They’re also responsible for XML and lots of other standards that work on top of HTML and XML like web audio, very near and dear to our hearts as web based music application developers.

So, the path from, as Philip mentioned, once MakeMusic acquired Recordare, then the collaboration on developing new versions of MusicXML does, like, basically shut off. Because nobody wanted to talk to a competitor about that and MakeMusic was a competitor to lots of companies in the way that Recordare wasn’t.

And so Joe Berkovitz from Noteflight, bless his heart, was very persistent. Especially once they became part of Hal Leonard, on saying, we gotta get this transferred over to an open governance. You know, what worked for Recordare doesn’t work for MakeMusic.

And the W3C has this thing called Community Groups, where you don’t have to be a member of the World Wide Web Consortium in order to join it. Community Groups do web-based standards in different areas that are not official W3C recommendations. So they’re not standards at that level, but they’re standards in terms of a Community Group report. And that seemed like a much more appropriate place to have MusicXML governance, going forward.

Philip: That was a real pivotal moment, I think, too. Because, think about, that’s a real 180 in terms of the philosophy. Because you had just gotten that advice only a few years ago, really.

Michael: Yeah, but at that point it had been almost 10 years ago.

Philip: Okay. So it was really at that point…

Michael: Things had changed.

Philip: Things had changed. Yeah, okay.

Michael: MusicXML 3.0 was mature enough. Yeah, we’re going to want to do new things, but we don’t have to do huge swaths of new things like we did for MusicXML 1.1. The advice that applied 10 years ago wasn’t applicable now. Here, the benefit was much greater to have, as long as we were convinced that this was a group that would let us do, lightweight processes. And a W3C Community Group, you can do whatever your own process is. So that was great.

We didn’t have to follow some thing where, oh, there has to be a 100% consensus on every decision or something like that, which would still slow things down.

My condition to Joe was that, yeah, that sounds like a good idea, but we’re not going to do it unless Steinberg donates SMuFL to the same group. So we wanted the W3C Music Notation Community Group to collect the two major standards that were being used in notation — didn’t want MakeMusic to give something up without Steinberg giving something up.

So Daniel said, oh, sure. That sounds like a good idea. I mean, you’d have to talk to Daniel about any more details on that side, but from my perspective, it seemed like that was not a difficult conversation at all.

David: And to some extent, it’s much more useful, right? It would be much less useful to only have MusicXML under this umbrella and not SMuFL, or the other way around. It would be much less useful to have SMuFL in this Community Group and not MusicXML. Because obviously the semantic understanding of the music doesn’t mean a lot unless you can render it in some meaningful way.

So not only was it a good idea for you to work with Steinberg to both donate this really significant amount of intellectual work to the public good through the W3C Community Group, I think it really makes both parts of it a lot more powerful, which is one of the things that’s been really interesting to watchas the Community Group has evolved over the last few years.

Philip: Yeah, I would agree. And SMuFL, of course, for our listeners that may be coming to the podcast for the first time, is the Standard Music Font Layout standard that was developed by Steinberg, principally Daniel Spreadbury, for use in Dorico. And the difference, of course, though, being that he developed it, as he told us, really — Well, he developed the font, Bravura, and then the standard really was the other hand, if you will, the left hand and the right hand working together. But it was developed for their program, but then they made the decision to make it available under this, the auspices of this group, so that other applications could develop it.

And then other people — like, it’s one thing for a font developer say to say, well, I’m just, you know, maybe I’ll develop this font specifically for Dorico and no one else. But then if it’s like, hey, wait, there’s this open standard, and a lot of other web-based applications will be using it, and a lot of other potential applications and maybe other legacy applications — like MuseScore, we’ve seen now have implemented it — then becomes, all of a sudden, a lot more appealing to a lot of people to develop for it and support it.

And that was part of the calculation, the calculus, I’m sure, in joining your Community Group. To follow up on a point that David made, yeah. Having the two standards in the same group. First, it gives you more critical mass. We’re already a small community. Let’s — let’s have all the standards that are related to music notation, key to music notation, in the same place, thank you very much!

Michael: But also, the interchange, because MusicXML in version 3.1 is, as Daniel mentioned, added a lot of support for SMuFL fonts where you can reference, you know, a particular SMuFL font character so that we now don’t need to have an element for every single one of the 3,000 glyphs in SMuFL. You can reference them in a way that doesn’t make MusicXML so complex as a language.

Philip: Yeah.

Michael: And SMuFL has also been adapted and modified to flow well with MusicXML. That was actually happening before. the two groups got combined. It’s been very productive.

Philip: Yeah, So, Michael, what is the practical effect on users? And maybe fast forwarding a little bit to the current day, like, where is it at now? How would people see MusicXML reflected in their use of notation software?

Michael: Hopefully you don’t see MusicXML, would be ideal. Because it’s a tool that should be in the background. But you definitely see it in your workflow, if you ever have to share with somebody else who’s using a different program.

So if you’re just doing your own music in Finale or Sibelius or Dorico or MuseScore, sure, you don’t need it. You create your score, you send out PDFs, maybe you send an audio file mock-up But you don’t send out any modifiable file format like MusicXML.

But if you’re a composer and you’re working with an engraver, or if you’re orchestrators and you’re working on a show or a movie, or anytime you have a divide between applications and people are using different applications, that’s when MusicXML is going to go into play.

And hopefully it looks really seamless. You export in from one and you import into the other and you go, oh, great. It works. And then what guides the future development is when you go, well, it didn’t quite work.

So that’s why we have MusicXML 4.0. Fixed some of those issues that keep coming up. I mentioned SmartMusic. We’re doing tens of thousands of files from a Finale-based system to a SmartMusic-based system. We find some issues. So MusicXML 4.0 addresses both some longstanding needs for the MusicXML format, plus a lot of nitpicky details that come up when we go from one program to the other.

Philip: So for someone listening to this podcast episode and thinking, hey, I would like to know what to expect in the future in 4.0, can you give us a little bit of a taste of some of those things that maybe don’t work so well right now, but can expect in the future?

Michael: I mean, one thing is, each program tends to have its own way of having parts integrated with the score.MusicXML has basically been focused on, you do either a score or you do a part, and hasn’t really done anything between the linkages of score and parts.

So now in MusicXML 4.0, there’s a standard way to include in one compressed MusicXML file — the dot MXL — instead of dot MusicXML, the smaller one. You can have both the score and all your parts in the same file. Which means that you can look at the different score and parts and see what the differences are to adjust things on import. So you can maintain part formatting, as well as score formatting, from a single file.

Philip: So if I understand correctly, you could conceivably import that one compressed MXL file into one Finale file or one Sibelius, and it would all be part of one file and the parts would come in as you had formatted them.

Michael: The current plan is to have a beta version of a Finale plug-in that works with the current Finale software. And that’s already happening there, is that, when you bring in the parts — the system breaks, for instance, in particular — it doesn’t get every bit of formatting that differs, but it gets the placement of the text blocks. And system breaks, in particular, are preserved among both the score and the parts.

David: Which would save a ton of time.

Michael: Yeah, it should. That’s the goal.

In turn with that, it also handles a concert score with transposed parts. And concert scores — C scores — have been a very weak point of MusicXML for a long time. So it’s great to finally tackle that problem and get things working properly.

Philip: That’s great.

Can you actually tell us a little bit about how someone that gets the same exact MusicXML file — because you mentioned this concert versus transposed thing — and I’m thinking, one program may read it in one way, and one program may read it in another way. I’ve encountered that; opening something in a Dorico file versus a Sibelius file. What would cause a particular software to interpret the same MusicXML file in potentially very different ways?

Michael: Usually that’s just not supporting all the features in the language. I mean, music notation is very complex, which makes MusicXML very complex. And each of the applications, you know, the top level applications, are all complex. And not everybody either implements all the features in MusicXML or in their software, period. You know, you can’t do it without putting some hack in. Or, you have other things to work on your program besides perfect MusicXML import.

So there are just some features that haven’t made it yet. And if you’re importing the concert score for MusicXML 4.0 into a program that implements Music XML 3.0, you’re not going to get the same results as you will from somebody that imports MusicXML 4.0. So, as with any of these version transitions, there may be a bit of a shakier period as the programs get themselves up to different levels of MusicXML 4.0 support. But that usually lasts for about a year or so, and then the programs come up to the MusicXML 4.0 level and things tend to get smoother again.

Philip: That’s exciting.

Michael: A couple more of the new fancy features coming! New features for score following and assessment applications, or other types of applications doing machine listening. Some of them suggested by SmartMusic. It’s one of these things where we see the few basic features and we see how well this is used, how it takes off and may evolve into something more. But we’re hoping that opens up MusicXML to another whole other class of applications to be used.

And then some more detailed things like Roman numeral support for music theory. Nashville numbers support using the same things that the Roman numeral support is.

And the big thing for developers is that there’s actually going to be updated MusicXML 4.0 documentation that’s hosted on the W3C site. A big thing for MusicXML 3.0 was to put some documentation together and that’s on the MakeMusic site. That never made it over to the W3C site as part of the transfer. And now nobody finds the MusicXML 3.1 features, because all the Google searches take you over to the MusicXML 3.0 documentation. So, can’t do that. We’ve got to get the documentation in place for MusicXML 4.0.

Philip: Hey, the importance of documentation. Good documentation is not to be underestimated, as you said earlier in the show, Michael, had that ManuScript feature in Sibelius been adequately documented, it would have saved you a few years in putting together a plug-in for MusicXML.

Michael: It’s part of what you mentioned for why doesn’t the application work the same way? Well, because they looked at the MusicXML 3.0 documentation and they missed the fact that it was added in MusicXML 3.1.

Whose fault is that? It’s our fault. And we’ve got to fix that.

Philip: Well, you have a lot on your plate, so we will forgive you, but just this time. No, we are really grateful. And David, I know that we’ve been talking about the more commercial applications, Finale, Dorico, Sibelius, what have you. But I know you’re very grateful for the way in which you’ve used MusicXML recently.

David: One way that I have made a lot of use of MusicXML recently, and I just want to say thank you directly Michael for this. I have a student in my university who is visually impaired. And to support this student, we’ve needed to prepare music Braille editions of every musical example from every theory course that this student is taking.

And that sort of thing is only possible because MusicXML exists. And the reason it’s implemented by this research team is because it’s an open standard and it works great online. Like you said, it’s got all kinds of built-in XML parsing. It’s doing all plain-text stuff on both sides of that. It’s a really great tool that is only possible because there is this open standard.

Michael: Oh, great.

Philip: Michael, this has been really terrific.

You said something about if we’re using MusicXML correctly, we actually really shouldn’t be thinking about it. And I suppose that’s true. We appreciate that.

At the same time, I think our listeners, especially those of you that are listening and are relatively new to the software, whether you’re younger or just coming at it at a different stage in your career, that there used to be a time when, if somebody was working in one music notation software platform or another, there was virtually no way, apart from MIDI, to transfer the files between the different products that you were using.

And now we pretty much take it for granted. But don’t take Michael Good for granted.

Even if you don’t think about MusicXML on a regular basis, think about Michael every once in awhile. Because without him, I think we’d be in a very different spot when it comes to using these tools.

So, Michael, not only are we grateful for all the work that you have done over, really, the decades of your career in putting together these tools for us, but we’re supremely grateful for taking a little bit of time today and coming on the show to talk to us about it all.

Michael: Well, thanks so much for the opportunity. And let’s not leave out all the folks in the MusicXML community and the Community Group over the years who have contributed so much to format. I certainly got the ball rolling, but a lot of the best ideas in the MusicXML you use today were not my ideas. They were ideas from other members of the MusicXML community. And the power of the community is much greater than the power of any single person.

Philip: For sure. Characteristically humble as I said. But that is true. There’s a great community that we have in this field, and a great community of listeners I know will certainly enjoy hearing what you’ve had to say about it today.

David, we finally had Michael Good and we had a proper discussion about MusicXML.

David: I enjoyed every minute of it. This is great. Thank you so much for your time, Michael.

Philip: Thank you both. And thanks to you listening. Hope you enjoyed this one. There’ll be many more to come until then. Take care. We’ll talk to you next time.


Listen to the podcast episode

On the Scoring Notes podcast, David MacDonald and Philip Rothman talk with Michael Good. If you’ve ever needed to open a music notation file in a different program, you’ve relied on MusicXML to do it. Michael Good invented this now-ubiquitous format two decades ago, and we find out how it happened. Listen now:

Scoring Notes
Scoring Notes
Michael Good, the inventor of MusicXML [encore]


Leave a Comment

Your email address will not be published. Required fields are marked *