[jonathrg]

I have not had much success using MusicXML to switch between different notation programs. Trying to read a score exported from Musescore as MusicXML in Sibelius or vice versa feels worse than switching between Microsoft Office and other ostensibly compatible formats.

Does anyone have any success stories?

[adrianh]

This is a common complaint, and it's something we're trying to remedy with MNX: https://w3c.github.io/mnx/docs/

Music notation is incredibly complex, and there are many places things can go wrong. There's a wide spectrum of error situations, such as:

* The exporting application "thinks" about notation in a different way than the importing application (i.e., it has a different mental model).

* MusicXML provides multiple ways of encoding the same musical concept, and some applications don't take the effort to check for all possible scenarios.

* Some applications support a certain type of notation while others don't.

* MusicXML doesn't have a semantic way of encoding certain musical concepts (leading applications to encode them as simple text (via the words element), if at all.

* Good ol' fashioned bugs in MusicXML import or export. (Music notation is complex, so it's easy to introduce bugs!)

[saltminer]

> MusicXML provides multiple ways of encoding the same musical concept, and some applications don't take the effort to check for all possible scenarios.

This sounded interesting, so I went to the webpage, and found this point specifically called out:

> It prioritizes interchange, meaning: it can be generated unambiguously, it can be parsed unambiguously, it favors one-and-only-one way to express concepts, and multiple programs reading the same MNX file will interpret it the same way.

But I'm curious to see some examples of this. https://w3c.github.io/mnx/docs/comparisons/musicxml/ provides an interesting comparison (and calls out how the same MusicXML can be interpreted in different ways for things like octave shifts), but it would be nice if the page also included alternate ways that MusicXML can represent the same composition and talk about how certain programs end up misinterpreting/misrepresenting them. The Parts comparison, for instance, mentions how you can represent the same thing in two different ways in MusicXML (score-timewise and score-partwise), but only provides an example for one (score-partwise), and doesn't go into much more detail about if this leads to ambiguity in interpretation or if it's just making things needlessly complex.

[adrianh]

Thanks, that's good feedback — will add that to the to-do list.

Just to give you a quick response: look into MusicXML's concept of a "cursor". Parsing a MusicXML document requires you to keep an internal state of a "position", which increments for every note (well, careful, not every note -- not the ones that contain a "chord" subelement!) and can be explicitly moved via the "backup" and "forward" elements: https://w3c.github.io/musicxml/musicxml-reference/elements/f...

For music with multiple voices, this gets easy to mess up. It's also prone to fractional errors in music with tuplets, because sometimes software chooses to use MusicXML position numbers that aren't evenly divisible into the rhythms used in a particular piece of music. That can result in a situation where the MusicXML cursor gets to a state that doesn't actually align with any of the music.

[saltminer]

That sounds like a nightmare to deal with, I'm surprise you don't mention this in the comparison example for multiple voices.

Another suggestion: you highlight the MusicXML elements being discussed in blue, but not the MNX elements. Especially on the longer examples, highlighting the relevant MNX elements would be nice.

[adrianh]

Thanks, that blue highlighting is definitely on the to-do list!

[im3w1l]

I recently used a funny workflow involving MusicXML. I wanted to learn a song that I only had sheet music for and not being much of a sightsinger, I had manually input the sheet music into Vocaloid so I could sing along with it (OCR exists but in my experience is in such a sorry state and requires so many manual fix ups that for the moment it's easier to type it in manually. As for enterring the data I have experimented and I'm significantly faster and more accurate with a piano roll than typing note names in musescore).

Now as this song had nonsense lyrics and many repetitions and almost-repetitions, the structure of the song didn't quite pop out to me, so what I did was export a midi from vocaloid that I opened musescore. From musescore I then exported it as MusicXML. I opened that in Notepad++ for the sole purpose of pretty printing the xml to normalize the texual representation and saved it right back. I took that and opened it in a jupyter notebook where I scraped it for <measure> elements with regular expressions and then I searched for repeating ones, that I assembled into repeating segments and sub-segments.

This helped me memorize the song.

What I liked about MusicXML was that it was self-documenting enough that I didn't need to reference documentation and I could find candidates for normalization quite easy (for instance I didn't care about directions of stems or inferred dynamics).

A gotcha is that Musescore 4 has a bug where it doesn't show the "midi import" where you can adjust the duration quantization, this didn't matter to me for this song, but I did bite me once in the past when opening a midi from Vocaloid. Musescore 3 works. Without playing around with that there can be an issue where it infers 16th notes as staccato 8th notes and similar.