Urs Liska <u...@openlilylib.org> writes: > Am 05.03.2015 um 21:28 schrieb Paul Morris: >> Urs Liska wrote >>> What you describe about the "Frescobaldi" approach is true, at least >>> that's where this approach is coming from. However, we are discussing >>> the other one too, because it would of course be very helpful to have as >>> much as possible done _within_ LilyPond. So this is not necessarily an >>> antagonism. By contrast, if someone were working (e.g. through GSoC) on >>> a way to represent LilyPond as XML the Guile way that would be very >>> interesting also for "third-party" development. >> Ok, thanks for clarifying. I didn't mean to suggest an antagonism. So it >> seems to me that a good approach for exporting would be: >> >> 1. In LilyPond use Scheme to convert the internal Scheme music data >> structure into an SXML version of this same data structure, call it >> "LilySXML". >> >> 2. Provide an option to output that LilySXML as XML ("LilyXML"). This can >> then be used by 3rd parties like Frescobaldi etc. Use the SXML Guile module >> to do the conversion from SXML to XML. >> >> 3. Use the SXML Guile module to convert the LilySXML to an SXML version of >> MusicXML and/or MEI. Then convert that to actual (XML) MusicXML/MEI. >> >> >> For importing, there's David K's suggestion, as I understand it: >> >> Use the SXML Guile module to go from MusicXML/MEI data files to SXML >> versions of this data and then convert from that SXML to the internal data >> structure with Scheme. This bypasses LilyPond's input text format. > > Everything correct. > I find especially the very last point interesting. > Being able to map an XML structure to a LilyPond-Scheme structure > through SXML seems like taking away many of the obstacles such a > conversion process has when having to deal with all the syntactic > special cases.
I also think it could likely make LilyPond more interesting for music typesetting/recording purposes in cases where the LilyPond input is not user-serviceable anyway and generated on the fly. We won't save much performance in that manner, but this should give a more reliably stable input format. Of course, using LilyPond itself for MusicXML export is also reasonably interesting. It's particularly interesting when the input is organized using significant amount of user-defined functions/markup. Depending on where in the processing one deals with the export, a lot of user-created programming/content might make it through processing. If one can write different "transcribers" for the \xml output (like we have "engravers" for the \layout and "performers" for \midi), different include files with \xml blocks might be tuned for the MusicXML import of different other notation programs. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel