Re: Google Summer of Code 2015

[David Kastrup]

Urs Liska <address@hidden> 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