4 @c A menu is needed before every deeper *section nesting of @nodes
5 @c Run M-x texinfo-all-menus-update
6 @c to automagically fill in these menus
7 @c before saving changes
14 When translating the input to notation, there are number of distinct
15 phases. We list them here:
18 @c todo: moved from refman.
20 The purpose of LilyPond is explained informally by the term `music
21 typesetter'. This is not a fully correct name: not only does the
22 program print musical symbols, it also makes aesthetic decisions.
23 Symbols and their placements are @emph{generated} from a high-level
24 musical description. In other words, LilyPond would be best described
25 by `music compiler' or `music to notation compiler'.
27 LilyPond is linked to GUILE, GNU's Scheme library for extension
28 programming. The Scheme library provides the glue that holds together
29 the low-level routines and separate modules which are written in C++.
31 When lilypond is run to typeset sheet music, the following happens:
33 @item GUILE Initialization: various scheme files are read
34 @item parsing: first standard @code{ly} initialization files are read, and
35 then the user @file{ly} file is read.
36 @item interpretation: the music in the file is processed ``in playing
37 order'', i.e. the order that you use to read sheet music, or the
38 order in which notes are played. The result of this step is a typesetting
42 The typesetting specification is solved: positions and formatting is
45 @item the visible results ("virtual ink") are written to the output file.
48 During these stages different types of data play the the main role:
49 during parsing, @strong{Music} objects are created. During the
50 interpretation, @strong{contexts} are constructed, and with these contexts
51 a network of @strong{graphical objects} (``grobs'') is created. These
52 grobs contain unknown variables, and the network forms a set of
53 equations. After solving the equations and filling in these variables,
54 the printed output (in the form of @strong{molecules}) is written to an
57 These threemanship of tasks (parsing, translating, typesetting) and
58 data-structures (music, context, graphical objects) permeates the entire
59 design of the program.
67 The LY file is read, and converted to a list of @code{Scores}, which
68 each contain @code{Music} and paper/midi-definitions. Here @code{Music},
69 @code{Pitch} and @code{Duration} objects are created.
71 @item Interpreting music
72 @cindex interpreting music
74 All music events are "read" in the same order as they would be played
75 (or read from paper). At every step of the interpretation, musical
76 events are delivered to
77 interpretation contexts,
79 which use them to build @code{Grob}s (or MIDI objects, for MIDI output).
81 In this stage @code{Music_iterators} do a traversal of the @code{Music}
82 structure. The music events thus encountered are reported to
83 @code{Translator}s, a set of objects that collectively form interpretation
91 At places where line breaks may occur, clefs and bars are prepared for
92 a possible line break.
98 In this stage, all information that is needed to determine line breaking
101 @item Break calculation:
103 The lines and horizontal positions of the columns are determined.
107 Relations between all grobs are modified to reflect line breaks: When a
108 spanner, e.g. a slur, crosses a line-break, then the spanner is "broken
109 into pieces", for every line that the spanner is in, a copy of the grob
110 is made. A substitution process redirects all grob-reference so that
111 each spanner grob will only reference other grobs in the same line.
115 All vertical dimensions and spanning objects are computed, and all grobs
116 are output, line by line. The output is encoded in the form of
121 The data types that are mentioned here are all discussed in this
125 * Grobs:: Graphical object
126 * Molecules:: Molecules are stand-alone descriptions of output
132 This section is about Grobs (short for Graphical Objects), which are
133 formatting objects used to create the final output. This material is
134 normally the domain of LilyPond gurus, but occasionally, a normal user
135 also has to deal with grobs.
137 The most simple interaction with Grobs are when you use
141 \property Voice.Stem \override #'direction = #1
144 This piece of lily input causes all stem objects to be stem-up
145 henceforth. In effect, you are telling lilypond to extend the definition
146 of the `Stem' grob with the setting @code{direction := 1}.
151 * Setting grob properties::
153 * Items and Spanners::
154 * Grob Scheme functions::
159 @node What is a grob?
160 @subsection What is a grob?
162 In music notation, lots of symbols are related in some way. You can
163 think of music notation as a graph where nodes are formed by the
164 symbols, and the arcs by their relations. A grob is a node in that graph.
165 The directed edges in the graph are formed by references to other grobs
167 This big graph of grobs specifies the notation problem. The solution of
168 this problem is a description of the printout in closed form, i.e. a
169 list of values. These values are Molecules. (see @ref{Molecules})
171 All grobs have an X and Y-position on the page. These X and Y positions
172 are stored in a relative format, so they can easily be combined by
173 stacking them, hanging one grob to the side of another, and coupling
174 them into a grouping-grob.
176 Each grob has a reference point (a.k.a. parent): the position of a grob
177 is stored relative to that reference point. For example the X-reference
178 point of a staccato dot usually is the note head that it applies
179 to. When the note head is moved, the staccato dot moves along
182 If you keep following offset reference points, you will always end up at
183 the root object. This root object is called @code{Line_of_score}, and it
184 represents a system (i.e. a line of music).
186 All grobs carry a set of grob-properties. In the Stem example above,
187 the property @code{direction} is set to value @code{1}. The function
188 that draws the symbol (@code{Stem::brew_molecule}) uses the value of
189 @code{direction} to determine how to print the stem and the flag. The
190 appearance of a grob is determined solely by the values of its
193 A grob is often associated with a symbol, but some grobs do not print
194 any symbols. They take care of grouping objects. For example, there is a
195 separate grob that stacks staves vertically. The @code{NoteCollision}
196 is also an abstract grob: it only moves around chords, but doesn't print
199 A complete list of grob types is found in the generated documentation.
203 @subsection Callbacks
205 Offsets of grobs are relative to a parent reference point. Most
206 positions are not known when an object is created, so these are
207 calculated as needed. This is done by adding a callback for a specific
210 Suppose you have the following code in a .ly file.
212 #(define (my-callback gr axis)
213 (* 2.0 (get-grob-property gr 'direction))
218 \property Voice.Stem \override #'Y-offset-callbacks = #(list
222 When the Y-offset of a Stem object is needed, LilyPond will
223 automatically execute all callbacks for that object. In this case, it
224 will find @code{my-callback}, and execute that. The result is that the
225 stem is translated by two staff spaces in its direction.
227 (note: @code{Y-offset-callbacks} is also a property)
231 Offset callbacks can be stacked, i.e.
234 \property .... \override #'Y-offset-callbacks = #(list
235 callback1 callback2 callback3)
239 The callbacks will be executed in the order @code{callback3 callback2
240 callback1}. This is used for quantized positioning: the staccato dot is
241 above or below a note head, and it must not be on a staff-line. To
242 achieve this, the staccato dot has two callbacks: one that positions the
243 grob above or below the note head, and one that rounds the Y-position of
244 the grob to the nearest open space.
246 Similarly, the size of a grob are determined through callbacks, settable
247 with grob properties @code{X-extent-callback} and
248 @code{Y-extent-callback}. There can be only one extent-callback for
249 each axis. No callback (Scheme value @code{#f}) means: "empty in this
250 direction". If you fill in a pair of numbers, that pair hard-codes the
251 extent in that coordinate.
254 @node Setting grob properties
255 @subsection Setting grob properties
257 Grob properties are stored as GUILE association lists, with symbols as
258 keys. In GUILE you can access these using functions described in
259 Section @ref{Grob Scheme functions}. From C++, grob properties can be
260 accessed using these functions:
263 SCM get_grob_property (SCM) const;
264 void set_grob_property (const char * , SCM val);
265 void set_immutable_grob_property (const char * , SCM val);
266 void set_immutable_grob_property (SCM key, SCM val);
267 void set_grob_property (SCM , SCM val);
268 void set_grob_pointer (const char*, SCM val);
269 SCM remove_grob_property (const char* nm);
272 All lookup functions identify undefined properties with end-of-list
273 (i.e. @code{'()} in Scheme or @code{SCM_EOL} in C)
275 Properties are stored in two ways:
277 @item mutable properties.
278 Grob properties that change from object to object. The storage of
279 these are private to a grob. For example pointers to other grobs are
280 always stored in the mutable properties.
282 @item immutable properties.
283 Grob properties that are shared across different grobs of the same
284 type. The storage is shared, and hence it is read-only. Typically, this
285 is used to store function callbacks, and default settings. They are
286 initially read from @file{scm/grob-description.scm}.
289 You can change immutable grob properties with the \override syntax:
292 \property Voice.Stem \override #'direction = #1
295 This will push the entry @code{'(direction . 1)} on the immutable
296 property list for stems, in effect overriding the setting from
297 @file{scm/grob-description.scm}. This can be undone by
300 \property Voice.stem \revert #'direction
303 There is also a shorthand,
306 \property Context.GrobType \set #'prop = #VAL
309 this does a @code{\revert} followed by a @code{\override}
311 You can change mutable properties with \outputproperty. This construct
315 \context ContextName \outputproperty @var{pred} #@var{sym} = #@var{val}
318 In this case, in every grob that satisfies @var{pred}, the grob property
319 @var{sym} is set to @var{val}. For example
323 #(lambda (gr) (string? (ly-get-grob-property gr
325 #'extra-offset = #'(-1.0 . 0.0)
328 This shifts all grobs that have a @code{text} property one staff
329 space to the left. This mechanism is rather clumsy to use, but it allows
330 you tweak any setting of any grob.
333 @node Grob interfaces
334 @unnumberedsubsec Grob interfaces
336 Grob properties form a name space where you can set variables per
337 object. Each object however, may have multiple functions. For example,
338 consider a dynamic symbol, such @code{\ff} (fortissimo). It is printed
339 above or below the staff, it is a dynamic sign, and it is a kind of
342 To reflect this different functions of a grob, procedures and variables
343 are grouped into so-called interfaces. The dynamic text for example
344 supports the following interfaces:
347 The glyph is built from characters from a font, hence the
348 @code{font-interface}. For objects supporting @code{font-interface}, you
349 can select alternate fonts by setting @code{font-style},
350 @code{font-point-size}, etc.
352 @item dynamic-interface
353 Dynamic interface is not associated with any variable or function in
354 particular, but this makes it possible to distinguish this grob from
355 other similar grobs (like @code{TextScript}), that have no meaning of
359 This interface is for texts that are to be set using special routines
360 to stack text into lines, using kerning, etc.
362 @item general-grob-interface
363 This interface is supported by all grob types.
368 @node Items and Spanners
369 @unnumberedsubsec Items and Spanners
371 Grobs can also be distinguished in their role in the horizontal spacing.
372 Many grobs define constraints on the spacing by their sizes. For
373 example, note heads, clefs, stems, and all other symbols with a fixed
374 shape. These grobs form a subtype called @code{Item}.
376 Other grobs have a shape that depends on the horizontal spacing. For
377 example, slur, beam, tie, etc. These grobs form a subtype called
378 @code{Spanner}. All spanners have two span-points (these must be
379 @code{Item}s), one on the left and one on the right. The left bound is
380 also the X-reference point of the spanner.
382 Some items need special treatment for line breaking. For example, a
383 clef is normally only printed at the start of a line (i.e. after a line
384 break). To model this, `breakable' items (clef, key signature, bar lines,
385 etc.) are copied twice. Then we have three versions of each breakable
386 item: one version if there is no line break, one version that is printed
387 before the line break (at the end of a system), one version that is
388 printed after the line break.
390 Whether these versions are visible and take up space, is determined by
391 the outcome of the @code{visibility-lambda}. This grob property is a
392 function taking a direction (-1, 0 or 1) as argument. It returns a cons
393 of booleans, signifying whether this grob should be transparent and have
396 @node Grob Scheme functions
397 @unnumberedsubsec Grob Scheme functions
399 Grob properties can be manipulated from Scheme. In practice, most
400 manipulations are coded in C++ because of tradition.
409 @cindex Output description
411 The objective of any typesetting system is to put ink on paper in the
412 right places. For LilyPond, this final stage is left to the @TeX{} and
413 the printer subsystem. For lily, the last stage in processing a score is
414 outputting a description of what to put where. This description roughly
423 you merely have to look at the tex output of lily to see this.
424 Internally these instructions are encoded in Molecules.@footnote{At some
425 point LilyPond also contained Atom-objects, but they have been replaced
426 by Scheme expressions, making the name outdated.} A molecule is
427 what-to-print-where information that also contains dimension information
428 (how large is this glyph?).
430 Conceptually, Molecules can be constructed from Scheme code, by
431 translating a Molecule and by combining two molecules. In BNF
435 Molecule :: COMBINE Molecule Molecule
436 | TRANSLATE Offset Molecule
441 If you are interested in seeing how this information is stored, you
442 can run with the @code{-f scm} option. The scheme expressions are then
443 dumped in the output file.
445 All visible, i.e. non-transparent, grobs have a callback to create a
446 Molecule. The name of the property is @code{molecule-callback}, and its
447 value should be a Scheme function taking one argument (the grob) and
448 returning a Molecule. Most molecule callbacks are written in C++, but
449 you can also write them in Scheme. An example is provided in
450 @code{input/regression/molecule-hacking.ly}.