1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
\input texinfo @c -*- coding: utf-8; mode: texinfo; -*-
@ignore
Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
When revising a translation, copy the HEAD committish of the
version that you are working on. See TRANSLATION for details.
@end ignore
@node input-format
@unnumberedsec Input format
As discussed earlier, the ideal input format for a music engraving
system is the content: the music itself. This poses a formidable
problem: how can we define what music really @emph{is}? Our way out
of this problem, is to reverse it. Instead of defining what music is,
our program serves as a definition: we write a program capable of
producing sheet music, and adjust the format to be as lean as
possible. When the format can no longer be trimmed down, by
definition we are left with content itself.
The syntax is also the user-interface for LilyPond, hence it is easily
typable, e.g.,
@verbatim
c'4 d'8
@end verbatim
Are a quarter note C1 and eighth note D1, as in this example:
@divClass{float-center}
@divEnd
@image{pictures/simple-notation,,,.png}
On a microscopic scale, such syntax is easy to use. On a larger scale,
syntax also needs structure. How else can you enter complex pieces
like symphonies and operas? The structure is formed by the concept of
music expressions: by combining small fragments of music into larger
ones, more complex music can be expressed. For example,
@table asis
@item
@tab
c4
@tab
@image{pictures/simultaneous-0,,,.png}
@end table
Combine this simultaneously with two other notes by enclosing in <<
and >>.
@table asis
@item
@tab
@verbatim
<<c4 d4 e4>>
@end verbatim
@tab
@image{pictures/simultaneous-1,,,.png}
@end table
This expression is put in sequence by enclosing it in braces, i.e.,
@table asis
@item
@tab
@verbatim
{ <<c4 d4 e4>> f4 }
@end verbatim
@tab
@image{pictures/simultaneous-2,,,.png}
@end table
The above is another expression, and therefore, it may be combined
again with a simultaneous expression (in this case, a half note).
@table asis
@item
@tab
@verbatim
<< { <<c4 d4 e4>> f4 } g2 >>
@end verbatim
@tab
@image{pictures/simultaneous-3,,,.png}
@end table
Such recursive structures can be specified neatly and formally in a
@emph{context-free grammar}. The parsing code is also generated
from this grammar. In other words, the syntax of LilyPond is clearly
and unambiguously defined.
User-interfaces and syntax are what people see and deal with
most. They are partly a matter of taste, and also subject of much
discussion. Although discussions on taste do have their merit, they
are not very productive. In the larger picture of LilyPond, the
importance of input syntax is small: inventing neat syntax is easy,
writing decent formatting code is much harder. This is also
illustrated by the line-counts for the respective components: parsing
and representation take up less than 10% of the code.
@table asis
@item
@item
Parsing + representation
@item
total
@item
@tab
6000 lines C++
@tab
61500 lines C++
@end table
<! todo :
blurbs about lilypond today
future?
>
@divClass{float-right}
@divEnd
Next: @ref{conclusion.html,wrapping it up}, the conclusion.
@bye
|
