> I looked up the MNX format. Compared with musicxml, it seems like > its syntax is more similar to that of LilyPond.
Well... I don't think so. First of all, it is incredibly verbose, targeted at computers and not at humans. Second, while it tries to avoid some bad decisions in MusicXML (mainly describing the visual layout instead of the musical contents), its represenation of music is partially based on MusicXML, making it non-trivial to convert to and from LilyPond, AFAICS. Hopefully, I'm wrong :-) > One could write a more robust and flexible MNX export with python > json handling, refactoring and building upon the xml-MNX-agnostic > functionality from musicxml.py. Maybe this would even be easier > than improving the xml export itself for next year's GSoC. Does > this seem like a suitable project? Good question. The thing is that while I work a lot on the `musicxml2ly` script that comes with LilyPond, I don't know how Frescobaldi's `musicxml.py` works... Maybe you can contact Peter Bjuhr directly (I don't know whether he is on one of the LilyPond mailing lists) and ask for more information. > I am unsure of how widely spread and implemented the MNX format has > become yet. The format itself is still very rudimentary and under heavy development, so there are zero implementations except some experimental ones. > Still, with active development of MNX, MNX-implementations and > MNX-converters > (https://github.com/w3c/mnxconverter?tab=readme-ov-file), it looks > like it's worth it looking into. It most certainly is, mainly because the people from the MusicXML standard think that MNX is the future. Werner
