Re: Evolutionary User Strategery

[Erik Sandberg]

Please always CC to the list.

On 7/12/06, Ian Hawthorn <address@hidden> wrote:
> My 0.02c
>
> The lilypond language is still evolving.  Recent changes in syntax
> have improved usablity.  However at some point the improvements
> to be gained by further tinkering with the syntax will be outweighed
> by the nuisance factor of having to frequently update/rewrite scores.
> I don't think we are quite there yet as I still find the syntax awkward
> for certain things. But it will happen at some point. Yes?
>
> I think we need to look at tex as an example of the way forward.
> I have tex files which I wrote back in the mid 80s which still
> run just fine. The core of tex has been standard and static now for
> a very long time. Yet tex continues to evolve via its package structure.
> Maybe lilypond should look at doing this.
>
> If the size of the codebase is a problem, a package structure would help.
> I really have no need of weird medaevil musical notation, six line staves,
> guitar tablature,  drum staves, strange clefs, notation for quarter tone
> notes, etc etc. Others may not need the capacity to deal with polyphony
> and lyrics which for me is essential. Yet every copy of lilypond comes
> with everything.
>
> A package structure would also help to manage the growth of the project.
> Features could be added by adding packages, and it would be clear who
> was supporting what.
>
> In addition to its package structure, tex also uses style files. lilypond
> could look to do the same. The templates now in the documentation
> look to me to be embryonic style files, and seem to want to evolve in that
> direction.
>
> Finally, I'd like to eventually see something analogous to latex for
> lilypond -
> a package providing higher level syntax to make score writing less technical
> for the average user.
>
> Ian H

My 2 öre:

- A precondition for much of what you suggest, is a stable API: If we
decide a specific format for add-on packages, then all such packages
will break as soon as we change the API. Right now, I'm working on
introducing *two* new intermediate music representation formats to
lily. I see this as an indication that it will take some time before
it's time to define a stable API.

- Package size is not a problem, as long as it doesn't grow insanely
large (e.g., I wouldn't think it's sensible to multiply the package
size by the number of previously released versions).

- There are many problems to bridge; e.g., the syntax of lots of
features (lyrics, figured bass) are built into the .ly language, so
parser rules would have to be soft-codable.

- I hope you know about LSR, the lilypond snippet repository. So far
the LSR is rather small, which indicates that there is little public
interest in building add-on packages to lily. Currently, there seems
to exist few lily gurus (=people with so advanced knowledge that they
could have written LaTeX-style add-on-packages). So far I think it's
better if those people get involved in lily directly, and perhaps
contribute some snippets to the LSR. As long as LSR doesn't contain a
very large number of general utility .ly snippets, I don't think it
makes much sense to invent an add-on package system.

- I have the impression that Han-Wen is even more user-oriented than
me (i.e., he doesn't add features without proof that users need them).
So the best way of convincing _him_ that we need a system for add-on
packages, is probably to get involved and try to write some packages
yourself, using the (limited) mechanisms that exist.

Erik