constructive criticism

[John Williams]

Someone asked for contructive criticism of lilypond.

First, a little deconstruction...

Lilypond's note syntax is great.  The problems start when you want to
\override some default behavior. I think this paragraph typifies the
problems with lilypond:

> This object is created whenever a Staff context is created. The
> appearance of the staff symbol cannot be changed by using \override or
> \set. At the moment that \property Staff is interpreted, a Staff
> context is made, and the StaffSymbol is created before any \override
> is effective. Properties can be changed in a \translator definition,
> or by using \applyoutput.

In other words, if you don't like the default, the only way to change it
is with a complicated hack which requires an expert in scheme, tex,
postscript, and lilypond internals to figure out. If you cannot find a
preexisting recipe or someone to write one for you, you are screwed.
(Relevant example in this context: how do I create a staff group with a
brace on the left, but without connecting the barlines?)

Basically, I think a lot of thought needs to go into finding ways to make
lilypond easy for the user instead of easy for the programmer.  Nearly
anything is possible in lilypond, but the only things that are easy are
those things the programmers have anticipated that you might want to do,
and provided an example or shortcut for it.


Now some reconstruction...

Here's an area I have been thinking about.  There are a couple of
different types of properties, and each have different methods of setting
them.

   context properties.
   \property Staff.autoBeaming = ##f
       (context.variable)

   layout properties.
   \property Voice.Stem \override #'thickness = #3.0
       (context.object ... variable)

The second style is incredibly verbose.  Why not just:
   \property Context.Object.variable = value

And how about a better way to scope settings than \override and \revert:
If every \sequential { } or \simultaneous { } defined a new scope
for settings, then they could just expire at the ending brace (or >>).

And actually \property is rather too long.  Just \set would be better
(but that might not be backward compatible).

Following this proposal, this simple example:

c'4 \property Voice.Stem \override #'thickness = #4.0
c'4
c'4 \property Voice.Stem \revert #'thickness
c'4

would look like this instead:

c'4
{ \set Voice.Stem.thickness = #4.0
c'4
c'4
} % \set expires at end of scope
c'4

It would be nice to extend the scoping idea to fix the problem with the
Staff context described in the paragraph above.  Instead of "\property
Staff" automatically creating a new Staff context, it would store the
setting somewhere, so that new Staff contexts created in the same scope
could inherit their default values from it.

~ John Williams