Yes, I've already begun work on an open-source utility that converts from MusicXML to MNX: https://github.com/w3c/mnxconverter

Eventually it'll work both ways. I'm hoping this is a big help for adoption, as gives you two formats for the price of one (just write an importer for MNX, and you can get MusicXML import support "for free" if you use the library).

It's computer readable and (with highlighting) human readable. The JSON brackets are visually jarring. I feel that the XML is almost self documenting whereas I'd probably need the schema to understand the JSON.

I like JSON for data transfer but for describing documents XML is decent.

Having an MP3 to sheet music would be even better, but probably 10x harder to do well.

Thanks. If it isn't too many questions, are any layout concerns encodable in MNX, or is it scoped to semantic information only?

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.

XML is much more precise and much more flexible. It also benefits from much more powerful and mature tooling. The few comparative downsides it has include verboseness, which doesn't matter to machines, and that younger devs don't know how to work with it, which again shouldn't be much of an issue in this use case.

Thanks! We're not planning to support inline comments at this time; this was a tradeoff we knew we'd have to make when we decided to use JSON.

Given the choice between supporting comments and supporting a wider variety of implementations/libraries ("plain" JSON as opposed to a comments-supporting variant), I think the latter is a more practical priority.

With that said, we'd like to add a standard way to add vendor-specific information to an MNX document — which is definitely a must-have, for applications that will use MNX as a native format — and I could see a comments-ish thing appearing in that form.

Regarding that examples page, I'm actually planning to do something along those lines anyway. The MusicXML docs and the MNX docs use the same system (a Django app), and the MusicXML part uses a custom XML tag to define "this part of the XML example should be highlighted in blue" (example: https://w3c.github.io/musicxml/musicxml-reference/examples/a...). It's on my to-do list to implement the same thing for the JSON version — which is essentially like inline comments(ish), if you squint.

MIDI is absolutely horrible for ML. It lacks very necessary information such as articulation etc which are important to make sense of music. It's popular because it's simple but there is no way to understand music by just looking at MIDI.

I'm a hobbyist in this space (am a composer myself as well a software engineer) and currently all tools are very poor. MusicXML is better than MIDI. MEI [1] is better than MusicXML etc.

The problem is there is miniscule amount of effort and money spent into this field because music overall makes peanuts. It really doesn't justify training expensive ML algorithms which is unfortunate.

[1] https://music-encoding.org/about/

The reason why you don’t need some big, formal JSON schema (though they do exist) is because you can notate most of the constraints people care about in TypeScript. It’s just a bunch of structs, arrays, string enums, etc. XML doesn’t really have a nice mapping to type systems like that so it needs schemas.

My coup de grace against XML is that it is wholly unsuitable for serializing arbitrary strings in most programming languages. It’s defeated by quite simple strings like “hello\0world”. You can’t just escape the null using &#; because the standard, in its infinite wisdom, forbids it. Instead, you’re just expected to come up with some completely non-standard way like <null-char /> or just interpret “\0” specially in your application code. Meanwhile, JSON just lets you put pretty much whatever Unicode you want into a string with a standard way of escaping characters like the double quote.

> Flexible definition of data allows for greater precision of data structure.

Other way around. If there are 3 different ways of doing something, the data structure is less precise. Say you have an object with a Name as a string. You know exactly what this is going to look like in JSON:

    {
        "name": "Whizzbang"
    }

How is it going to look in XML? It might look like this:

    <Foo name="Whizzbang" />

It might look like this:

    <Foo>
        <Name>Whizzbang</Name>
    </Foo>

It might look like this:

    <Foo>
        <Name value="Whizzbang" />
    </Foo>

XML is less precise because it's more flexible. "But you just define an XML Schema to disambiguate" -- so now you're doing more work in a separate file that you have to publish and link in just to solve a problem that JSON doesn't have at all.

> Something like XSLT isn't for human interaction; it's for super-powerful machine transformations.

It's only "super-powerful" considering XSLT as a markup language. Considering it as a programming language, it rather sucks. If you're writing ETL scripts to transform data around, use an actual programming language. The fact that XSLT is Turing Complete only drives home the point that it's not a "powerful markup language", it's "poorly-designed programming language". Sure, if you're literally only transforming the exact same data from one XML schema to another, as some sort of adapter step, then XSLT beats general-purpose languages; but you're never just doing that, are you? You're linking in other data sources, validating things, sending things over the wire, etc. You already need the code to save and load your XML into a format you prefer in memory; just use that format for these tasks.

> Any time a dev pushes back against XML, it's been my experience they are uneducated on the subject.

Many people who push back against XML are not uneducated, but rather jaded on it, having worked with ambiguous formats, buggy schemas, and 4000-line long configuration behemoths that should have just been code. You can use XML parsimoniously, but there's not much overlap between the people doing that and the people who love XSLT.

Another concern with comments is that apps might try to (ab)use them to store app specific information, which hurts the goal of an interchange format.

Are you aware of the system I linked above? D.D. Johnson has a blogpost https://www.danieldjohnson.com/2015/08/03/composing-music-wi... with plenty of examples of what an instance of his model can generate. It may not be all that "good" in an absolute sense, but it's at least musically interesting, the opposite of elevator music. (There's also a proprietary model/AI called AIVA about which very little is known, but it does seem to be bona-fide AI output - albeit released in versions that have been orchestrated by humans - based on what it sounds like.)

> Or it seems that JSON works just fine without comments

Code that can't be annotated might as well be machine code. And guess what? Json largely is just that.

> It's so "absolutely necessary" that JSON has found hardly any success

I am almost 50, and since as early as I can remember, the worst technology always wins when there is some sort of standoff. That json succeeded doesn't mean anything, other than that it was the worst.

I'm old enough to understand why this is usually true... the best technology is usually more expensive, and economic forces favor the cheapest. Json though? Best I can figure is that imbeciles just got used to picking the worst, even when there was no expense tradeoff.

Snarking about how it won... I guess that means you think it was perfect on its first try? When the fuck has that ever happened with software?

You're just plainly wrong, and I don't know why or how you'd bother to be. Do you have a few hundred million in JSON Inc. shares about to IPO and somehow I missed it?

My point is that -- in my experience and musical taste -- deterministic algorithms (e.g. literal scripts you write yourself to generate MusicXML, MIDI, lilypond, PDF etc) are orders of magnitude more useful than these neural network ML models that give you monolithic chunks of music. You can still use NN models in your scripts (e.g. have a model to determine chord distance, tonality etc) but there is no universal musical model that has come remotely close to convincing me so far. Of course, when it comes to Western classical music, "counterpoint" is probably the closest you can get to a universal musical model that you'll attempt to find in all pieces of music, but even that comes nowhere near even remotely close to explaining great majority of musical statements (even in something as contrapuntal as Bach). Especially when we come to 20th and 21st century music when people actively react to this model.