Re: guilev1/2 musing

[Jan-Peter Voigt]

Hi there,

just a few words on my work on musicxml export:
There is an openlilylib project that provides an export command. It is based on 
an engraver that collects all events and builds an abstract structure that can 
be serialized by an export module. One of them writes MusicXML. Alex Roitman 
did a lot of work on it recently.
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.
The idea is to provide an export infrastructure that can be modified to add an 
export block like layout and midi are.
OTOH this project is based on the need to export files with the current used 
lily version.

Jan-Peter

Am 25. Januar 2019 16:43:55 MEZ schrieb David Kastrup <address@hidden>:
>Paul Morris <address@hidden> writes:
>
>> 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)
>
>They exist as Guile1 library, it's just that they are by default in
>Guile2.  If we decided prepackaging Guile1 was the way to go, including
>the respective library version should be feasible as well.
>
>No guarantees, but that was my impression.
>
>> to convert LilyPond's internal music data structures into MusicXML
>> output.
>
>> 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?
>
>Not really, and I don't think it makes sense to commit functionality to
>Guile2-only at this moment.
>
>> Then at some future point... either LilyPond moves to a future guile
>> or we back-port the guile2 procedures to guile1.
>
>"some future point" is just going to cause additional work.  We don't
>really have the personnel to do non-essential/non-trivial work on two
>separate implementations.
>
>> (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.)
>
>I haven't looked at Jan-Peter's approach.  David Garfinkle's code is
>mostly in the state of a solid first sketch, so a distribution-viable
>production-ready code is still quite a bit of work away.  Without
>anybody committed to take it considerably further, making decisions
>based on its existence would seem to be a bit premature.  Like with
>many
>open ends, this is more or less the "who decides to invest significant
>work gets to decide on the approach".  There is not much of a point in
>planning out in detail what nobody will pick up.
>
>> Thanks for the insights into the guile1/2 situation and what's
>causing
>> the performance hit.
>
>-- 
>David Kastrup
>
>_______________________________________________
>lilypond-devel mailing list
>address@hidden
>https://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.