Re: guilev1/2 musing

[Paul Morris]

Hi Jan-Peter,

On 1/26/19 1:36 PM, Jan-Peter Voigt wrote:
> sorry for missing to mention your contribs! And thank you for the XML 
> port.


Oh, no problem, and you're welcome!

> I didn't look into the gsoc code lately, but perhaps the two projects 
> dont need to compete?

Yeah, it would be nice to consolidate the two efforts somehow.  If you 
have a chance, it might be worth taking a look at the gsoc code.

Basically, the gsoc approach doesn't collect events with an engraver and 
then build up a data structure from them.  It rather converts a music 
expression into an s-expression data structure, same/similar as what you 
see when you do \displayMusic.  This is where its approach seems 
potentially simpler.

Then it uses the pattern matching and SXML modules to transform the 
s-expression data into MusicXML.  This part (transforming some data into 
MusicXML) seems fairly similar in both approaches (either using the 
pattern matching module or just vanilla Scheme).  So the first part of 
how to get at the data seems like the key question.

I'm not sure what the impact of these approaches is for how the user 
might ultimately use the feature.  Maybe not much.  Having export blocks 
like layout and midi, as you mentioned, seems like a nice consistent 
interface.

> The functions to build XML are copied from guile 2 so they can be 
> easily adapted if they are included in a guile 1 fork or via guile 2.


Some more detail on this: these copied functions are only a small part 
of the SXML module, just the ones to convert from sxml to XML.  These 
were easy to copy.  The gsoc code uses the pattern matching module and I 
think more of the SXML module, which didn't appear to be as easy to copy 
and use with guile1.

Here are links for anyone curious:

GSOC code: https://sourceforge.net/p/testlilyissues/issues/665/#6428
OpenLilyLib code: https://github.com/openlilylib/lilypond-export

Cheers,
-Paul