Re: convert-ly problem

[Laura Conrad]

>>>>> "GP" == Graham Percival <address@hidden> writes:

    >> Which "we" is that?  I really think I'd remember a discussion of
    >> convert-ly not converting lyrics any more if it had happened on either
    >> lilypond-user or lilypond-devel.

    GP> I think that Erik is talking about this:
    GP> http://lists.gnu.org/archive/html/lilypond-devel/2004-12/msg00104.html

    GP> Lyrics weren't mentioned specifically, though.

No, and the implication is that converting 2.0 to 2.6 will be
unproblematic, which doesn't seem to be the case.

>>>>> "HN" == Han-Wen Nienhuys <address@hidden> writes:

    HN> Laura Conrad wrote:
    >> 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?
    HN> When either

    HN> 1. the number of future (potential) users is smaller than the
    HN> number of current users.

How about considering whether there would be more future potential
users if the half-life of lilypond code were longer?

    HN> 2. the current users start to pay me for better support of
    HN> older versions.

I'm not really a potential customer of this feature, since my current
income level is low.  But if I were, I would want to know what kind of
future support a paid-for feature could expect. Is a paid-for feature
just as subject to change without discussion as the non-paid-for
features?

    HN> You might want to try your luck with displayLilyMusic
    HN> though. With that, it should be possible to read something
    HN> with \oldaddlyrics and rearrange it for \lyricsto. 

If I manage to get a working lilypond development environment again,
I'll look at it.


>>>>> "ES" == Erik Sandberg <address@hidden> writes:

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

    ES> I agree this is a problem. There are however two distinct sub-problems:

    ES> (a) Getting what was previously written, to work with the
    ES> current lilypond.

    ES> (b) Making sure that everything that works with the current
    ES> lilypond, will continue to work in the future.

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

I'm glad to hear this.  I agree that (b) is more important than (a),
and if I were convinced that (b) had happened starting on 2.6 (or 3.0
or whatever), I might not mind doing some conversion by hand (although
I'll probably keep the giant Dowland project (almost finished) and the
large Morley projects (data entry finished, although some transposed
versions are in the works) in earlier versions.

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

I would definitely do that if I could still run the version of
lilypond it worked on.  Unfortunately, I was a very early adopter, and
still have a lot of 1.4, and maybe earlier code.  I forget the details
of why I can no longer install or run 1.4 on my system, but it looked
like rewriting the lilypond was more likely to be successful than
unraveling the dependancy tree.

I understand that the reason lilyond is more system-dependent than,
for instance, the (other) ABC output apps is that it uses much more
sophisticated integration with the rest of the system, and this is
also why the output is better.  However, it really does put more of an
onus on the developers to support upgrade paths.  

People who publish their work electronically aren't doing it just
because they want a pdf file this week -- they really expect that next
month or next year or 10 years from now, if they (or someone elsewhere
on the world wide web) want a pdf file with the notes transposed or
different clefs or larger fonts or different paper size..., they'll be
able to get it out of the same code, without completely reconfiguring
their system and risking breaking email.

At the moment, lilypond isn't really promising that, or if it is, it
isn't delivering very well.

    ES> So to your question:
    >> At what point is this volume of stuff going to feed
    >> into design decisions? 

    ES> To me it seems that the policy changed somewhere around the
    ES> 2.2 release, after some people (including you, IIRC) made
    ES> clear that this is a serious problem. 

I think several of us tried; I'm not sure we succeeded, based on
Han-Wen's remarks above.  

-- 
Laura (mailto:address@hidden , http://www.laymusic.org/ )
(617) 661-8097  fax: (501) 641-5011
233 Broadway, Cambridge, MA 02139