2.12 is out

LilyPond 2.12.0 is out. Go. Download. It. Now. Seriously...it's wonderful! :-)

The Future of the Internals Reference

I hope you're prepared for another...ahem...*nerdy* post from me. As you have probably noticed, I care about LilyPond a lot. And guess what? The ``Internals Reference'' is a piece of the LilyPond documentation. So again, another post relating to LilyPond. Though LilyPond's Learning Manual and Notation Reference do a good job of explaining how to navigate the Internals Reference, this manual needs some major improvements. And since the Internals Reference is automatically generated from source code, these changes will likely be non-trivial to implement (except for the developers that are proficient in Scheme):

1. The ``Music expression'' pages should indicate which ``Music properties'' they support. Implementing a new collection of pages similar to the ``Grob interface'' pages would be nice.
2. What are ``Music classes''? I have a vague idea from browsing through the manual, but this concept should be cleared up.
3. The list of grob interfaces on the grob pages should be placed above the list of standard settings, i.e. near the top. The current structure is less efficient from a navigation point of view.
4. Every grob page should list *precisely* which grob properties the grob supports and *from which* grob interface each grob property belongs. If a grob *supports* an interface, this doesn't mean it supports *every* grob property in the interface; this is why documenting *only* the grob interfaces is less than ideal. However, implementing a system that improves the current setup might require more ``data dumping'' from the C++ side.
5. The following items should be differentiated from the source code itself and not hardcoded in Scheme code: (a) Tunable versus internal context properties, (b) Tunable versus internal grob properties, (c) Whether or not a grob support a particular grob interfaces, (d) Precisely which properties a grob supports.
6. Brand new sections need to be added to ``4. Scheme functions''. As I noted in an earlier post, there are *many* more Scheme functions available than the ones listed here. However, I admire this section in that it is *truly* auto-generated from source code. Every other section is too hard-coded to be completely useful.

As it stands, the Internals Reference is a wonderful resource, but it needs to be more of a "living" document than it is right now.

New Glyphs!!

Sweet! Check out these new arrowed-accidental glyphs that have just been added to LilyPond: These are pretty awesome. I really want to learn Metafont *now*. But there are many programming languages in the queue right now. :-) Many thanks to Maximilian Albert and Werner Lemberg for adding these glyphs. Cheers!

Scheme and Lily

A very interesting discussion is happening on the LilyPond Development mailing list (starting here) relating to improving LilyPond's support for tablature notation. LilyPond's syntax, as mandated by the parser, caters more to "note-centric" input; however it seems that tablature notation is best written in terms of "finger positions" without having to worry about what notes are indicated. This got me thinking about LilyPond's syntax in general. It's "surface" syntax resembles that of TeX or LaTeX, with commands beginning with backslashes and curly braces used as delimiters. But its "beneath-the-surface" syntax uses the Scheme programming language and shows the music events that are taking place. However, this syntax can get pretty wordy and complex. I think it would be very interesting to try implementing a macro language for the underlying Scheme language using Scheme! After all, that is what Scheme is useful for: building an abstraction on top of another, and another, and another, etc. IMO, this would look very elegant. So instead of typing this: \version "2.11.65" I could type this instead: (version 2.11.65) And instead of this: \relative c' { c4 d e f g1 } I could type: (relative-to C4 'sequential (c-quarter d e f g-whole)) I don't know yet, but I think it would be kind of neat. :-)

Millions of Functions

LilyPond's documentation is quite extensive, and it's a great source of information if you're interested in learning how to use the software. Some of LilyPond's documentation is automatically generated straight from Scheme source code. This part of the documentation cover's much of LilyPond's "internals", including a complete list of music expressions, grobs, grob properties, etc. It also covers public functions that are exported to Scheme at runtime from C++ code. All of these functions begin with `ly:', so they are easy to recognize. However, there are *many* functions that are defined in the Scheme source that don't have autogenerated documentation. Some have docstrings, but many do not. Eventually I plan on getting all of these functions documented too, because some of them are incredibly useful. I didn't realize until today that some of these functions are generated *on-the-fly*, so it might be more tricky to document these particular functions. Some examples are `make-simple-markup', `make-bold-markup', etc. In fact, a `make-BLAH-markup' function is created for *every* markup command. So Lily's markup command \simple performs the same operation as `make-simple-markup' would in Scheme. Interesting stuff. I'm slowly becoming more familiar with how LilyPond operates, so the huge number of (unfortunately) undocumented Scheme functions is definitely helping me understand things better.