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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
