Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MusicXML

musicxml.com

Post reply on HN
Print view View original

41–50 of 80 posts

Re: MusicXML

#41

Post by jefftk »

account-5 wrote: post #30
Tokkemon wrote: post #8

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/ 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…

Never 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/

What do you like better about the XML version?

Re: MusicXML

#42

Post by Exoristos »

bastawhiz wrote: post #39
Exoristos wrote: post #37

Earlier quoted context omitted.

> they recently switched to JSON Considering this data is machine-generated and machine-ingested, moving away from XML seems like a big step down.

In 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.

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.

Re: MusicXML

#43

Post by marsven_422 »

Tokkemon wrote: post #8

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/ 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…

[dead]

Re: MusicXML

#44

Post by jefftk »

gnulinux wrote: post #20
zozbot234 wrote: post #13

Earlier quoted context omitted.

Note that MIDI is a lot more effective when it comes to ML/AI, since it's multiple orders of magnitude less data. Daniel D. Johnson's (formerly known as Hexahedria, hired by Google Brain) model biaxial-rnn-music-composition is from 2015, requires very few resources for training or inference, and still delivers compelling, SOTA-or-close results wrt. improvising ("noodling") classical piano. https://github.com/danieldj…

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…

> MIDI is absolutely horrible for ML. It lacks very necessary information such as articulation etc which are important to make sense of music.

This depends enormously on the instrument. Consider someone playing a piece live on a keyboard: we can keep a MIDI recording of that and we've captured everything about their performance that the audience hears.

Re: MusicXML

#45

Post by microtherion »

Tokkemon wrote: post #8

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/ 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…

I've written two music apps that use MusicXML as their native representation (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.

Re: MusicXML

#46

Post by zozbot234 »

gnulinux wrote: post #33
zozbot234 wrote: post #26

Earlier quoted context omitted.

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 i…

Yes I'm familiar and... > Here's a taste of things to come it sounds like randomly generated MIDI... Doesn't sound like anything to me at all. Music is very subjective but I've so far seen no model that's convincing. If you like it that's cool I suppose. I personally use algorithmic composing plenty in my own compositions (I write music for piano) and these kind of models don't do it for me. They're definitely tools,…

Well yes, this model like others is quite far from giving you a finished piece. But if it's giving you "a sense" of possibly useful ideas, that's enough to make it more than "random". (Besides, I'm not sure that we would even want AI to produce music on its own with zero human input - what would be the point of that? So "just noodling around, giving you some ideas to get started with" is quite good as far as it goes.)

Re: MusicXML

#47

Post by ctxc »

Exoristos wrote: post #42
bastawhiz wrote: post #39

Earlier quoted context omitted.

In 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.

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.

My 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.

Re: MusicXML

#48

Post by feoren »

Exoristos wrote: post #42
bastawhiz wrote: post #39

Earlier quoted context omitted.

In 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.

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.

XML 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.

Re: MusicXML

#49

Post by OfSanguineFire »

AdmiralAsshat wrote: post #3

MusicXML is old hat. All the cool kids are using MusicJSON now. EDIT: I'd like to clarify that I posted this comment, as a joke , before the below comment went on to clarify that there was, in fact, a JSON-based rewrite of the music standard in progress: https://news.ycombinator.com/item?id=38460827 Never change, tech world!

Please don't post one-line jokes on HN. The longstanding culture of this venue finds that inappropriate.

Re: MusicXML

#50

Post by adrianh »

im3w1l wrote: post #38
adrianh wrote: post #11

Earlier quoted context omitted.

Hi, 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.

As different standards proliferate it makes me worried that we will have less interoperability not more, as programs only have limited resources and pick one format they focus on supporting and perhaps half-assing another. (How) do you plan to adress this? Are there plans for some library for dealing with these files to help adoption? What will be the best way for users to convert from MusicXML to MNX and back? Is lo…

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).

Post reply on HN