Node: Music representation, Next: Example applications, Previous: Typography and program architecture, Up: Introduction
Our premise is that LilyPond is a system that does music formatting completely automatically. Under this assumption, the output does not have to be touched up. Consequently, an interactive display of the output, where it is possible to reposition notation elements, is superfluous. This implies that the program should be a batch program: the input is entered in a file, which then is compiled, i.e. put through the program. The final output is produced as a file ready to view or print. The compiler fills in all the details of the notation, those details should be left out of the input file. In other words, the input should mirror the content as closely as possible. In the case of music notation the content is the music itself, so that is what the input should consist of.
On paper this theory sounds very good. In practice, it opens a can of worms. What really is music? Many philosophical treatises must have been written on the subject. Instead of losing ourselves in philosophical arguments over the essence of music, we have reversed the question to yield a more practical approach. Our assumption is that the printed score contains all of the music of piece. We build a program that uses some input format to produce such a score. Over the course of time, the program evolves. While this happens, we can remove more and more elements of the input format: as the program improves, it can fill in irrelevant details of the input by itself. At some (hypothetical) point, the program is finished: there is no possibility to remove any more elements from the syntax. What we have left is by definition exactly the musical meaning of the score.
There are also more practical concerns. Our users have to key in the
music into the file directly, so the input format should have a
friendly syntax: a quarter note C is entered as c4
, the code
r8.
signifies a dotted eighth rest.
Notes and rests form the simplest musical expressions in the input syntax. More complex constructs are produced by combining them into compound structures. This is done in much the same way that complex mathematical formulas are built from simple expressions such as numbers and operators.
In effect, the input format is a language, and the rules of that language can be specified succinctly with a so-called context-free grammar. The grammar formally specificies what types of input form valid `sentences'. Reading such languages, and splitting them into grammatical structures is a problem with standard solutions. Moreover, rigid definitions make the format easier to understand: a concise formal definition permits a simple informal description.
The user-interface of LilyPond is its syntax. That part is what users see most. As a results, some users think that music representation is a very important or interesting problem. In reality, less than 10% of the source code of the program handles reading and representing the input, and they form the easy bits of the program. In our opinion, producing music notation, and formatting it prettily are much more interesting and important than music representation: solving these problems takes up most of the bulk of the code, and they are the most difficult things to get right.
This page is for LilyPond-2.0.1 (stable-branch).