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

[Urs Liska]

Am 25.08.2011 01:48, schrieb Carl Sorensen:

On 8/24/11 5:31 PM, "Michael Ellis" <address@hidden> wrote:

On Wed, Aug 24, 2011 at 6:34 PM, Kieren MacMillan
<address@hidden> wrote:

Hi all,

In short, the only way to make it extendable for the future (so
that one day we can also export the layout) is to handle (MusicXML) export
similar to MIDI generation, namely via translators that collect all events

and

all settings as they appear in the score.

+1.
KMac.

This makes sense.  A standalone converter would, essentially, have to
duplicate Lily's internal logic.  Why write the same code twice?

Hence the importance of Jan's original comment.  We need to clarify what is
wanted.

Do you want

1) XML that captures only the music (and could be imported into some other
program which will make the layout decisions)?

2) XML that captures both the music and the layout (and could therefore be
printed by some as-yet-unknown MusicXML printer)?

3) Some other XML that I haven't thought of?

My sense is that item 1) is relatively inexpensive (as Jan has discussed),
but that item 2) is relatively expensive (I think it's more than 100 expert
hours, but that's just a wild stab).

For me, item 1) is what we ought to be aiming at, at least initially.  It
seems strange to use Finale to print a layout defined by LilyPond.  If you
want to use a LilyPond layout and tweak a few things graphically, you should
be using the svg output, IMO, and editing the svg.

I think that holding out for 2) will probably delay completion of 1).

But having a well-defined enhancement request will at least allow a
developer to make a decision as to what they wish to attempt.

Thanks,

Carl


_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user

From what was discussed recently and in earlier discussions, I would really second your arguments.
Providing option 1) would allow this bidirectional openness we are talking about.
This will give

• ... potential LilyPond users the trust that they can get their work back into the software they are used to
  (a similar effect that NTFS support under Linux had)
• ... LilyPond users that for some reason or another are obliged to provide files for other software the possibility to do so.

It may however be useful to discuss how a given approach to 1) would affect the implementation of 2)
I think 1) should be done in a manner that can be further developped to a solution of 2)
(As I know way too little about (Music)XML and practically nothing about LilyPond's internals, I can't actively participate in these necessary discussions.)

Best
Urs