[Top][All Lists]

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

Re: Reasons why a LilyPond-to-MEI conversion should be developed

From: Urs Liska
Subject: Re: Reasons why a LilyPond-to-MEI conversion should be developed
Date: Sat, 24 Oct 2015 11:26:19 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Am 24.10.2015 um 03:18 schrieb Paul Morris:
> I think the same considerations that apply for MusicXML also apply for MEI.  
> See the discussions about the Google summer of code project from last spring. 
> Namely, LilyPond’s internal scheme data structure is a good target for import 
> and export (better than LilyPond’s plain text input syntax), and it is easier 
> to start with export to MEI which will give you a good sense of the mapping 
> between the two formats, and then it will be easier to work on the import 
> path.  

This is true but probably not enough for argumenting in a grant
application. I think it would be a valid argument if there were inherent
reasons why a mei2ly conversion would *only* work on top of an
implemented ly2mei conversion.
The perspective of our project and application is: "Integrate
professional engraving in current digital edition
infrastructure/contexts". So the question is not "why would that be
useful for LilyPond or easier as an approach" but "What does this
building block (ly2mei) add to the digital music edition ecosystem."

This is the background for our chance to get a serious development
project funded and bring LilyPond forward in a number of respects (which
I can't even disclose already).


> Also you can build on whatever work is done for MusicXML, which I assume has 
> already begun through the summer of code work.  Hmmm… what’s the latest on 
> that anyway?  
> -Paul
>> On Oct 23, 2015, at 11:44 AM, Urs Liska <address@hidden> wrote:
>> Hello devs,
>> I would like to get some feedback for use when preparing the mei2ly
>> application. I will deliberately not say what I think about the topic to
>> get less influenced opinions.
>> We will have to define a scope for the project that is sufficiently big
>> and at the same time not too small. Apart from what we may be interested
>> in it's important to be plausible and credible in order to get the
>> application accepted.
>> mei2ly, the possibility to use LiylPond to engrave MEI encoded editions,
>> is clearly the foundation of the project, so there's nothing to argue
>> about that. There are technical aspects, e.g. if LilyPond should consume
>> MEI or if a converter should produce LilyPond input (or to have both),
>> but the conversion direction itself is of course a prerequisite of all
>> discussion.
>> The other way round is less clear. Should it be possible to convert
>> LilyPond scores into MEI data? If yes, is it a requirement to have a
>> "general-purpose" export filter that can (ideally) handle arbitrary
>> existing LilyPond files or is it acceptable to define a certain subset
>> that (new) projects are allowed to contain?
>> I am convinced we should have this, for several reasons. But I think it
>> is not so clear from an outside perspective, of someone working in the
>> MEI field and even more of someone having to decide about the application.
>> So, before I'm going to write about my thoughts and feelings about it
>> please tell me what you think. We should have good arguments in order
>> not to slip through the net ...
>> Best
>> Urs
>> _______________________________________________
>> lilypond-devel mailing list
>> address@hidden

Urs Liska

reply via email to

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