[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: Fri, 25 Jan 2019 09:46:10 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 1/24/19 3:08 PM, Thomas Morley wrote:

 From my point of view (and limited knowledge) other newly implemented
guilev2-procedures are not _that_ important.

One area where guile2 (and upcoming guile3) would be useful is for MusicXML export.  David Garfinkle's summer of code project (mentored by David Kastrup) made a start on using guile2's sxml and pattern matching procedures (which aren't in guile1) to convert LilyPond's internal music data structures into MusicXML output.

One option would be to 'back-port' those procedures to a guile1 implementation, then further work on MusicXML export could happen with guile1, and the code would also work with guile2.  However, when I took a cursory look, rewriting those procedures looks non-trivial, and the effort would probably be better spent in other ways.

Since guile2 appears to work well enough at this point, aside from performance, would it be worth setting up a "guile2 and musicxml export" branch where we could land David Garfinkle's code and enable further work on MusicXML export?  It seems like a guile2 branch already exists to some extent?

Then at some future point... either LilyPond moves to a future guile or we back-port the guile2 procedures to guile1.

(Jan-Peter Voigt has also done separate work on MusicXML export, but my sense is that in the long run, the approach in the summer of code project would be preferable.)

Thanks for the insights into the guile1/2 situation and what's causing the performance hit.


reply via email to

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