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
10 @node Technical manual
11 @chapter Technical manual
14 When LilyPond is run, it reads an input file which is parsed. During
15 parsing, Music objects are created. This music is interpreted, which
16 is done by contexts, that produce graphical objects. This section
17 discusses details of these three concepts, and how they are glued
18 together with the embedded Scheme interpreter.
21 * Interpretation context::
22 * Scheme integration::
23 * Music storage format::
29 @node Interpretation context
30 @section Interpretation context
35 * Context properties::
36 * Context evaluation::
38 * Engravers and performers::
39 * Defining new contexts::
43 Interpretation contexts are objects that only exist during program
44 run. During the interpretation phase (when @code{interpreting music}
45 is printed on the standard output), the music expression in a
46 @code{\score} block is interpreted in time order, the same order in
47 which we hear and play the music. During this phase, the interpretation
48 context holds the state for the current point within the music, for
51 @item What notes are playing at this point?
53 @item What symbols will be printed at this point?
55 @item What is the current key signature, time signature, point within
59 Contexts are grouped hierarchically: A @internalsref{Voice} context is
60 contained in a @internalsref{Staff} context (because a staff can contain
61 multiple voices at any point), a @internalsref{Staff} context is contained in
62 @internalsref{Score}, @internalsref{StaffGroup}, or
63 @internalsref{ChoirStaff} context.
65 Contexts associated with sheet music output are called @emph{notation
66 contexts}, those for sound output are called @emph{performance
67 contexts}. The default definitions of the standard notation and
68 performance contexts can be found in @file{ly/engraver-init.ly} and
69 @file{ly/performer-init.ly}, respectively.
72 @node Creating contexts
73 @subsection Creating contexts
74 @cindex @code{\context}
75 @cindex context selection
77 Contexts for a music expression can be selected manually, using the
78 following music expression.
81 \context @var{contexttype} [= @var{contextname}] @var{musicexpr}
85 This means that @var{musicexpr} should be interpreted within a context
86 of type @var{contexttype} (with name @var{contextname} if specified).
87 If no such context exists, it will be created.
89 @lilypond[verbatim,singleline]
91 \notes \relative c'' {
92 c4 <d4 \context Staff = "another" e4> f
98 In this example, the @code{c} and @code{d} are printed on the default
99 staff. For the @code{e}, a context @code{Staff} called @code{another}
100 is specified; since that does not exist, a new context is created.
101 Within @code{another}, a (default) Voice context is created for the
102 @code{e4}. A context is ended when when all music referring it has
103 finished, so after the third quarter, @code{another} is removed.
106 @node Default contexts
107 @subsection Default contexts
109 Every top level music is interpreted by the @code{Score} context; in
110 other words, you may think of @code{\score} working like
114 \context Score @var{music}
118 Music expressions inherit their context from the enclosing music
119 expression. Hence, it is not necessary to explicitly specify
120 @code{\context} for most expressions. In
121 the following example, only the sequential expression has an explicit
122 context. The notes contained therein inherit the @code{goUp} context
123 from the enclosing music expression.
125 @lilypond[verbatim,singleline]
126 \notes \context Voice = goUp { c'4 d' e' }
130 Second, contexts are created automatically to be able to interpret the
131 music expressions. Consider the following example.
133 @lilypond[verbatim, singleline]
134 \score { \notes { c'4-( d' e'-) } }
138 The sequential music is interpreted by the Score context initially,
139 but when a note is encountered, contexts are setup to accept that
140 note. In this case, a @code{Thread},@code{Voice}, and @code{Staff}
141 context are created. The rest of the sequential music is also
142 interpreted with the same @code{Thread}, @code{Voice}, and
143 @code{Staff} context, putting the notes on the same staff, in the same
146 @node Context properties
147 @subsection Context properties
149 Contexts have properties. These properties are set from the @file{.ly}
150 file using the following expression:
151 @cindex @code{\property}
152 @cindex context properties
153 @cindex properties, context
156 \property @var{contextname}.@var{propname} = @var{value}
160 Sets the @var{propname} property of the context @var{contextname} to
161 the specified Scheme expression @var{value}. Both @var{propname} and
162 @var{contextname} are strings, which can often be written unquoted.
165 Properties that are set in one context are inherited by all of the
166 contained contexts. This means that a property valid for the
167 @internalsref{Voice} context can be set in the @internalsref{Score} context
168 (for example) and thus take effect in all @internalsref{Voice} contexts.
170 @cindex @code{Current}
171 If you do not wish to specify the name of the context in the
172 @code{\property}-expression itself, you can refer to the abstract context
173 name, @code{Current}. The @code{Current} context is the latest
174 used context. This will typically mean the @internalsref{Thread}
175 context, but you can force another context with the
176 @code{\property}-command. Hence the expressions
179 \property @var{contextname}.@var{propname} = @var{value}
186 \context @var{contextname}
187 \property Current.@var{propname} = @var{value}
191 do the same thing. The main use for this is in predefined variables.
192 This construction allows the specification of a property-setting
193 without restriction to a specific context.
195 Properties can be unset using the following statement.
197 \property @var{contextname}.@var{propname} \unset
200 @cindex properties, unsetting
201 @cindex @code{\unset}
204 This removes the definition of @var{propname} in @var{contextname}. If
205 @var{propname} was not defined in @var{contextname} (but was inherited
206 from a higher context), then this has no effect.
210 The syntax of @code{\unset} is asymmetric: @code{\property \unset} is not
211 the inverse of @code{\property \set}.
214 @node Context evaluation
215 @subsection Context evaluation
217 Contexts can be modified during interpretation with Scheme code. The
220 \applycontext @var{function}
223 @var{function} should be a Scheme function taking a single argument,
224 being the context to apply it to. The following code will print the
225 current bar number on the standard output during the compile.
230 (format #t "\nWe were called in barnumber ~a.\n"
231 (ly:get-context-property x 'currentBarNumber)))
236 @node Defining contexts
237 @subsection Defining contexts
239 @cindex context definition
240 @cindex translator definition
242 The most common way to create a new context definition is by extending
243 an existing one. An existing context from the paper block is copied
244 by referencing a context identifier:
249 @var{context-identifier}
255 Every predefined context has a standard identifier. For example, the
256 @code{Staff} context can be referred to as @code{\StaffContext}.
258 The context can then be modified by setting or changing properties,
263 Stem \set #'thickness = #2.0
264 defaultBarType = #"||"
267 These assignments happen before interpretation starts, so a @code{\property}
268 command will override any predefined settings.
274 It is not possible to collect multiple property assignments in a
275 variable, and apply to one @code{\translator} definition by
276 referencing that variable.
278 @node Engravers and performers
279 @subsection Engravers and performers
282 Each context is composed of a number of building blocks, or plug-ins
283 called engravers. An engraver is a specialized C++ class that is
284 compiled into the executable. Typically, an engraver is responsible
285 for one function: the @code{Slur_engraver} creates only @code{Slur}
286 objects, and the @code{Skip_event_swallow_translator} only swallows
287 (silently gobbles) @code{SkipEvent}s.
294 An existing context definition can be changed by adding or removing an
295 engraver. The syntax for these operations is
297 \consists @var{engravername}
298 \remove @var{engravername}
305 Here @var{engravername} is a string, the name of an engraver in the
306 system. In the following example, the @code{Clef_engraver} is removed
307 from the Staff context. The result is a staff without a clef, where
308 the central C is at its default position, the center line.
310 @lilypond[verbatim,singleline]
318 \remove Clef_engraver
324 A list of all engravers is in the internal documentation,
325 see @internalsref{All engravers}.
327 @node Defining new contexts
328 @subsection Defining new contexts
331 It is also possible to define new contexts from scratch. To do this,
332 you must define give the new context a name. In the following
333 example, a very simple Staff context is created: one that will put
334 note heads on a staff symbol.
338 \type "Engraver_group_engraver"
341 \consists "Staff_symbol_engraver"
342 \consists "Note_head_engraver"
343 \consistsend "Axis_group_engraver"
348 The argument of @code{\type} is the name for a special engraver that
349 handles cooperation between simple engravers such as
350 @code{Note_head_engraver} and @code{Staff_symbol_engraver}. This
351 should always be @code{Engraver_group_engraver} (unless you are
352 defining a Score context from scratch, in which case
353 @code{Score_engraver} must be used).
355 The complete list of context modifiers is as follows:
357 @item @code{\alias} @var{alternate-name}:
358 This specifies a different name. In the above example,
359 @code{\property Staff.X = Y} will also work on @code{SimpleStaff}s
361 @item @code{\consistsend} @var{engravername}:
362 Analogous to @code{\consists}, but makes sure that
363 @var{engravername} is always added to the end of the list of
366 Engravers that group context objects into axis groups or alignments
367 need to be at the end of the list. @code{\consistsend} insures that
368 engravers stay at the end even if a user adds or removes engravers.
370 @item @code{\accepts} @var{contextname}:
371 This context can contains @var{contextname} contexts. The first
372 @code{\accepts} is created as a default context when events (eg. notes
373 or rests) are encountered.
375 @item @code{\denies}:
376 The opposite of @code{\accepts}.
378 @item @code{\name} @var{contextname}:
379 This sets the type name of the context, e.g. @code{Staff},
380 @code{Voice}. If the name is not specified, the translator will not
385 @node Scheme integration
386 @section Scheme integration
390 @cindex Scheme, in-line code
391 @cindex accessing Scheme
392 @cindex evaluating Scheme
395 LilyPond internally uses GUILE, a Scheme-interpreter, to represent
396 data throughout the whole program, and glue together different program
397 modules. For advanced usage, it is sometimes necessary to access and
398 program the Scheme interpreter.
400 Scheme is a full-blown programming language, from the LISP
401 family. and a full discussion is outside the scope of this document.
402 Interested readers are referred to the website
403 @uref{http://www.schemers.org/} for more information on Scheme.
405 The GUILE library for extension is documented at
406 @uref{http://www.gnu.org/software/guile}.
408 When it is installed, the following link should take you to its manual
409 @ref{(guile.info)guile}
414 * Input variables and Scheme::
420 @subsection Inline Scheme
422 Scheme expressions can be entered in the input file by entering a
423 hash-sign (@code{#}). The expression following the hash-sign is
424 evaluated as Scheme. For example, the boolean value @var{true} is
425 @code{#t} in Scheme, so for LilyPond @var{true} looks like @code{##t},
426 and can be used in property assignments:
428 \property Staff.autoBeaming = ##f
432 @node Input variables and Scheme
433 @subsection Input variables and Scheme
436 The input format supports the notion of variable: in the following
437 example, a music expression is assigned to a variable with the name
440 traLaLa = \notes @{ c'4 d'4 @}
445 There is also a form of scoping: in the following example, the
446 @code{\paper} block also contains a @code{traLaLa} variable, which is
447 independent of the outer @code{\traLaLa}.
449 traLaLa = \notes @{ c'4 d'4 @}
450 \paper @{ traLaLa = 1.0 @}
453 In effect, each input file is a scope, and all @code{\header},
454 @code{\midi} and @code{\paper} blocks are scopes nested inside that
457 Both variables and scoping are implemented in the GUILE module system.
458 An anonymous Scheme module is attached to each scope. An assignment of
461 traLaLa = \notes @{ c'4 d'4 @}
465 is internally converted to a Scheme definition
467 (define traLaLa @var{Scheme value of ``@code{\notes ... }''})
470 This means that input variables and Scheme variables may be freely
471 mixed. In the following example, a music fragment is stored in the
472 variable @code{traLaLa}, and duplicated using Scheme. The result is
473 imported in a @code{\score} by means of a second variable
476 traLaLa = \notes @{ c'4 d'4 @}
478 #(define newLa (map ly:music-deep-copy
479 (list traLaLa traLaLa)))
481 (make-sequential-music newLa))
486 In the above example, music expressions can be `exported' from the
487 input to the Scheme interpreter. The opposite is also possible. By
488 wrapping a Scheme value in the function @code{ly:export}, a Scheme
489 value is interpreted as if it were entered in LilyPond syntax: instead
490 of defining @code{\twice}, the example above could also have been
494 \score @{ #(ly:export (make-sequential-music newLa)) @}
501 @node Scheme datatypes
502 @subsection Scheme datatypes
504 Scheme is used to glue together different program modules. To aid this
505 glue function, many lilypond specific object types can be passed as
508 The following list are all lilypond specific types, that
509 can exist during parsing:
516 In C++ terms, an @code{Event} is a subtype of @code{Music}. However,
517 both have different functions in the syntax.
518 @item Music_output_def
525 During a run, transient objects are also created and destroyed.
528 @item Grob: short for `Graphical object'.
529 @item Scheme_hash_table
532 @item Molecule: Device-independent page output object,
533 including dimensions.
539 @item Translator: An object that produces audio objects or Grobs.
540 It may be accessed with @code{\applyoutput}.
542 @item Font_metric: An object representing a font.
545 Many functions are defined to manipulate these data structures. They
546 are all listed and documented in the internals manual, see
547 @internalsref{All scheme functions}.
551 @subsection Assignments
554 Variables allow objects to be assigned to names during the parse
555 stage. To assign a variable, use
557 @var{name}@code{=}@var{value}
559 To refer to a variable, precede its name with a backslash:
560 `@code{\}@var{name}'. @var{value} is any valid Scheme value or any of
561 the input-types listed above. Variable assignments can appear at top
562 level in the LilyPond file, but also in @code{\paper} blocks.
564 A variable can be created with any string for its name, but for
565 accessing it in the LilyPond syntax, its name must consist of
566 alphabetic characters only, and may not be a keyword of the syntax.
567 There are no restrictions for naming and accessing variables in the
570 The right hand side of a variable assignment is parsed completely
571 before the assignment is done, so variables may be redefined in terms
572 of its old value, e.g.
578 When a variable is referenced in LilyPond syntax, the information it
579 points to is copied. For this reason, an variable reference must
580 always be the first item in a block.
585 \paperIdent % wrong and invalid
591 \paperIdent % correct
598 @node Music storage format
599 @section Music storage format
601 Music in LilyPond is entered as music expressions. This section
602 discusses different types of music expressions, and explains how
603 information is stored internally. This internal storage is accessible
604 through the Scheme interpreter, so music expressions may be
605 manipulated using Scheme functions.
608 * Music expressions::
609 * Internal music representation::
610 * Manipulating music expressions::
613 @node Music expressions
614 @subsection Music expressions
615 @cindex music expressions
617 Notes, rests, lyric syllables are music expressions. Small music
618 expressions may be combined to form larger ones, for example by
619 enclosing a list of expressions in @code{\sequential @{ @}} or @code{<
620 >}. In the following example, a compound expression is formed out of
621 the quarter note @code{c} and a quarter note @code{d}:
624 \sequential @{ c4 d4 @}
627 @cindex Sequential music
628 @cindex @code{\sequential}
629 @cindex sequential music
632 @cindex Simultaneous music
633 @cindex @code{\simultaneous}
635 The two basic compound music expressions are simultaneous and
639 \sequential @code{@{} @var{musicexprlist} @code{@}}
640 \simultaneous @code{@{} @var{musicexprlist} @code{@}}
643 For both, there is a shorthand:
646 @code{@{} @var{musicexprlist} @code{@}}
653 @code{<} @var{musicexprlist} @code{>}
657 for simultaneous music.
658 In principle, the way in which you nest sequential and simultaneous to
659 produce music is not relevant. In the following example, three chords
660 are expressed in two different ways:
662 @lilypond[fragment,verbatim,center,quote]
663 \notes \context Voice {
664 <a c'> <b d'> <c' e'>
665 < { a b c' } { c' d' e' } >
668 However, using @code{<} and @code{>} for entering chords leads to
669 various peculiarities. For this reason, a special syntax
670 for chords was introduced in version 1.7: @code{<< >>}.
676 Other compound music expressions include
679 \transpose @var{from} @var{to} @var{expr}
680 \apply @var{func} @var{expr}
681 \context @var{type} = @var{id} @var{expr}
682 \times @var{fraction} @var{expr}
685 @node Internal music representation
686 @subsection Internal music representation
693 When a music expression is parsed, it is converted into a set of
694 Scheme music objects. The defining property of a music object is that
695 it takes up time. Time is a rational number that measures the length
696 of a piece of music, in whole notes.
698 A music object has three kinds of types
701 Music name: each music expression has a name, for example, a note
702 leads to a @internalsref{NoteEvent}, and @code{\simultaneous} leads to
703 a @internalsref{SimultaneousMusic}. A list of all expressions
704 available is in the internals manual, under @internalsref{Music
708 Each music name has several `types' or interface. For example, a
709 note is an @code{event}, but it is also a @code{note-event}, a
710 @code{rhythmic-event} and a @code{melodic-event}.
712 All classes of music are listed in the internals manual, under
713 @internalsref{Music classes}.
715 Each music object is represented by a C++ object. For technical
716 reasons, different music objects may be represented by different C++
717 object types. For example, a note is @code{Event} object, while
718 @code{\grace} creates a @code{Grace_music} object.
720 We expect that distinctions between different C++ types will disappear
724 The actual information of a music expression is stored in properties.
725 For example, a @internalsref{NoteEvent} has @code{pitch} and
726 @code{duration} properties that store the pitch and duration of that
727 note. A list of all properties available is in the internals manual,
728 under @internalsref{Music properties}.
730 A compound music expresssion is a music object that contains other
731 music objects in its properties. A list of objects can be stored in
732 the @code{elements} property of a music object, or a single `child'
733 music object is stored in the @code{element} object. For example,
734 @internalsref{SequentialMusic} has its children in @code{elements},
735 and @internalsref{GraceMusic} has its single argument in
736 @code{element}. The body of a repeat is in @code{element} property of
737 @internalsref{RepeatedMusic}, and the alternatives in @code{elements}.
739 @node Manipulating music expressions
740 @subsection Manipulating music expressions
742 Music objects and their properties can be accessed and manipulated
743 directly, through the @code{\apply} mechanism.
744 The syntax for @code{\apply}
746 \apply #@var{func} @var{music}
750 This means that the scheme function @var{func} is called with
751 @var{music} as its argument. The return value of @var{func} is the
752 result of the entire expresssion. @var{func} may read and write music
753 properties using the functions @code{ly:get-mus-property} and
754 @code{ly:set-mus-property!}.
756 An example is a function that reverses the order of elements in
758 @lilypond[verbatim,singleline]
759 #(define (rev-music-1 m)
760 (ly:set-mus-property! 'elements (reverse
761 (ly:get-mus-property mus 'elements)))
763 \apply #rev-music-1 { c4 d4 }
766 The use of such a function is very limited. The effect of this
767 function is void when applied to an argument which is does not have
768 multiple children. The following function application has no effect:
771 \apply #rev-music-1 \grace @{ c4 d4 @}
775 In this case, @code{\grace} is stored as @internalsref{GraceMusic}, which has no
776 @code{elements}, only a single @code{element}. Every generally
777 applicable function for @code{\apply} must --like music expressions
778 themselves-- be recursive.
780 The following example is such a recursive function: it first extracts
781 the @code{elements} of an expression, reverses them and puts them
782 back. Then it recurses, both on @code{elements} and @code{element}
785 #(define (reverse-music music)
786 (let* ((elements (ly:get-mus-property music 'elements))
787 (child (ly:get-mus-property music 'element))
788 (reversed (reverse elements)))
791 (ly:set-mus-property! music 'elements reversed)
794 (if (ly:music? child) (reverse-music child))
795 (map reverse-music reversed)
800 A slightly more elaborate example is in
801 @inputfileref{input/test,reverse-music.ly}.
803 Some of the input syntax is also implemented as recursive music
804 functions. For example, the syntax for polyphony
810 is actually implemented as a recursive function that replaces the
811 above by the internal equivalent of
813 < \context Voice = "1" @{ \voiceOne a @}
814 \context Voice = "2" @{ \voiceTwo b @} >
817 Other applications of @code{\apply} are writing out repeats
818 automatically (@inputfileref{input/test,unfold-all-repeats.ly}),
819 saving keystrokes (@inputfileref{input/test,music-box.ly}) and
821 LilyPond input to other formats (@inputfileref{input/test,to-xml.ly})
825 @file{scm/music-functions.scm}, @file{scm/music-types.scm},
826 @inputfileref{input/test,add-staccato.ly},
827 @inputfileref{input/test,duration-check.ly}.
828 @inputfileref{input/test,unfold-all-repeats.ly},
829 @inputfileref{input/test,music-box.ly}.
831 @node Lexical details
832 @section Lexical details
838 Begins and ends with the @code{"} character. To include a @code{"}
839 character in a string write @code{\"}. Various other backslash
840 sequences have special interpretations as in the C language. A string
841 that contains no spaces can be written without the quotes. Strings can
842 be concatenated with the @code{+} operator.
847 @section Output details
849 LilyPond's default output format is @TeX{}. Using the option @option{-f}
850 (or @option{--format}) other output formats can be selected also, but
851 currently none of them work reliably.
853 At the beginning of the output file, various global parameters are defined.
854 It also contains a large @code{\special} call to define PostScript routines
855 to draw items not representable with @TeX{}, mainly slurs and ties. A DVI
856 driver must be able to understand such embedded PostScript, or the output
857 will be rendered incompletely.
859 Then the file @file{lilyponddefs.tex} is loaded to define the macros used
860 in the code which follows. @file{lilyponddefs.tex} includes various other
861 files, partially depending on the global parameters.
863 Now the music is output system by system (a `system' consists of all
864 staves belonging together). From @TeX{}'s point of view, a system is an
865 @code{\hbox} which contains a lowered @code{\vbox} so that it is centered
866 vertically on the baseline of the text. Between systems,
867 @code{\interscoreline} is inserted vertically to have stretchable space.
868 The horizontal dimension of the @code{\hbox} is given by the
869 @code{linewidth} parameter from LilyPond's @code{\paper} block.
872 After the last system LilyPond emits a stronger variant of
873 @code{\interscoreline} only if the macro
874 @code{\lilypondpaperlastpagefill} is not defined (flushing the systems
875 to the top of the page). You can avoid that by setting the variable
876 @code{lastpagefill} in LilyPond's @code{\paper} block.
878 It is possible to fine-tune the vertical offset further by defining the
879 macro @code{\lilypondscoreshift}. Example:
882 \def\lilypondscoreshift@{0.25\baselineskip@}
886 @code{\baselineskip} is the distance from one text line to the next.
888 The code produced by LilyPond should be run through La@TeX{}, not
891 Here an example how to embed a small LilyPond file @code{foo.ly} into
892 running La@TeX{} text without using the @code{lilypond-book} script
893 (@pxref{lilypond-book manual}).
896 \documentclass@{article@}
898 \def\lilypondpaperlastpagefill@{@}
900 \def\lilypondscoreshift@{0.25\baselineskip@}
903 This is running text which includes an example music file
909 The file @file{foo.tex} has been simply produced with
915 It is important to set the @code{indent} parameter to zero in the
916 @code{\paper} block of @file{foo.ly}.
918 The call to @code{\lineskip} assures that there is enough vertical space
919 between the LilyPond box and the surrounding text lines.