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 music from a file, translates that into
15 notation, and outputs the result to a file. The most important steps
16 are the first three. Consequently, there are three important basic
17 concepts within LilyPond: music, translation and layout. The
18 following diagram illustrates the concepts, and list the terminology
19 associated with each step.
24 +-------------+ Translation +----------+
26 | Music | ------------------> | Layout |
28 +-------------+ +----------+
31 Syntax: c4 \context \set #'padding =
34 Objects: Music expressions Contexts Layout object
37 Example objects: NoteEvent Voice NoteHead
40 Example properties: #'pitch keySignature #'line-count
42 User applications: none various tuning layout
46 The objects passed around in LilyPond have @emph{properties},
47 variables that can contain many different types of information. Users
48 can set these variables, to modify the default behavior. Since there
49 are three different main concepts, there are also three types of
53 @cindex concepts, main
55 @cindex music expressions
61 @item Music properties
62 These are used internally, and most users will not see or use them.
64 They use Scheme-style naming, i.e. lowercase words separated with
65 dashes: @code{pitch}, @code{tremolo-type}.
67 @item Translation properties
68 These influence the translation process, and most users will encounter them
69 regularly. For example, beaming behavior is tuned with
70 @code{autoBeamSettings}.
72 These use mixed-caps naming: @code{autoBeamSettings},
73 @code{ignoreMelismata}. They are assigned as follows:
75 \property Lyrics.ignoreMelismata = ...
78 @item Layout properties
79 These are internally used in the formatting process. Consequently, to
80 tune formatting details, it is necessary to adjust these
81 properties. For example, some objects may be moved around vertically
82 by setting their @code{padding} property.
84 These properties use Scheme-style naming: @code{c0-position},
85 @code{break-align-symbol}. They most often assigned as follows:
88 \property Score.RehearsalMark \set #'break-align-symbol = ...
92 Here, @code{RehearsalMark} is the type of the layout object.
96 This chapter discusses details of the three concepts in more detail,
97 and explains how they are glued together in LilyPond with the embedded
101 * Interpretation context::
102 * Scheme integration::
103 * Music storage format::
109 @node Interpretation context
110 @section Interpretation context
113 * Creating contexts::
115 * Context properties::
116 * Context evaluation::
117 * Defining contexts::
118 * Changing contexts locally::
119 * Engravers and performers::
120 * Defining new contexts::
124 Interpretation contexts are objects that only exist during program
125 run. During the interpretation phase (when @code{interpreting music}
126 is printed on the standard output), the music expression in a
127 @code{\score} block is interpreted in time order, the same order in
128 which we hear and play the music. During this phase, the interpretation
129 context holds the state for the current point within the music, for
132 @item What notes are playing at this point?
134 @item What symbols will be printed at this point?
136 @item What is the current key signature, time signature, point within
140 Contexts are grouped hierarchically: A @internalsref{Voice} context is
141 contained in a @internalsref{Staff} context (because a staff can contain
142 multiple voices at any point), a @internalsref{Staff} context is contained in
143 @internalsref{Score}, @internalsref{StaffGroup}, or
144 @internalsref{ChoirStaff} context.
146 Contexts associated with sheet music output are called @emph{notation
147 contexts}, those for sound output are called @emph{performance
148 contexts}. The default definitions of the standard notation and
149 performance contexts can be found in @file{ly/engraver-init.ly} and
150 @file{ly/performer-init.ly}, respectively.
153 @node Creating contexts
154 @subsection Creating contexts
155 @cindex @code{\context}
156 @cindex context selection
158 Contexts for a music expression can be selected manually, using one of
159 the following music expressions:
162 \new @var{contexttype} @var{musicexpr}
163 \context @var{contexttype} [= @var{contextname}] @var{musicexpr}
167 This means that @var{musicexpr} should be interpreted within a context
168 of type @var{contexttype} (with name @var{contextname} if specified).
169 If no such context exists, it will be created:
171 @lilypond[verbatim,raggedright]
173 \notes \relative c'' {
174 c4 <<d4 \context Staff = "another" e4>> f
180 In this example, the @code{c} and @code{d} are printed on the default
181 staff. For the @code{e}, a context @code{Staff} called @code{another}
182 is specified; since that does not exist, a new context is created.
183 Within @code{another}, a (default) Voice context is created for the
184 @code{e4}. A context is ended when when all music referring it has
185 finished, so after the third quarter, @code{another} is removed.
187 The @code{\new} construction creates a context with a
188 generated, unique @var{contextname}. An expression with
189 @code{\new} always leads to a new context. This is convenient
190 for creating multiple staffs, multiple lyric lines, etc.
192 When using automatic staff changes, automatic phrasing, etc., the
193 context names have special meanings, so @code{\new} cannot be
197 @node Default contexts
198 @subsection Default contexts
200 Every top level music is interpreted by the @code{Score} context; in
201 other words, you may think of @code{\score} working like
205 \context Score @var{music}
209 Music expressions inherit their context from the enclosing music
210 expression. Hence, it is not necessary to explicitly specify
211 @code{\context} for most expressions. In
212 the following example, only the sequential expression has an explicit
213 context. The notes contained therein inherit the @code{goUp} context
214 from the enclosing music expression.
216 @lilypond[verbatim,raggedright]
217 \notes \context Voice = goUp { c'4 d' e' }
221 Second, contexts are created automatically to be able to interpret the
222 music expressions. Consider the following example:
224 @lilypond[verbatim,raggedright]
225 \score { \notes { c'4-( d' e'-) } }
229 The sequential music is interpreted by the Score context initially,
230 but when a note is encountered, contexts are setup to accept that
231 note. In this case, a @code{Voice}, and @code{Staff}
232 context are created. The rest of the sequential music is also
233 interpreted with the same @code{Voice}, and
234 @code{Staff} context, putting the notes on the same staff, in the same
237 @node Context properties
238 @subsection Context properties
240 Contexts have properties. These properties are set from the @file{.ly}
241 file using the following expression:
242 @cindex @code{\property}
243 @cindex context properties
244 @cindex properties, context
247 \property @var{contextname}.@var{propname} = @var{value}
251 Sets the @var{propname} property of the context @var{contextname} to
252 the specified Scheme expression @var{value}. Both @var{propname} and
253 @var{contextname} are strings, which can often be written unquoted.
256 Properties that are set in one context are inherited by all of the
257 contained contexts. This means that a property valid for the
258 @internalsref{Voice} context can be set in the @internalsref{Score} context
259 (for example) and thus take effect in all @internalsref{Voice} contexts.
261 @cindex @code{Current}
262 If you do not wish to specify the name of the context in the
263 @code{\property}-expression itself, you can refer to the abstract context
264 name, @code{Current}. The @code{Current} context is the latest
265 used context. This will typically mean the @internalsref{Voice} context,
266 but you can force another context with the
267 @code{\property}-command. Hence the expressions
270 \property @var{contextname}.@var{propname} = @var{value}
277 \context @var{contextname}
278 \property Current.@var{propname} = @var{value}
282 do the same thing. The main use for this is in predefined variables.
283 This construction allows the specification of a property-setting
284 without restriction to a specific context.
286 Properties can be unset using the following statement.
288 \property @var{contextname}.@var{propname} \unset
291 @cindex properties, unsetting
292 @cindex @code{\unset}
295 This removes the definition of @var{propname} in @var{contextname}. If
296 @var{propname} was not defined in @var{contextname} (but was inherited
297 from a higher context), then this has no effect.
301 The syntax of @code{\unset} is asymmetric: @code{\property \unset} is not
302 the inverse of @code{\property \set}.
304 The context @code{Current} is confusing.
307 @node Context evaluation
308 @subsection Context evaluation
310 Contexts can be modified during interpretation with Scheme code. The
313 \applycontext @var{function}
316 @var{function} should be a Scheme function taking a single argument,
317 being the context to apply it to. The following code will print the
318 current bar number on the standard output during the compile:
323 (format #t "\nWe were called in barnumber ~a.\n"
324 (ly:get-context-property x 'currentBarNumber)))
329 @node Defining contexts
330 @subsection Defining contexts
332 @cindex context definition
333 @cindex translator definition
335 The most common way to create a new context definition is by extending
336 an existing one. An existing context from the paper block is copied
337 by referencing a context identifier:
342 @var{context-identifier}
348 Every predefined context has a standard identifier. For example, the
349 @code{Staff} context can be referred to as @code{\StaffContext}.
351 The context can then be modified by setting or changing properties,
356 Stem \set #'thickness = #2.0
357 defaultBarType = #"||"
360 These assignments happen before interpretation starts, so a @code{\property}
361 command will override any predefined settings.
367 It is not possible to collect multiple property assignments in a
368 variable, and apply to one @code{\translator} definition by
369 referencing that variable.
371 @node Changing contexts locally
372 @subsection Changing contexts locally
375 Extending an existing context can also be done locally. A piece of
376 music can be interpreted in a changed context by using the following syntax
380 @var{context modifications}
384 These statements comes between @code{\new} or @code{\context} and the
385 music to be interpreted. The @var{context modifications} property
386 settings and @code{\remove}, @code{\consists} and @code{\consistsend}
387 commands. The syntax is similar to the @code{\translator} block.
389 The following example shows how a staff is created with bigger spaces,
390 and without a @code{Clef_engraver}.
392 @lilypond[relative=1,fragment,verbatim]
394 \new Staff { c4 es4 g2 }
396 StaffSymbol \set #'staff-space = #(magstep 1.5)
398 \remove "Clef_engraver"
406 The command @code{\with} has no effect on contexts that already
407 exist. Neither can it be used for @internalsref{Score} contexts.
410 @node Engravers and performers
411 @subsection Engravers and performers
414 Each context is composed of a number of building blocks, or plug-ins
415 called engravers. An engraver is a specialized C++ class that is
416 compiled into the executable. Typically, an engraver is responsible
417 for one function: the @code{Slur_engraver} creates only @code{Slur}
418 objects, and the @code{Skip_event_swallow_translator} only swallows
419 (silently gobbles) @code{SkipEvent}s.
426 An existing context definition can be changed by adding or removing an
427 engraver. The syntax for these operations is
429 \consists @var{engravername}
430 \remove @var{engravername}
437 Here @var{engravername} is a string, the name of an engraver in the
438 system. In the following example, the @code{Clef_engraver} is removed
439 from the Staff context. The result is a staff without a clef, where
440 the central C is at its default position, the center line:
442 @lilypond[verbatim,raggedright]
450 \remove Clef_engraver
456 A list of all engravers is in the internal documentation,
457 see @internalsref{Engravers}.
459 @node Defining new contexts
460 @subsection Defining new contexts
463 It is also possible to define new contexts from scratch. To do this,
464 you must define give the new context a name. In the following
465 example, a very simple Staff context is created: one that will put
466 note heads on a staff symbol.
470 \type "Engraver_group_engraver"
473 \consists "Staff_symbol_engraver"
474 \consists "Note_head_engraver"
475 \consistsend "Axis_group_engraver"
480 The argument of @code{\type} is the name for a special engraver that
481 handles cooperation between simple engravers such as
482 @code{Note_head_engraver} and @code{Staff_symbol_engraver}. This
483 should always be @code{Engraver_group_engraver} (unless you are
484 defining a Score context from scratch, in which case
485 @code{Score_engraver} must be used).
487 The complete list of context modifiers is the following:
489 @item @code{\alias} @var{alternate-name}:
490 This specifies a different name. In the above example,
491 @code{\property Staff.X = Y} will also work on @code{SimpleStaff}s.
493 @item @code{\consistsend} @var{engravername}:
494 Analogous to @code{\consists}, but makes sure that
495 @var{engravername} is always added to the end of the list of
498 Engravers that group context objects into axis groups or alignments
499 need to be at the end of the list. @code{\consistsend} insures that
500 engravers stay at the end even if a user adds or removes engravers.
502 @item @code{\accepts} @var{contextname}:
503 This context can contains @var{contextname} contexts. The first
504 @code{\accepts} is created as a default context when events (e.g. notes
505 or rests) are encountered.
507 @item @code{\denies}:
508 The opposite of @code{\accepts}.
510 @item @code{\name} @var{contextname}:
511 This sets the type name of the context, e.g. @code{Staff},
512 @code{Voice}. If the name is not specified, the translator will not
517 @node Scheme integration
518 @section Scheme integration
522 @cindex Scheme, in-line code
523 @cindex accessing Scheme
524 @cindex evaluating Scheme
527 LilyPond internally uses GUILE, a Scheme-interpreter, to represent
528 data throughout the whole program, and glue together different program
529 modules. For advanced usage, it is sometimes necessary to access and
530 program the Scheme interpreter.
532 Scheme is a full-blown programming language, from the LISP
533 family. and a full discussion is outside the scope of this document.
534 Interested readers are referred to the website
535 @uref{http://www.schemers.org/} for more information on Scheme.
537 The GUILE library for extension is documented at
538 @uref{http://www.gnu.org/software/guile}.
540 When it is installed, the following link should take you to its manual
541 @ref{(guile.info)guile}
546 * Input variables and Scheme::
552 @subsection Inline Scheme
554 Scheme expressions can be entered in the input file by entering a
555 hash-sign (@code{#}). The expression following the hash-sign is
556 evaluated as Scheme. For example, the boolean value @var{true} is
557 @code{#t} in Scheme, so for LilyPond @var{true} looks like @code{##t},
558 and can be used in property assignments:
560 \property Staff.autoBeaming = ##f
564 @node Input variables and Scheme
565 @subsection Input variables and Scheme
568 The input format supports the notion of variable: in the following
569 example, a music expression is assigned to a variable with the name
572 traLaLa = \notes @{ c'4 d'4 @}
577 There is also a form of scoping: in the following example, the
578 @code{\paper} block also contains a @code{traLaLa} variable, which is
579 independent of the outer @code{\traLaLa}.
581 traLaLa = \notes @{ c'4 d'4 @}
582 \paper @{ traLaLa = 1.0 @}
585 In effect, each input file is a scope, and all @code{\header},
586 @code{\midi} and @code{\paper} blocks are scopes nested inside that
589 Both variables and scoping are implemented in the GUILE module system.
590 An anonymous Scheme module is attached to each scope. An assignment of
593 traLaLa = \notes @{ c'4 d'4 @}
597 is internally converted to a Scheme definition
599 (define traLaLa @var{Scheme value of ``@code{\notes ... }''})
602 This means that input variables and Scheme variables may be freely
603 mixed. In the following example, a music fragment is stored in the
604 variable @code{traLaLa}, and duplicated using Scheme. The result is
605 imported in a @code{\score} by means of a second variable
608 traLaLa = \notes @{ c'4 d'4 @}
610 #(define newLa (map ly:music-deep-copy
611 (list traLaLa traLaLa)))
613 (make-sequential-music newLa))
618 In the above example, music expressions can be `exported' from the
619 input to the Scheme interpreter. The opposite is also possible. By
620 wrapping a Scheme value in the function @code{ly:export}, a Scheme
621 value is interpreted as if it were entered in LilyPond syntax: instead
622 of defining @code{\twice}, the example above could also have been
626 \score @{ #(ly:export (make-sequential-music newLa)) @}
633 @node Scheme datatypes
634 @subsection Scheme datatypes
636 Scheme is used to glue together different program modules. To aid this
637 glue function, many LilyPond specific object types can be passed as
640 The following list are all LilyPond specific types, that
641 can exist during parsing:
648 In C++ terms, an @code{Event} is a subtype of @code{Music}. However,
649 both have different functions in the syntax.
650 @item Music_output_def
657 During a run, transient objects are also created and destroyed.
660 @item Grob: short for `Graphical object'.
661 @item Scheme_hash_table
664 @item Molecule: Device-independent page output object,
665 including dimensions.
671 @item Translator: An object that produces audio objects or Grobs.
672 It may be accessed with @code{\applyoutput}.
674 @item Font_metric: An object representing a font.
677 Many functions are defined to manipulate these data structures. They
678 are all listed and documented in the internals manual, see
679 @internalsref{All scheme functions}.
683 @subsection Assignments
686 Variables allow objects to be assigned to names during the parse
687 stage. To assign a variable, use
689 @var{name}@code{=}@var{value}
691 To refer to a variable, precede its name with a backslash:
692 `@code{\}@var{name}'. @var{value} is any valid Scheme value or any of
693 the input-types listed above. Variable assignments can appear at top
694 level in the LilyPond file, but also in @code{\paper} blocks.
696 A variable can be created with any string for its name, but for
697 accessing it in the LilyPond syntax, its name must consist of
698 alphabetic characters only, and may not be a keyword of the syntax.
699 There are no restrictions for naming and accessing variables in the
702 The right hand side of a variable assignment is parsed completely
703 before the assignment is done, so variables may be redefined in terms
704 of its old value, e.g.
710 When a variable is referenced in LilyPond syntax, the information it
711 points to is copied. For this reason, an variable reference must
712 always be the first item in a block.
717 \paperIdent % wrong and invalid
723 \paperIdent % correct
730 @node Music storage format
731 @section Music storage format
733 Music in LilyPond is entered as music expressions. This section
734 discusses different types of music expressions, and explains how
735 information is stored internally. This internal storage is accessible
736 through the Scheme interpreter, so music expressions may be
737 manipulated using Scheme functions.
740 * Music expressions::
741 * Internal music representation::
742 * Manipulating music expressions::
745 @node Music expressions
746 @subsection Music expressions
747 @cindex music expressions
749 Notes, rests, lyric syllables are music expressions. Small music
750 expressions may be combined to form larger ones, for example, by
751 enclosing a list of expressions in @code{\sequential @{ @}} or @code{<<
752 >>}. In the following example, a compound expression is formed out of
753 the quarter note @code{c} and a quarter note @code{d}:
756 \sequential @{ c4 d4 @}
759 @cindex Sequential music
760 @cindex @code{\sequential}
761 @cindex sequential music
764 @cindex Simultaneous music
765 @cindex @code{\simultaneous}
767 The two basic compound music expressions are simultaneous and
771 \sequential @code{@{} @var{musicexprlist} @code{@}}
772 \simultaneous @code{@{} @var{musicexprlist} @code{@}}
775 For both, there is a shorthand:
778 @code{@{} @var{musicexprlist} @code{@}}
785 @code{<<} @var{musicexprlist} @code{>>}
789 for simultaneous music.
790 In principle, the way in which you nest sequential and simultaneous to
791 produce music is not relevant. In the following example, three chords
792 are expressed in two different ways:
794 @lilypond[fragment,verbatim,center,quote]
795 \notes \context Voice {
796 <<a c'>> <<b d'>> <<c' e'>>
797 << { a b c' } { c' d' e' } >>
800 However, using @code{<<} and @code{>>} for entering chords leads to
801 various peculiarities. For this reason, a special syntax
802 for chords was introduced in version 1.7: @code{< >}.
808 Other compound music expressions include:
811 \transpose @var{from} @var{to} @var{expr}
812 \apply @var{func} @var{expr}
813 \context @var{type} = @var{id} @var{expr}
814 \times @var{fraction} @var{expr}
817 @node Internal music representation
818 @subsection Internal music representation
825 When a music expression is parsed, it is converted into a set of
826 Scheme music objects. The defining property of a music object is that
827 it takes up time. Time is a rational number that measures the length
828 of a piece of music, in whole notes.
830 A music object has three kinds of types:
833 music name: Each music expression has a name, for example, a note
834 leads to a @internalsref{NoteEvent}, and @code{\simultaneous} leads to
835 a @internalsref{SimultaneousMusic}. A list of all expressions
836 available is in the internals manual, under @internalsref{Music
840 `type' or interface: Each music name has several `types' or interface,
841 for example, a note is an @code{event}, but it is also a @code{note-event},
842 a @code{rhythmic-event} and a @code{melodic-event}.
844 All classes of music are listed in the internals manual, under
845 @internalsref{Music classes}.
847 C++ object: Each music object is represented by a C++ object. For technical
848 reasons, different music objects may be represented by different C++
849 object types. For example, a note is @code{Event} object, while
850 @code{\grace} creates a @code{Grace_music} object.
852 We expect that distinctions between different C++ types will disappear
856 The actual information of a music expression is stored in properties.
857 For example, a @internalsref{NoteEvent} has @code{pitch} and
858 @code{duration} properties that store the pitch and duration of that
859 note. A list of all properties available is in the internals manual,
860 under @internalsref{Music properties}.
862 A compound music expression is a music object that contains other
863 music objects in its properties. A list of objects can be stored in
864 the @code{elements} property of a music object, or a single `child'
865 music object in the @code{element} object. For example,
866 @internalsref{SequentialMusic} has its children in @code{elements},
867 and @internalsref{GraceMusic} has its single argument in
868 @code{element}. The body of a repeat is in @code{element} property of
869 @internalsref{RepeatedMusic}, and the alternatives in @code{elements}.
871 @node Manipulating music expressions
872 @subsection Manipulating music expressions
874 Music objects and their properties can be accessed and manipulated
875 directly, through the @code{\apply} mechanism.
876 The syntax for @code{\apply} is
878 \apply #@var{func} @var{music}
882 This means that the scheme function @var{func} is called with
883 @var{music} as its argument. The return value of @var{func} is the
884 result of the entire expression. @var{func} may read and write music
885 properties using the functions @code{ly:get-mus-property} and
886 @code{ly:set-mus-property!}.
888 An example is a function that reverses the order of elements in
890 @lilypond[verbatim,raggedright]
891 #(define (rev-music-1 m)
892 (ly:set-mus-property! m 'elements (reverse
893 (ly:get-mus-property m 'elements)))
895 \score { \notes \apply #rev-music-1 { c4 d4 } }
898 The use of such a function is very limited. The effect of this
899 function is void when applied to an argument which is does not have
900 multiple children. The following function application has no effect:
903 \apply #rev-music-1 \grace @{ c4 d4 @}
907 In this case, @code{\grace} is stored as @internalsref{GraceMusic}, which has no
908 @code{elements}, only a single @code{element}. Every generally
909 applicable function for @code{\apply} must -- like music expressions
910 themselves -- be recursive.
912 The following example is such a recursive function: It first extracts
913 the @code{elements} of an expression, reverses them and puts them
914 back. Then it recurses, both on @code{elements} and @code{element}
917 #(define (reverse-music music)
918 (let* ((elements (ly:get-mus-property music 'elements))
919 (child (ly:get-mus-property music 'element))
920 (reversed (reverse elements)))
923 (ly:set-mus-property! music 'elements reversed)
926 (if (ly:music? child) (reverse-music child))
927 (map reverse-music reversed)
932 A slightly more elaborate example is in
933 @inputfileref{input/test,reverse-music.ly}.
935 Some of the input syntax is also implemented as recursive music
936 functions. For example, the syntax for polyphony
942 is actually implemented as a recursive function that replaces the
943 above by the internal equivalent of
945 << \context Voice = "1" @{ \voiceOne a @}
946 \context Voice = "2" @{ \voiceTwo b @} >>
949 Other applications of @code{\apply} are writing out repeats
950 automatically (@inputfileref{input/test,unfold-all-repeats.ly}),
951 saving keystrokes (@inputfileref{input/test,music-box.ly}) and
953 LilyPond input to other formats (@inputfileref{input/test,to-xml.ly})
957 @file{scm/music-functions.scm}, @file{scm/music-types.scm},
958 @inputfileref{input/test,add-staccato.ly},
959 @inputfileref{input/test,unfold-all-repeats.ly}, and
960 @inputfileref{input/test,music-box.ly}.
962 @node Lexical details
963 @section Lexical details
969 By enclosing text in quotes (@code{"}), strings are formed. To
970 include a @code{"} character in a string write @code{\"}. Various
971 other backslash sequences have special interpretations as in the C
972 language. A string that does not contain spaces or special characters
973 can be written without the quotes. The exact form of such unquoted
974 strings depends on the input mode; there are different rules for
975 lyrics, notes and markups. Strings can be concatenated with the
980 @section Output details
982 LilyPond's default output format is @TeX{}. Using the option @option{-f}
983 (or @option{--format}) other output formats can be selected also, but
984 currently none of them work reliably.
986 At the beginning of the output file, various global parameters are defined.
987 It also contains a large @code{\special} call to define PostScript routines
988 to draw items not representable with @TeX{}, mainly slurs and ties. A DVI
989 driver must be able to understand such embedded PostScript, or the output
990 will be rendered incompletely.
992 Then the file @file{lilyponddefs.tex} is loaded to define the macros used
993 in the code which follows. @file{lilyponddefs.tex} includes various other
994 files, partially depending on the global parameters.
996 Now the music is output system by system (a `system' consists of all
997 staves belonging together). From @TeX{}'s point of view, a system is an
998 @code{\hbox} which contains a lowered @code{\vbox} so that it is centered
999 vertically on the baseline of the text. Between systems,
1000 @code{\interscoreline} is inserted vertically to have stretchable space.
1001 The horizontal dimension of the @code{\hbox} is given by the
1002 @code{linewidth} parameter from LilyPond's @code{\paper} block.
1005 After the last system LilyPond emits a stronger variant of
1006 @code{\interscoreline} only if the macro
1007 @code{\lilypondpaperlastpagefill} is not defined (flushing the systems
1008 to the top of the page). You can avoid that by setting the variable
1009 @code{lastpagefill} in LilyPond's @code{\paper} block.
1011 It is possible to fine-tune the vertical offset further by defining the
1012 macro @code{\lilypondscoreshift}:
1015 \def\lilypondscoreshift@{0.25\baselineskip@}
1019 where @code{\baselineskip} is the distance from one text line to the next.
1021 The code produced by LilyPond should be run through La@TeX{}, not
1024 Here an example how to embed a small LilyPond file @code{foo.ly} into
1025 running La@TeX{} text without using the @code{lilypond-book} script
1026 (@pxref{lilypond-book manual}):
1029 \documentclass@{article@}
1031 \def\lilypondpaperlastpagefill@{@}
1033 \def\lilypondscoreshift@{0.25\baselineskip@}
1036 This is running text which includes an example music file
1042 The file @file{foo.tex} has been simply produced with
1048 It is important to set the @code{indent} parameter to zero in the
1049 @code{\paper} block of @file{foo.ly}.
1051 The call to @code{\lineskip} assures that there is enough vertical space
1052 between the LilyPond box and the surrounding text lines.