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

31–40 of 80 posts

Re: MusicXML

#31

Post by jsphweid »

adgjlsfhk1 wrote: post #29
jsphweid wrote: post #27

Earlier quoted context omitted.

Right, but sheet music is ubiquitous in countless musical contexts and there's very little attention to it from the ML side. Sheet music is somewhat arduous to create and there is definitely room for a lot of automation and ML could help out a lot. I experimented with a tokenizer / GPT-2 (decoder-only) model for MusicXML ( https://github.com/jsphweid/xamil ) that is able to generate single staff music somewhat cohere…

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

For now, between the state of the art source separation models (e.g. demucs) and transcription models (e.g. Magenta's MT3) the last mile seems to be MIDI -> MusicXML IMO. But yes, I suspect it'll become more end-to-end ML in time.

Re: MusicXML

#32

Post by adrianh »

odyssey7 wrote: post #24
adrianh wrote: post #16

Earlier quoted context omitted.

They'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 s…

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

Yes, 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/multip...

Re: MusicXML

#33

Post by gnulinux »

zozbot234 wrote: post #26
gnulinux wrote: post #25

Earlier quoted context omitted.

> If you want notes that will actually sound good when played back, it's hard to beat it. I strongly disagree with this. There is no good algorithmic music generator trained on MIDI. They all generate elevator music.

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, you can use them like ChatGPT to get a sense of things but we're decades away from producing "music" this way imho.

Re: MusicXML

#34

Post by usrusr »

TedDoesntTalk wrote: post #10
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…

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

I'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...

Re: MusicXML

#35

Post by odyssey7 »

adrianh wrote: post #32
odyssey7 wrote: post #24

Earlier quoted context omitted.

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

Yes, 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/multip...

Much appreciated! This is excellent work.

Re: MusicXML

#36

Post by ronyeh »

adrianh wrote: post #11
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…

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.

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

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.

Re: MusicXML

#37

Post by Exoristos »

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…

> they recently switched to JSON

Considering this data is machine-generated and machine-ingested, moving away from XML seems like a big step down.

Re: MusicXML

#38

Post by im3w1l »

adrianh wrote: post #11
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…

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 losslessly roundtripping MusicXML an explicit goal? (I assume losslessly roundtripping MNX will not be possible in general as you intend to add new features to MNX that MusicXML doesn't have and will never have).

Re: MusicXML

#39

Post by bastawhiz »

Exoristos wrote: post #37
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…

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

Re: MusicXML

#40

Post by microtherion »

usrusr wrote: post #34
TedDoesntTalk wrote: post #10

Earlier quoted context omitted.

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

I'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...

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.
Post reply on HN