moinejf/abc2svg

Musicxml import

Opened this issue · 7 comments

Hi,
Do you have any plans to incorporate musicxml file import feature in abc2svg?

There is already the famous xml2abc package from W. Vree.
Anyway, I don't like musicXML. MEI is cooler (job started). Otherwise, I wonder about MNX from the W3C.

bwl21 commented

@moinejf Why don't you like musicXML. Its main advantage is the fact that it works well and is supported by nearly any Music software. and W.Vree's xml2abc works great.

To be honest, thanks to xml2abc I did not even look into the datamodel of musicXML yet :-)

As you can see in
https://w3c.github.io/mnx/by-example/
MNX is much more compact than MusicXML.
Also, the MusicXML tag is rather odd.
What do you mean by "datamode of musicXML"?

bwl21 commented

@moinejf it was a typo: i mean data model. As I said MusicXML is widely adopted.

In my opinion the data model is the crucial thing which should be clear enough, the XML-representation of the same is not that important as it is only a serialization of a data model.

And looking into the https://w3c.github.io/mnx/specification/common/#root-structure i really miss an UML representation of the approach - which is the case for MusicXML as well :-) Such a meta model would make life much easier, it supports documenteation and even subsequent generation of a consistent XML schema.

Some characters went out in my previous comment:
"Also, the MusicXML tag <backup> is rather odd."
Don't you think so?

@bwl21 Well, after looking again at our JSON data model, I think this one could be generated from MIE.

The idea is to directly convert the MEI output to JSON (this is easy: there is no pointer!). Then you would get a more readable data model in JSON representation. There would be no maintenance to do anymore by me because the MEI stream contains all the needed western music information.

What do you think?

bwl21 commented

@moinejf to be honest, i hesitate to do bigger changes here. As i said the conversion from the JSON -Model to the Zupfnoter Music model is pretty complex. In 2015 I was working one Month on this. I am afraid, that i will have to redo this effort again.

With respect to the JSON Model, maybe we could generate another JS-Object and serialize this with JSON.stringify() to produce JSON if we want to reduce maintenance effort.

With respect to MNX (beside the fact that they claim it not to be implementation ready) I feel that they invent too many IMHO even somehow strange local syntaxes as specified in chapter "Notational Syntaxes". I think they should work out a proper data model for this stuff, and then see, how it can be serialized in XML, of as Domain specifc language.

@bwl21 The problem with my data structure is the pointers. To have JSON.stringify() working, there must not be loops with the pointers, and there are a lot of them.
I do not work on MNX. Compared with MusicXML, I just find they can reduce the size of the music files and also remove the odd elements (backup!).

No, I am talking about MIE. The script 'tomei.js' (actually in batch) outputs working MEI files from ABC. I tried some XML to JSON programs, and the result is clean, and way shorter than the actual abc2svg JSON.
As told in my previous comment, it would easy to adapt the script tomei.js and directly generate JSON. This would be faster than to build a new specific data model from the internals of abc2svg.