Re: Supporting my work on LilyPond financially

[David Kastrup]

Kieren MacMillan <address@hidden> writes:

> Hi David,
>
>> I'm always a bit surprised about the low resonance on features like
>> 
>> <URL:http://code.google.com/p/lilypond/issues/detail?id=3648>
>> Issue 3648: Patch: Isolated durations in music sequences now stand for
>> unpitched notes
>
> It’s a nice feature… but applicable, I would imagine, to a
> spectacularly small percentage of users. I, for one, can think of
> exactly three staves (and then only a fraction of the measures in
> those staves) in I would have used this feature, out of the last
> several thousand that I’ve engraved.
>
> On the other hand, something really useful — and helpful in getting
> users “out of the code” — would be the ability to say:
>
> lastCymbalCrash = {
>   \atMoment (256 . 1) b4\accent\sff
> }
>
> and then output a 256-measure part (complete with rests, time
> signatures, etc.) for the poor cymbal player with
>
> \score {
>   \new RhythmicStaff << \theGlobalStuff \lastCymbalCrash >>
> }

What makes this hard is that lengths are precomputed, this may lead to
weird side effects.  Now to be honest, \lyricsto has the same problem.
I'm not sure this isn't related to some obscure bugs...

> Or how about
>
> \score {
>   \new Staff \with { \lineBreaksAt (5 10 17 21 26) \pageBreaksAt (17)
> \autoBreaksOnAt (26) } \theMusic
> }
>
> Or any of a dozen other functions I could dream up in a few minutes
> which would make life easier here in the trenches.

So dream them up, one by one, and either let them first be discussed
here, one by one, before preparing an issue report.  Yes, some may end
up as "invalid" or as not compatible with how LilyPond does things, and
some may sit years in the tracker.  When preparing a careful proposal
fitting with the rest of LilyPond, this may be somewhat deflating.

>> most of the time I'm left alone with figuring out what might work
>> best for people.
>
> This, I think, is the key problem with "front-end” Lilypond
> development right now: there are spectacular things going on in the
> "back-end" — prerequisites, of course, for real advance(s) to the
> “front-end”

No, that's rather independent.  The frontend is about how much it sucks
to tell LilyPond what one wants, and the backend is about how much it
sucks what LilyPond does once it has understood what is wanted.
Dependencies come into play only when LilyPond has no useful concept
representing the idea to be presented to the frontend.

> — but there are few real quantum leaps on the user side that mean
> anything to people who are cranking out real-world scores on a daily
> basis. And those are the ones that reduce the well-documented inertia
> that keep many users from switching to Lilypond.

Well, we have by now a slowly growing number of power uses that crank
out ad-hoc solutions.  At some point of time we need to integrate a few
of them back into LilyPond when they are often asked for, being
reasonably careful that this makes sense as a whole.

> When 2.18 is out, perhaps the ‘Pond would benefit from a discussion of
> what real-world functions might bring us closer to some of those
> “huddled masses yearning to be free”.

We'll certainly need to get a better idea how to grow better without
getting different tasks in the way of each other.

-- 
David Kastrup