[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guilev1/2 musing

From: Paul Morris
Subject: Re: guilev1/2 musing
Date: Sat, 26 Jan 2019 20:30:31 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

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:
OpenLilyLib code:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]