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

[Simon Albrecht]

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

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
> discussion.
>
> 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