Re: convert-ly problem

[Laura Conrad]

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

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

    HN> I seem to recall that you and I have been through this discussion 
    HN> before, and probably more than once.  If you need absolute stability, 
    HN> you have the following options:

    HN> * Use tools which have stopped developing. SCORE would be a candidate, 
    HN> as well as various musictex flavors.

I keep an eye on the musictex stuff, but find it pretty difficult to
use.

    HN> * Develop your own intermediate format, which you can convert to the 
    HN> syntax du jour.

I'm more or less attempting to use the ABC source for that.  My
current plan is to be a bit better organized about how I modify the
lilypond that abc2ly outputs, so that I can then just figure out how to
translate the changes to new versions.

    HN> * Build statically linked binaries, and store them in a safe place, 
    HN> together installation disks of your distribution.

I have attempted this with other programs, which seemed smaller and
simpler than lilypond, without success.  (Does anyone know how to run
spider or ical on a modern linux system?)  If I understood more about
the changes in the underlying C libraries, I might have more success,
but my impression is that the people who understand those changes do
the same thing I do, and find maintained programs with similar
functionality (pysol and netplan in the case of spider and ical
respectively).

    HN> I have the feeling you are trying to make me feel guilty about
    HN> changing things and/or want me to spend an inordinate amount
    HN> of my time on your specific problems. If that's the case,
    HN> you're failing.

I'm sorry if I said anything that seemed to be taking this discussion
to a personal level.  My intention was to point out that, because of
the success of lilypond as an electronic music publishing program
(which you should feel proud of), a different development model might
be appropriate now than the one that worked so well when it was just
you and Jan.

    HN> Also, you have to keep in mind that the longer you postpone
    HN> upgrading the .ly files, the more work it will cost. At some
    HN> point, everyone, including myself, will have forgotten the
    HN> details of the 1.4 syntax.

That's why I'm raising the issue.  I would in fact like to be doing
things that I will need help from the list for, such as Dowland-style
lute tablature, and I'm aware that there are very few people who know
that stuff at all, and most of them probably don't currently know it
for 2.0.  (I've forgotten everything I ever knew about 1.4, too.)

    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. 

    HN> Paid-for features get the same treatment as other features
    HN> that I added.  I know you would to like to have hard
    HN> guarantees about stability, but as I explained above, I can't
    HN> give those.  

I don't think that's exactly what I'm asking for.  Of course I love
being able to go back to any LaTeX file I or anyone else has ever
written and use it to figure out how to do something this year.  But
for lilypond, I'd just like to know that when my code becomes useless
someone has:

        Realized that they were making the change.  

        Discussed the benefits of the change with someone who
        is going to lose by the change.

        Done some kind of cost/benefit analysis that says that the
        change is worth the problems it will cause.

Right now, I don't see that kind of discussion happening, which
suggests that if it's happening anywhere, it isn't on the
lilypond-user or lilypond-devel lists.  And if I'd paid for a feature
that was going to be changed or discontinued, I would certainly want
to be included in such discussions.

To take an example that isn't a major problem for anyone, what led to
the choice of lyrics font in 2.6?  Did anyone who actually publishes
vocal music have any input into that selection, what other fonts were
considered, and why was this one decided on?  It seems to me that
there are enough lilypond users affected by this that it should have
been discussed.  I know any experienced user who doesn't like it can
probably figure out how to change it to something else, but it is the
public face of what you can do with lilypond, and these hordes of
potential new users you're trying to attract will be making their
decision based on what the default looks like.

    HN> I can say that 2.6 will be a lot more stable, because we fixed
    HN> a lot of kludges that were in the 1.x branch).  For example, I
    HN> can't recall any reports of serious breakage between 2.4 and
    HN> 2.6

I remember someone pointing out quite recently that he was using 2.7
because of a problem with lilypond-book in 2.6.  But I agree that 2.6
is remarkably similar to 2.4 considering how many changes happened.

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

    HN> I recommend you to use the autopackages; they're less fuss to
    HN> install, and they're made from snapshots that are known to
    HN> work - somethign which can't be said of CVS.

I seem to have better luck with CVS.  I haven't reported my
autopackage failures because it seemed that other people were
reporting similar problems, but I will if you think you've fixed all
the problems that were reported before yesterday.

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

    HN> Also, "At the moment" is a bit of a misnomer if you are
    HN> complaining of upgrading out of files which you entered over 4
    HN> years ago.

"At the moment" may have been a poor choice of words, but it does seem
that the syntax changes over the last year have been more fundamental
and far-reaching than previous changes.  That is, previously, I've had
to deal with issues like "How do I tell lilypond not to automatically
assume melisma in some circumstances?", now I have to deal with "How
do I find the start of the note entry given that there's no longer a
'\notes' statement?"


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