[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: Simon Albrecht
Subject: Re: Reasons why a LilyPond-to-MEI conversion should be developed
Date: Sat, 24 Oct 2015 01:39:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 23.10.2015 17:44, Urs Liska 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.

That’s tautological the way you wrote it. Do I get you right interpreting this as ‘should be ambitious but realistic’?

  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 LilyPond 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

Interesting thought. I should be surprised if MEI were to consent in granting LilyPond this honour (as which I’d consider it). Given the ‘universal’ intent of MEI, they might not want to ‘take sides’ with LilyPond (as opposed to other typesetting software) in such a complete and definite way.

  or if a converter should produce LilyPond input (or to have both),
but the conversion direction itself is of course a prerequisite of all

The other way round is less clear. Should it be possible to convert
LilyPond scores into MEI data?

From the code samples I’ve seen, I can’t seriously imagine anybody _entering_ music in .mei directly. So there must be some kind of ‘frontend’ for the input. And I’d argue that .ly is a serious candidate for this because it compromises between a syntax apt for reading and writing by humans, and the ‘structural integrity’ and semantic appropriation which is necessary for a project like MEI. Certainly, there are downsides too: LilyPond’s input format is – through the Scheme interface – extensible without limit, and it’s plain also that there are too few definite standards on coding style. So in the context of this mei-ly topic we have to reconsider GLISS, which would have been due, yet was postponed for years now. And putting up stricter standards for .ly input files is a daunting task, since there are good reasons for the current diversity: ranging from a single-file melody of less than 50 lines of code, requiring only the most basic and simple constructs, to something like the ‘Trunknes Lied’ project or an oratorio edition like Nicolas Sceaux did several, making excellent use of a highly individuated setup involving a complex directory structure, using build and maintenance scripts featuring not only Scheme, but also Python and/or Makefile (which latter is even recommended in Lily’s documentation!). One must doubt if it is at all possible, but it’s at least most difficult to find a balance here, and a viable solution working for all this diversity at once… The small melody I mentioned would be converted to .mei with fair ease, for the largest projects it would surely be impossible. But neither is it possible to produce such works in LilyPond without a very sophisticated setup. The examples are extreme of course, and I imagine the Messiah would be split in one .mei file per movement. Yet – a lot to consider there…
So far some thoughts.

Yours, Simon

reply via email to

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