5 ms·
I work for Sibelius so I'm heavily involved in this world. MusicXML is a great standard and offered a solid basis for data interchange between music notation pr
by Tokkemon 3y ago
I work for Sibelius so I'm heavily involved in this world. MusicXML is a great standard and offered a solid basis for data interchange between music notation programs. But now there's a new group working to build a successor standard, MNX: https://w3c.github.io/mnx/docs/ https://w3c.github.io/mnx/docs/
It was originally going to be in XML but they recently switched to JSON, which is a good move, I think. I can't wait for it to be adopted as it will give so much more richness to the data set.
- odyssey7 3y agoHow would you explain the relationship between MNX and SMuFL?
- adrianh 3y agoThey're totally different things, though the standards are maintained by the same people. SMuFL is a font layout specification. It solves the longtime problem of "I'm making a music font. Which Unicode code glyph should I use for a treble clef?" For many years, this was a Wild West situation, and it wasn't possible to swap music fonts because they defined their glyphs in inconsistent ways. This problem is basically solved now, thanks to SMuFL. MNX is a way of encoding the music itself. It solves the problem of "I have some music notation I want to encode in a semantic format, so it can be analyzed/displayed/exported/imported/etc."
- odyssey7 3y agoThanks. If it isn't too many questions, are any layout concerns encodable in MNX, or is it scoped to semantic information only?
- adrianh 3y agoYes, the goal is to allow people to encode layout information optionally — as a separate layer from the semantic information. One particularly cool thing is the ability for a single document to have multiple layouts (!), which is useful for parts vs. conductor scores. See here for an example: https://w3c.github.io/mnx/docs/mnx-reference/examples/multiple-layouts/ https://w3c.github.io/mnx/docs/mnx-reference/examples/multip...
- odyssey7 3y agoMuch appreciated! This is excellent work.
- TedDoesntTalk 3y agoHopefully they will use JSON5 so comments can be included. The loss of comments when switching from XML to JSON was a disaster in other domains.
- usrusr 3y agoI'm all for JSON-with-comments, and I even have a bit of a soft spot for the idea of JSON-with-expressions, but considering how far I expect this one to be on the "interchange" side of the spectrum between interchange formats and authoring formats, I doubt that comments will be missed a lot. Certainly less, less by several orders of magnitude, than in the depressingly ubiquitous JSON-as-configuration use case...
- microtherion 3y agoAnother 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.
- NoMoreNicksLeft 3y ago"Oh no! Bad actors might abuse this absolutely necessary feature, so it's better that we leave it out and let everyone suffer to avoid that! You'll just have to cope!"
- throw0101b 3y ago> "Oh no! Bad actors might abuse this […] There's no "might" about. This is exactly what happened in the early/beta days of JSON, per Douglas Crockford, creator of JSON: > I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. * https://web.archive.org/web/20190112173904/https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr https://web.archive.org/web/20190112173904/https://plus.goog... * https://archive.today/2015.07.04-102718/https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://archive.today/2015.07.04-102718/https://plus.google.... > […] absolutely necessary feature […] It's so "absolutely necessary" that JSON has found hardly any success and is struggling to find a use case or a niche… /s Or it seems that JSON works just fine without comments, especially as a data exchange format, which contradicts that claim that it is "necessary" (absolutely or otherwise).
- adrianh 3y agoHi, I'm the person running the MNX project! Contributions welcome — we're making good progress and the new format is going to be really fantastic.
- ronyeh 3y agoAwesome project (as always) Adrian! Will MNX allow for inline comments? I don’t see any comments on the examples page: https://w3c.github.io/mnx/docs/mnx-reference/examples/ https://w3c.github.io/mnx/docs/mnx-reference/examples/ I know JSON doesn’t have comments, but JS and JSON5 allow for comments. It would be super nice to allow for comments because you can hand annotate sections of the MNX file for the purposes of teaching.
- adrianh 3y agoThanks! 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/accidental-mark-element-notation/ 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.
- ronyeh 3y agoThanks! I’ll definitely follow the MNX project. Seems exciting.
- 3y ago
- Kye 3y agoHow well does MusicXML (and MNX) represent the full range of notation? It seems like an exceptionally hard problem. Related: Can it handle non-Western notations?
- Tokkemon 3y agoMusicXML only works with conventional western notation, but MNX is attempting to expand that significantly. How far they will get with that, I don't know.
- deleted 3y ago[deleted]
- gnulinux 3y agoHow about MEI? https://music-encoding.org/about/ https://music-encoding.org/about/ This is what MuseScore 4 will soon start using.
- account-5 3y agoNever heard of either before but having looked at the comparison [0] I think I prefer the XML version. [0] https://w3c.github.io/mnx/docs/comparisons/musicxml/ https://w3c.github.io/mnx/docs/comparisons/musicxml/
- jefftk 3y agoWhat do you like better about the XML version?
- account-5 3y agoIt'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.
- poulpy123 3y agoI'm with you. I usually prefer JSON to XML but in the example the XML is more readable
- Exoristos 3y ago> they recently switched to JSON Considering this data is machine-generated and machine-ingested, moving away from XML seems like a big step down.
- bastawhiz 3y agoIn what way is JSON a step down versus XML? Frankly I get nervous and sweaty every time I need to deal with XML, because of the inherent performance/security issues it brings into my codebase.
- Exoristos 3y agoXML 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.
- ctxc 3y agoMy experience has been similar to the immediate parent although I think xml looks better than json here. All fun and games till you forget to turn transforms and the 10 other knobs in your parser off. The dev will be like "okay what are transforms though?" as they watch new calculator.exe instances popping up on the screen.
- feoren 3y agoXML is less precise, because it's more flexible. Powerful and mature tooling only matters to people creating and editing XML, not computers. XML Schemas are there to support human editors, not computers. Verboseness means larger files and longer processing times, which does matter to computers; the verbosity is explicitly and only there for human readers and editors. JSON is a much better format for something humans only occasionally look at.
- Exoristos 3y ago
- marsven_422 3y ago[dead]
- microtherion 3y agoI've written two music apps that use MusicXML as their native representation (https://woodshed.in https://woodshed.in is the newer one), so I've been involved in this world as well. MusicXML is a great effort to tackle a very difficult problem, but some of the details can get rather hairy (e.g. having to represent many concepts twice, once for the visual aspect, and once for the performance aspect; or how exactly to express incomplete slurs). Interoperability in practice seems to be fairly limited (Possibly because for many music programs, MusicXML import/export is an afterthought). One of the biggest contributions a new standard could make is to provide as complete a test suite as possible of various musical concepts (and their corner cases!) and their canonical representation. It looks like MNX has already made good efforts in this direction.