Re: convert-ly problem

[Erik Sandberg]

On Wednesday 27 July 2005 16.59, Laura Conrad wrote:
> >>>>> "ES" == Erik Sandberg <address@hidden> writes:
>     >> I'm willing to believe there is no automated way to convert every
>     >> possible \addlyrics to an equivalent \lyricsto.  I don't believe
>     >> that the most common cases couldn't be handled.  For example, two
>     >> verses, with a chorus appended to the first verse, as in the example
>     >> I submitted.
>
>     ES> The main problems are:
>
>     ES>  - Two verses now require two separate Lyrics contexts.  -
>     ES>  Convert-ly is regexp-driven. If you can figure out a nice way
>     ES>  to express a ES> partial \addlyrics -> \lyricsto conversion
>     ES>  rule with regular expressions, ES> this would be very
>     ES>  welcome.
>
> I was building lilyond at the end of the 2.5-2.6 development cycle,
> and was able to contribute code in a small way.  Since then, the
> dependencies have changed so that my system no longer builds lilypond
> in either the 2.6 branch or the 2.7 branch.  Since Serpent
> Publications (me) has decided that the costs outweigh the benefits of
> converting to 2.6 (see
> <http://www.laymusic.org/cgi-bin/blosxom.cgi/2005/07/21#050721-lilypond>
> for the rationale behind this decision), I really can't justify
> spending time figuring out (again) how to get a build environment for
> a program I'm not going to really be using.

This is understandable (and it is why there now is an autopackage).

When it comes to convert-ly, you can write patches for 2.4 or 2.2 if you like 
- there should be no problem to front-port them to 2.7.

> Does anyone know how much lilypond out there is orphaned?  Between the
> fact that old versions of lilypond don't run on modern machines and the
> fact that there's a lot of lilypond that convert-ly doesn't handle,
> there must be a lot of stuff that nobody can compile  without major
> manual labor.  At what point is this volume of stuff going to feed
> into design decisions?  Surely the lilypond developers want people to
> be able to transcribe something and still be able to use it a year or
> even 10 years from now?

I agree this is a problem. There are however two distinct sub-problems:
(a) Getting what was previously written, to work with the current lilypond.
(b) Making sure that everything that works with the current lilypond, will 
continue to work in the future.

IMHO, we have improved a lot on (b); e.g., lilypond 2.6 still accepts files 
marked with \version "2.4.0". And I am currently working on a project which 
hopefully will give us full future compatibility.

For this reason, it might be wise for you to wait with upgrading lilypond: If 
you need to do manual work to get a piece working again, you could just as 
well wait a year or so for a version that promises that you never should have 
to do that again.

When it comes to (a) above, the situation isn't very good as you say. It is 
very hard to handle the more complicated cases: To rewrite pre-2.2 lyrics to 
post-2.2 syntax, we need something stronger than regexps AFAICS. Keeping the 
old commands compatible, would require that we added a couple of new context 
types (context OldLyrics and context OldLyricVoice). I doubt this is 
possible, since
(1) it should have been done on 2.2 already; since convert-ly should convert 
the old "Lyrics" to "OldLyrics" in conversion only when going from 2.0 to 
2.2, this would be incorrect to do since 2.2 doesn't understand what 
OldLyrics means. (I think one could use hacks to work around this)
(2) I doubt that Han-Wen would accept to add & maintain new context types for 
maintaining poorly-designed old functionality (but I don't know).

So to your question:
> At what point is this volume of stuff going to feed
> into design decisions? 
To me it seems that the policy changed somewhere around the 2.2 release, after 
some people (including you, IIRC) made clear that this is a serious problem. 
The real problem was actually that some lyrics related code was poorly 
designed at an early stage. When this was fixed, one result was that syntax 
changes in some cases were too complex to be automatically handled.

I can't really speak for the development team, so I'm CC:ing a copy to 
Han-Wen: Please correct me if I'm wrong on some points.

Erik