Re: MusicXML exporter (was Re: Lilypond lobbying?)

[Pierre THIERRY]

Scribit Kieren MacMillan dies 24/08/2011 hora 20:00:
> > 1) XML that captures only the music […]
> No: this is trivial to obtain from #2 or #3, via XSLT.

To stay in mathematical lingo, I'd say the issue is that, although it
is indeed trivial to obtain #1 from #2, the problem of getting #2 in
the first place may be undecidable in the general case.

I'm actually pretty certain that it is undecidable, as for any
translation between two systems that are not equivalent, and that's
why it will never be a "perfect" translation.

So it will be an imperfect translation, covering as much as possible
of the subset of Lilypond that is mappable onto MusicXML.

And the real question is: how much do we cover at first?


For what it's worth, I suspect that only exporting the music at first
would be both relatively easy for the programmer (which may be me, so
that's also appealing) and very useful to the users.

One of the main needs seems to enable Lilypond composers to interact
with publishers and engravers that use MusicXML-savvy software. In
this case, the latter probably don't care about layout, they care
about music (correct me if I'm wrong), because they want to specify a
layout for themselves, according to their own guidelines and habits
(which, yes, may well be worse than Lilypond's default automatic
layout, but that's life).

One other important need is the cooperation between composers. In this
case, I suppose the not Lilypond-using composer probably doesn't want
to tinker with the layout and send back the adjustements (BTW, would
musicxml2ly really support that by outputting a meaningful, diffable
to the original, .ly file? that seems insanely difficult). I expect
most of them want to play the music and tinker with the music, to send
back adjustments on the musical composition, not on its layout.


And finally, I oh so strongly support the idea that you succeed with
baby steps, even if the baby steps are directed towards a very
ambitious goal. There should be a clear deliverable after a reasonably
small amount of work. That is possible with #1, probably not really
with #2 or a far less interesting "product".

Quickly,
Pierre
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature