>>>>> "GP" == Graham Percival <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user