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

61–70 of 80 posts

Re: MusicXML

#61

Post by bastawhiz »

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.

> It also benefits from much more powerful and mature tooling.

JSON is over two decades old. XML is only five years older. Both have powerful and mature tooling; I'm not sure how you can suggest otherwise.

Re: MusicXML

#62

Post by ronyeh »

adrianh wrote: post #54
ronyeh wrote: post #36

Earlier quoted context omitted.

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.

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

Thanks! I’ll definitely follow the MNX project. Seems exciting.

Re: MusicXML

#63

Post by saltminer »

adrianh wrote: post #21
saltminer wrote: post #19

Earlier quoted context omitted.

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

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

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.

Re: MusicXML

#64

Post by adrianh »

saltminer wrote: post #63
adrianh wrote: post #21

Earlier quoted context omitted.

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

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.

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

Re: MusicXML

#65

Post by zozbot234 »

gnulinux wrote: post #60
zozbot234 wrote: post #46

Earlier quoted context omitted.

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

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

Yes it depends on what you're trying to do. If you're looking for something to automate part of your composition and make it an "algorithmic" piece where the computer picks the notes, these models are just too limited for that, at least so far.

BTW, "counterpoint" generally refers to one facet of how Western music works, the process of setting "note against note" in musical lines (or "voices") that preserve some kind of autonomy. But there's many other things that explain what makes music sound good, both within a single line and on a broader view, where music is written to target "rest points" or "key areas", and repeat or develop "thematic" material.

(The model I pointed to above doesn't even try in the least to explore these broader-scale things, it's trained on a very small-scale view of its input. It deals pretty well with counterpoint, and the inner workings of a single line. It ends up doing interesting things nonetheless when trying to make sense of its music as it randomly drifts out of the established scale - ISTM that it sometimes ends up changing key as a result of alterations in melody, not always in the background harmony. One could see this as a kind of very light and subtle atonality, even as part of what's clearly a 'tonal' style. It also knows about different historical styles within tonal music, and manages to overlay and transition between them quite well IMHO.)

Re: MusicXML

#66

Post by vilunov »

microtherion wrote: post #40
usrusr wrote: post #34

Earlier quoted context omitted.

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.

They might do it even without comments by adding unused fields.

Re: MusicXML

#67

Post by throw0101b »

microtherion wrote: post #40
usrusr wrote: post #34

Earlier quoted context omitted.

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.

> Another concern with comments is that apps might try to (ab)use them […]

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

* https://archive.today/2015.07.04-102718/https://plus.google....

Re: MusicXML

#68

Post by throw0101b »

NoMoreNicksLeft wrote: post #53
microtherion wrote: post #40

Earlier quoted context omitted.

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.

"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!"

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

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

Re: MusicXML

#69

Post by NoMoreNicksLeft »

throw0101b wrote: post #68
NoMoreNicksLeft wrote: post #53

Earlier quoted context omitted.

"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!"

> "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.or…

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

Re: MusicXML

#70

Post by [deleted] »

NoMoreNicksLeft wrote: post #69
throw0101b wrote: post #68

Earlier quoted context omitted.

> "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.or…

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

[deleted]
Post reply on HN