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: @code{pitch}, @code{tremolo-type}.
66 @item Translation properties
67 These influence the translation process, and most users will encounter them
68 regularly. For example, beaming behavior is tuned with
69 @code{autoBeamSettings}.
71 These use mixed-caps naming: @code{autoBeamSettings},
72 @code{ignoreMelismata}.
75 @item Layout properties
76 These are internally used in the formatting process. Consequently, to
77 tune formatting details, it is necessary to adjust these
78 properties. For example, some objects may be moved around vertically
79 by setting their @code{padding} property.
81 These properties use Scheme-style naming: @code{c0-position},
82 @code{break-align-symbol}.
86 This chapter discusses details of the three concepts in more detail,
87 and explains how they are glued together in LilyPond with the embedded
91 * Interpretation context::
92 * Scheme integration::
93 * Music storage format::
99 @node Interpretation context
100 @section Interpretation context
103 * Creating contexts::
105 * Context properties::
106 * Context evaluation::
107 * Defining contexts::
108 * Changing contexts locally::
109 * Engravers and performers::
110 * Defining new contexts::
114 Interpretation contexts are objects that only exist during program
115 run. During the interpretation phase (when @code{interpreting music}
116 is printed on the standard output), the music expression in a
117 @code{\score} block is interpreted in time order, the same order in
118 which we hear and play the music. During this phase, the interpretation
119 context holds the state for the current point within the music, for
122 @item What notes are playing at this point?
124 @item What symbols will be printed at this point?
126 @item What is the current key signature, time signature, point within
130 Contexts are grouped hierarchically: A @internalsref{Voice} context is
131 contained in a @internalsref{Staff} context (because a staff can contain
132 multiple voices at any point), a @internalsref{Staff} context is contained in
133 @internalsref{Score}, @internalsref{StaffGroup}, or
134 @internalsref{ChoirStaff} context.
136 Contexts associated with sheet music output are called @emph{notation
137 contexts}, those for sound output are called @emph{performance
138 contexts}. The default definitions of the standard notation and
139 performance contexts can be found in @file{ly/engraver-init.ly} and
140 @file{ly/performer-init.ly}, respectively.
143 @node Creating contexts
144 @subsection Creating contexts
145 @cindex @code{\context}
146 @cindex context selection
148 Contexts for a music expression can be selected manually, using one of
149 the following music expressions:
152 \new @var{contexttype} @var{musicexpr}
153 \context @var{contexttype} [= @var{contextname}] @var{musicexpr}
157 This means that @var{musicexpr} should be interpreted within a context
158 of type @var{contexttype} (with name @var{contextname} if specified).
159 If no such context exists, it will be created:
161 @lilypond[verbatim,singleline]
163 \notes \relative c'' {
164 c4 <<d4 \context Staff = "another" e4>> f
170 In this example, the @code{c} and @code{d} are printed on the default
171 staff. For the @code{e}, a context @code{Staff} called @code{another}
172 is specified; since that does not exist, a new context is created.
173 Within @code{another}, a (default) Voice context is created for the
174 @code{e4}. A context is ended when when all music referring it has
175 finished, so after the third quarter, @code{another} is removed.
177 The @code{\new} construction creates a context with a
178 generated, unique @var{contextname}. An expression with
179 @code{\new} always leads to a new context. This is convenient
180 for creating multiple staffs, multiple lyric lines, etc.
182 When using automatic staff changes, automatic phrasing, etc., the
183 context names have special meanings, so @code{\new} cannot be
187 @node Default contexts
188 @subsection Default contexts
190 Every top level music is interpreted by the @code{Score} context; in
191 other words, you may think of @code{\score} working like
195 \context Score @var{music}
199 Music expressions inherit their context from the enclosing music
200 expression. Hence, it is not necessary to explicitly specify
201 @code{\context} for most expressions. In
202 the following example, only the sequential expression has an explicit
203 context. The notes contained therein inherit the @code{goUp} context
204 from the enclosing music expression.
206 @lilypond[verbatim,singleline]
207 \notes \context Voice = goUp { c'4 d' e' }
211 Second, contexts are created automatically to be able to interpret the
212 music expressions. Consider the following example:
214 @lilypond[verbatim, singleline]
215 \score { \notes { c'4-( d' e'-) } }
219 The sequential music is interpreted by the Score context initially,
220 but when a note is encountered, contexts are setup to accept that
221 note. In this case, a @code{Thread}, @code{Voice}, and @code{Staff}
222 context are created. The rest of the sequential music is also
223 interpreted with the same @code{Thread}, @code{Voice}, and
224 @code{Staff} context, putting the notes on the same staff, in the same
227 @node Context properties
228 @subsection Context properties
230 Contexts have properties. These properties are set from the @file{.ly}
231 file using the following expression:
232 @cindex @code{\property}
233 @cindex context properties
234 @cindex properties, context
237 \property @var{contextname}.@var{propname} = @var{value}
241 Sets the @var{propname} property of the context @var{contextname} to
242 the specified Scheme expression @var{value}. Both @var{propname} and
243 @var{contextname} are strings, which can often be written unquoted.
246 Properties that are set in one context are inherited by all of the
247 contained contexts. This means that a property valid for the
248 @internalsref{Voice} context can be set in the @internalsref{Score} context
249 (for example) and thus take effect in all @internalsref{Voice} contexts.
251 @cindex @code{Current}
252 If you do not wish to specify the name of the context in the
253 @code{\property}-expression itself, you can refer to the abstract context
254 name, @code{Current}. The @code{Current} context is the latest
255 used context. This will typically mean the @internalsref{Thread} context,
256 but you can force another context with the
257 @code{\property}-command. Hence the expressions
260 \property @var{contextname}.@var{propname} = @var{value}
267 \context @var{contextname}
268 \property Current.@var{propname} = @var{value}
272 do the same thing. The main use for this is in predefined variables.
273 This construction allows the specification of a property-setting
274 without restriction to a specific context.
276 Properties can be unset using the following statement.
278 \property @var{contextname}.@var{propname} \unset
281 @cindex properties, unsetting
282 @cindex @code{\unset}
285 This removes the definition of @var{propname} in @var{contextname}. If
286 @var{propname} was not defined in @var{contextname} (but was inherited
287 from a higher context), then this has no effect.
291 The syntax of @code{\unset} is asymmetric: @code{\property \unset} is not
292 the inverse of @code{\property \set}.
295 @node Context evaluation
296 @subsection Context evaluation
298 Contexts can be modified during interpretation with Scheme code. The
301 \applycontext @var{function}
304 @var{function} should be a Scheme function taking a single argument,
305 being the context to apply it to. The following code will print the
306 current bar number on the standard output during the compile:
311 (format #t "\nWe were called in barnumber ~a.\n"
312 (ly:get-context-property x 'currentBarNumber)))
317 @node Defining contexts
318 @subsection Defining contexts
320 @cindex context definition
321 @cindex translator definition
323 The most common way to create a new context definition is by extending
324 an existing one. An existing context from the paper block is copied
325 by referencing a context identifier:
330 @var{context-identifier}
336 Every predefined context has a standard identifier. For example, the
337 @code{Staff} context can be referred to as @code{\StaffContext}.
339 The context can then be modified by setting or changing properties,
344 Stem \set #'thickness = #2.0
345 defaultBarType = #"||"
348 These assignments happen before interpretation starts, so a @code{\property}
349 command will override any predefined settings.
355 It is not possible to collect multiple property assignments in a
356 variable, and apply to one @code{\translator} definition by
357 referencing that variable.
359 @node Changing contexts locally
360 @subsection Changing contexts locally
363 Extending an existing context can also be done locally. A piece of
364 music can be interpreted in a changed context by using the following syntax
368 @var{context modifications}
372 These statements comes between @code{\new} or @code{\context} and the
373 music to be interpreted. The @var{context modifications} property
374 settings and @code{\remove}, @code{\consists} and @code{\consistsend}
375 commands. The syntax is similar to the @code{\translator} block.
377 The following example shows how a staff is created with bigger spaces,
378 and without a @code{Clef_engraver}.
380 @lilypond[relative=1,fragment,verbatim]
382 \new Staff { c4 es4 g2 }
384 StaffSymbol \set #'staff-space = #(magstep 1.5)
386 \remove "Clef_engraver"
394 The command @code{\with} has no effect on contexts that already
395 exist. Neither can it be used for @internalsref{Score} contexts.
398 @node Engravers and performers
399 @subsection Engravers and performers
402 Each context is composed of a number of building blocks, or plug-ins
403 called engravers. An engraver is a specialized C++ class that is
404 compiled into the executable. Typically, an engraver is responsible
405 for one function: the @code{Slur_engraver} creates only @code{Slur}
406 objects, and the @code{Skip_event_swallow_translator} only swallows
407 (silently gobbles) @code{SkipEvent}s.
414 An existing context definition can be changed by adding or removing an
415 engraver. The syntax for these operations is
417 \consists @var{engravername}
418 \remove @var{engravername}
425 Here @var{engravername} is a string, the name of an engraver in the
426 system. In the following example, the @code{Clef_engraver} is removed
427 from the Staff context. The result is a staff without a clef, where
428 the central C is at its default position, the center line:
430 @lilypond[verbatim,singleline]
438 \remove Clef_engraver
444 A list of all engravers is in the internal documentation,
445 see @internalsref{All engravers}.
447 @node Defining new contexts
448 @subsection Defining new contexts
451 It is also possible to define new contexts from scratch. To do this,
452 you must define give the new context a name. In the following
453 example, a very simple Staff context is created: one that will put
454 note heads on a staff symbol.
458 \type "Engraver_group_engraver"
461 \consists "Staff_symbol_engraver"
462 \consists "Note_head_engraver"
463 \consistsend "Axis_group_engraver"
468 The argument of @code{\type} is the name for a special engraver that
469 handles cooperation between simple engravers such as
470 @code{Note_head_engraver} and @code{Staff_symbol_engraver}. This
471 should always be @code{Engraver_group_engraver} (unless you are
472 defining a Score context from scratch, in which case
473 @code{Score_engraver} must be used).
475 The complete list of context modifiers is the following:
477 @item @code{\alias} @var{alternate-name}:
478 This specifies a different name. In the above example,
479 @code{\property Staff.X = Y} will also work on @code{SimpleStaff}s.
481 @item @code{\consistsend} @var{engravername}:
482 Analogous to @code{\consists}, but makes sure that
483 @var{engravername} is always added to the end of the list of
486 Engravers that group context objects into axis groups or alignments
487 need to be at the end of the list. @code{\consistsend} insures that
488 engravers stay at the end even if a user adds or removes engravers.
490 @item @code{\accepts} @var{contextname}:
491 This context can contains @var{contextname} contexts. The first
492 @code{\accepts} is created as a default context when events (e.g. notes
493 or rests) are encountered.
495 @item @code{\denies}:
496 The opposite of @code{\accepts}.
498 @item @code{\name} @var{contextname}:
499 This sets the type name of the context, e.g. @code{Staff},
500 @code{Voice}. If the name is not specified, the translator will not
505 @node Scheme integration
506 @section Scheme integration
510 @cindex Scheme, in-line code
511 @cindex accessing Scheme
512 @cindex evaluating Scheme
515 LilyPond internally uses GUILE, a Scheme-interpreter, to represent
516 data throughout the whole program, and glue together different program
517 modules. For advanced usage, it is sometimes necessary to access and
518 program the Scheme interpreter.
520 Scheme is a full-blown programming language, from the LISP
521 family. and a full discussion is outside the scope of this document.
522 Interested readers are referred to the website
523 @uref{http://www.schemers.org/} for more information on Scheme.
525 The GUILE library for extension is documented at
526 @uref{http://www.gnu.org/software/guile}.
528 When it is installed, the following link should take you to its manual
529 @ref{(guile.info)guile}
534 * Input variables and Scheme::
540 @subsection Inline Scheme
542 Scheme expressions can be entered in the input file by entering a
543 hash-sign (@code{#}). The expression following the hash-sign is
544 evaluated as Scheme. For example, the boolean value @var{true} is
545 @code{#t} in Scheme, so for LilyPond @var{true} looks like @code{##t},
546 and can be used in property assignments:
548 \property Staff.autoBeaming = ##f
552 @node Input variables and Scheme
553 @subsection Input variables and Scheme
556 The input format supports the notion of variable: in the following
557 example, a music expression is assigned to a variable with the name
560 traLaLa = \notes @{ c'4 d'4 @}
565 There is also a form of scoping: in the following example, the
566 @code{\paper} block also contains a @code{traLaLa} variable, which is
567 independent of the outer @code{\traLaLa}.
569 traLaLa = \notes @{ c'4 d'4 @}
570 \paper @{ traLaLa = 1.0 @}
573 In effect, each input file is a scope, and all @code{\header},
574 @code{\midi} and @code{\paper} blocks are scopes nested inside that
577 Both variables and scoping are implemented in the GUILE module system.
578 An anonymous Scheme module is attached to each scope. An assignment of
581 traLaLa = \notes @{ c'4 d'4 @}
585 is internally converted to a Scheme definition
587 (define traLaLa @var{Scheme value of ``@code{\notes ... }''})
590 This means that input variables and Scheme variables may be freely
591 mixed. In the following example, a music fragment is stored in the
592 variable @code{traLaLa}, and duplicated using Scheme. The result is
593 imported in a @code{\score} by means of a second variable
596 traLaLa = \notes @{ c'4 d'4 @}
598 #(define newLa (map ly:music-deep-copy
599 (list traLaLa traLaLa)))
601 (make-sequential-music newLa))
606 In the above example, music expressions can be `exported' from the
607 input to the Scheme interpreter. The opposite is also possible. By
608 wrapping a Scheme value in the function @code{ly:export}, a Scheme
609 value is interpreted as if it were entered in LilyPond syntax: instead
610 of defining @code{\twice}, the example above could also have been
614 \score @{ #(ly:export (make-sequential-music newLa)) @}
621 @node Scheme datatypes
622 @subsection Scheme datatypes
624 Scheme is used to glue together different program modules. To aid this
625 glue function, many LilyPond specific object types can be passed as
628 The following list are all LilyPond specific types, that
629 can exist during parsing:
636 In C++ terms, an @code{Event} is a subtype of @code{Music}. However,
637 both have different functions in the syntax.
638 @item Music_output_def
645 During a run, transient objects are also created and destroyed.
648 @item Grob: short for `Graphical object'.
649 @item Scheme_hash_table
652 @item Molecule: Device-independent page output object,
653 including dimensions.
659 @item Translator: An object that produces audio objects or Grobs.
660 It may be accessed with @code{\applyoutput}.
662 @item Font_metric: An object representing a font.
665 Many functions are defined to manipulate these data structures. They
666 are all listed and documented in the internals manual, see
667 @internalsref{All scheme functions}.
671 @subsection Assignments
674 Variables allow objects to be assigned to names during the parse
675 stage. To assign a variable, use
677 @var{name}@code{=}@var{value}
679 To refer to a variable, precede its name with a backslash:
680 `@code{\}@var{name}'. @var{value} is any valid Scheme value or any of
681 the input-types listed above. Variable assignments can appear at top
682 level in the LilyPond file, but also in @code{\paper} blocks.
684 A variable can be created with any string for its name, but for
685 accessing it in the LilyPond syntax, its name must consist of
686 alphabetic characters only, and may not be a keyword of the syntax.
687 There are no restrictions for naming and accessing variables in the
690 The right hand side of a variable assignment is parsed completely
691 before the assignment is done, so variables may be redefined in terms
692 of its old value, e.g.
698 When a variable is referenced in LilyPond syntax, the information it
699 points to is copied. For this reason, an variable reference must
700 always be the first item in a block.
705 \paperIdent % wrong and invalid
711 \paperIdent % correct
718 @node Music storage format
719 @section Music storage format
721 Music in LilyPond is entered as music expressions. This section
722 discusses different types of music expressions, and explains how
723 information is stored internally. This internal storage is accessible
724 through the Scheme interpreter, so music expressions may be
725 manipulated using Scheme functions.
728 * Music expressions::
729 * Internal music representation::
730 * Manipulating music expressions::
733 @node Music expressions
734 @subsection Music expressions
735 @cindex music expressions
737 Notes, rests, lyric syllables are music expressions. Small music
738 expressions may be combined to form larger ones, for example, by
739 enclosing a list of expressions in @code{\sequential @{ @}} or @code{<<
740 >>}. In the following example, a compound expression is formed out of
741 the quarter note @code{c} and a quarter note @code{d}:
744 \sequential @{ c4 d4 @}
747 @cindex Sequential music
748 @cindex @code{\sequential}
749 @cindex sequential music
752 @cindex Simultaneous music
753 @cindex @code{\simultaneous}
755 The two basic compound music expressions are simultaneous and
759 \sequential @code{@{} @var{musicexprlist} @code{@}}
760 \simultaneous @code{@{} @var{musicexprlist} @code{@}}
763 For both, there is a shorthand:
766 @code{@{} @var{musicexprlist} @code{@}}
773 @code{<<} @var{musicexprlist} @code{>>}
777 for simultaneous music.
778 In principle, the way in which you nest sequential and simultaneous to
779 produce music is not relevant. In the following example, three chords
780 are expressed in two different ways:
782 @lilypond[fragment,verbatim,center,quote]
783 \notes \context Voice {
784 <<a c'>> <<b d'>> <<c' e'>>
785 << { a b c' } { c' d' e' } >>
788 However, using @code{<<} and @code{>>} for entering chords leads to
789 various peculiarities. For this reason, a special syntax
790 for chords was introduced in version 1.7: @code{< >}.
796 Other compound music expressions include:
799 \transpose @var{from} @var{to} @var{expr}
800 \apply @var{func} @var{expr}
801 \context @var{type} = @var{id} @var{expr}
802 \times @var{fraction} @var{expr}
805 @node Internal music representation
806 @subsection Internal music representation
813 When a music expression is parsed, it is converted into a set of
814 Scheme music objects. The defining property of a music object is that
815 it takes up time. Time is a rational number that measures the length
816 of a piece of music, in whole notes.
818 A music object has three kinds of types:
821 music name: Each music expression has a name, for example, a note
822 leads to a @internalsref{NoteEvent}, and @code{\simultaneous} leads to
823 a @internalsref{SimultaneousMusic}. A list of all expressions
824 available is in the internals manual, under @internalsref{Music
828 `type' or interface: Each music name has several `types' or interface,
829 for example, a note is an @code{event}, but it is also a @code{note-event},
830 a @code{rhythmic-event} and a @code{melodic-event}.
832 All classes of music are listed in the internals manual, under
833 @internalsref{Music classes}.
835 C++ object: Each music object is represented by a C++ object. For technical
836 reasons, different music objects may be represented by different C++
837 object types. For example, a note is @code{Event} object, while
838 @code{\grace} creates a @code{Grace_music} object.
840 We expect that distinctions between different C++ types will disappear
844 The actual information of a music expression is stored in properties.
845 For example, a @internalsref{NoteEvent} has @code{pitch} and
846 @code{duration} properties that store the pitch and duration of that
847 note. A list of all properties available is in the internals manual,
848 under @internalsref{Music properties}.
850 A compound music expression is a music object that contains other
851 music objects in its properties. A list of objects can be stored in
852 the @code{elements} property of a music object, or a single `child'
853 music object in the @code{element} object. For example,
854 @internalsref{SequentialMusic} has its children in @code{elements},
855 and @internalsref{GraceMusic} has its single argument in
856 @code{element}. The body of a repeat is in @code{element} property of
857 @internalsref{RepeatedMusic}, and the alternatives in @code{elements}.
859 @node Manipulating music expressions
860 @subsection Manipulating music expressions
862 Music objects and their properties can be accessed and manipulated
863 directly, through the @code{\apply} mechanism.
864 The syntax for @code{\apply} is
866 \apply #@var{func} @var{music}
870 This means that the scheme function @var{func} is called with
871 @var{music} as its argument. The return value of @var{func} is the
872 result of the entire expression. @var{func} may read and write music
873 properties using the functions @code{ly:get-mus-property} and
874 @code{ly:set-mus-property!}.
876 An example is a function that reverses the order of elements in
878 @lilypond[verbatim,singleline]
879 #(define (rev-music-1 m)
880 (ly:set-mus-property! m 'elements (reverse
881 (ly:get-mus-property m 'elements)))
883 \score { \notes \apply #rev-music-1 { c4 d4 } }
886 The use of such a function is very limited. The effect of this
887 function is void when applied to an argument which is does not have
888 multiple children. The following function application has no effect:
891 \apply #rev-music-1 \grace @{ c4 d4 @}
895 In this case, @code{\grace} is stored as @internalsref{GraceMusic}, which has no
896 @code{elements}, only a single @code{element}. Every generally
897 applicable function for @code{\apply} must -- like music expressions
898 themselves -- be recursive.
900 The following example is such a recursive function: It first extracts
901 the @code{elements} of an expression, reverses them and puts them
902 back. Then it recurses, both on @code{elements} and @code{element}
905 #(define (reverse-music music)
906 (let* ((elements (ly:get-mus-property music 'elements))
907 (child (ly:get-mus-property music 'element))
908 (reversed (reverse elements)))
911 (ly:set-mus-property! music 'elements reversed)
914 (if (ly:music? child) (reverse-music child))
915 (map reverse-music reversed)
920 A slightly more elaborate example is in
921 @inputfileref{input/test,reverse-music.ly}.
923 Some of the input syntax is also implemented as recursive music
924 functions. For example, the syntax for polyphony
930 is actually implemented as a recursive function that replaces the
931 above by the internal equivalent of
933 << \context Voice = "1" @{ \voiceOne a @}
934 \context Voice = "2" @{ \voiceTwo b @} >>
937 Other applications of @code{\apply} are writing out repeats
938 automatically (@inputfileref{input/test,unfold-all-repeats.ly}),
939 saving keystrokes (@inputfileref{input/test,music-box.ly}) and
941 LilyPond input to other formats (@inputfileref{input/test,to-xml.ly})
945 @file{scm/music-functions.scm}, @file{scm/music-types.scm},
946 @inputfileref{input/test,add-staccato.ly},
947 @inputfileref{input/test,unfold-all-repeats.ly}, and
948 @inputfileref{input/test,music-box.ly}.
950 @node Lexical details
951 @section Lexical details
957 By enclosing text in quotes (@code{"}), strings are formed. To
958 include a @code{"} character in a string write @code{\"}. Various
959 other backslash sequences have special interpretations as in the C
960 language. A string that does not contain spaces or special characters
961 can be written without the quotes. The exact form of such unquoted
962 strings depends on the input mode; there are different rules for
963 lyrics, notes and markups. Strings can be concatenated with the
968 @section Output details
970 LilyPond's default output format is @TeX{}. Using the option @option{-f}
971 (or @option{--format}) other output formats can be selected also, but
972 currently none of them work reliably.
974 At the beginning of the output file, various global parameters are defined.
975 It also contains a large @code{\special} call to define PostScript routines
976 to draw items not representable with @TeX{}, mainly slurs and ties. A DVI
977 driver must be able to understand such embedded PostScript, or the output
978 will be rendered incompletely.
980 Then the file @file{lilyponddefs.tex} is loaded to define the macros used
981 in the code which follows. @file{lilyponddefs.tex} includes various other
982 files, partially depending on the global parameters.
984 Now the music is output system by system (a `system' consists of all
985 staves belonging together). From @TeX{}'s point of view, a system is an
986 @code{\hbox} which contains a lowered @code{\vbox} so that it is centered
987 vertically on the baseline of the text. Between systems,
988 @code{\interscoreline} is inserted vertically to have stretchable space.
989 The horizontal dimension of the @code{\hbox} is given by the
990 @code{linewidth} parameter from LilyPond's @code{\paper} block.
993 After the last system LilyPond emits a stronger variant of
994 @code{\interscoreline} only if the macro
995 @code{\lilypondpaperlastpagefill} is not defined (flushing the systems
996 to the top of the page). You can avoid that by setting the variable
997 @code{lastpagefill} in LilyPond's @code{\paper} block.
999 It is possible to fine-tune the vertical offset further by defining the
1000 macro @code{\lilypondscoreshift}:
1003 \def\lilypondscoreshift@{0.25\baselineskip@}
1007 where @code{\baselineskip} is the distance from one text line to the next.
1009 The code produced by LilyPond should be run through La@TeX{}, not
1012 Here an example how to embed a small LilyPond file @code{foo.ly} into
1013 running La@TeX{} text without using the @code{lilypond-book} script
1014 (@pxref{lilypond-book manual}):
1017 \documentclass@{article@}
1019 \def\lilypondpaperlastpagefill@{@}
1021 \def\lilypondscoreshift@{0.25\baselineskip@}
1024 This is running text which includes an example music file
1030 The file @file{foo.tex} has been simply produced with
1036 It is important to set the @code{indent} parameter to zero in the
1037 @code{\paper} block of @file{foo.ly}.
1039 The call to @code{\lineskip} assures that there is enough vertical space
1040 between the LilyPond box and the surrounding text lines.