Re: MusicXML

[Han-Wen Nienhuys]

address@hidden writes:
> > > more than finding the closest mudela equivalent for every MusicXML
> > > directive.
> > 
> > There is no good technical reason to read MusicXML directly into
> > lilypond, so I prefer to keep it outside.
> 
> An explanation for why you say this would be an answer to my original
> question.

Because it takes one simple thing (musicxml) and a complex thing
(lily) and combines them into a bigger, more complex thing.  Unless
there is a specific technical advantage for doing so, making more
complex things is a bad idea.

And no: integration doesn't help with the quality of the import. That
is simply determined by how much efforts the musicxml -> lily
maintainers put into the support. And as you have perhaps noticed, I do
not volunteer for this effort.

> >   As for the "lilypond
> > developers" opinion: I've personally spent a lot of time writing
> > convertors (etf2ly, pmx2ly, musedata2ly, etc.) only to find out that
> > noone uses them.
> 
> Would you use a compiler that required you to first run your source file
> through an external program that translates your program into a
> different language with vastly different semantics?  Would you feel that
> you can count on every construct in the target language being translated
> correctly?
> 
> Even assuming this translation can happen in a robust way, in this case
> the target language (mudela) is changing all the time; what if the
> converter becomes unmaintained?  It will no longer be usable.
> 
> Surely you can appreciate the different between native support and
> support that requires an external converter.

I think that you are missing the point: "native" support can just as
well be unmaintained: we change the internals of the program all the
time (more often than the input language), and if noone maintains the
"native" support for something, we remove it from Lily. Since removing
features from lily is something we rather not do, we only integrate
features that either

  1. we ourselves need, or

  2. comes with an offer to actively develop and maintain the
respective code. An example of this is the ancient notation support.

Since musicxml does not fall under 1., it falls under 2., which brings
us to the next point

> > > It seems that
> > > supporting this format would benefit everyone involved.
> > 
> > MusicXML is neither a particularly advanced or complicated format. Why
> > don't you try implementing support yourself and "scratch your own
> > itch"?
> 
> I was thinking about trying sometime, but I didn't know how it would fit
> architecturally into lily; I posted my question hoping to gain this
> information.  I really have no idea how lilypond is put together (even
> though I have used it some, and contributed two scores to the mutopia
> project).  I am especially unclear on the division between TeX, C++, and
> Guile.  I was hoping to find out if lily's architecture would make it
> easy to write another language front-end or not.

Sorry -- the source and the manual is all there.  Please study it
first. Answering specific questions is much easier than trying to
bring across philosophical ideas of program development and
maintenance.

-- 

Han-Wen Nienhuys   |   address@hidden   |   http://www.cs.uu.nl/~hanwen