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 _______________________________________________ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user