[Top][All Lists]

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

Re: Google Summer of Code - Ideas List, please discuss

From: Reinhold Kainhofer
Subject: Re: Google Summer of Code - Ideas List, please discuss
Date: Wed, 15 Feb 2012 16:21:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0

On 12/02/2012 15:13, Graham Percival wrote:
> On Sun, Feb 12, 2012 at 12:03:48PM +0100, Janek Warchoł wrote:
>> 2) Adding comprehensive MusicXML import and export features, together
>> with test suites for it.  Requirements: ? (no idea in which language
>> this would be written), MusicXML, basic LilyPond and music notation
>> knowledge; familiarity with other scorewriters would be a nice bonus
>> (for cross-testing).  The goal would be considered achieved when a
>> (previously chosen) not-so-complicated score could be imported from
>> MusicXML and exported back with no (unintentional) loss of data.
> umm, you know that we already have musicxml2ly import, right?
> I agree with having this on the ideas list, but it should
> definitely mention and basic familiarity with
> python.  The export would most likely be in scheme, although it's
> not impossible to imagine that somebody might write a relatively
> simple scheme exporter to an intermediate format (or just use
> \displaymusic{} ), then use python to construct the actual
> musicxml file.

That's bound to fail. LilyPond has so much processing going on in the
engravers, that the MusicXML exporter would have to duplicate most of
that. To me it makes much more sense to build on the result of the
iterators and engravers, rather than having to duplicate most of them in
custom code.


Reinhold Kainhofer, address@hidden,
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 *, DVR: 0005886
 * LilyPond, Music typesetting,

reply via email to

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