1 @c -*- coding: utf-8; mode: texinfo; -*-
2 @c This file is part of lilypond-learning.tely
4 Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
6 When revising a translation, copy the HEAD committish of the
7 version that you are working on. See TRANSLATION for details.
15 This chapter introduces readers to LilyPond and the
20 * About the documentation::
27 This section covers the overall goals and architecture of
32 * Automated engraving::
33 * What symbols to engrave?::
34 * Music representation::
35 * Example applications::
40 @unnumberedsubsec Engraving
42 The art of music typography is called @emph{(plate) engraving}.
43 The term derives from the traditional process of music printing.
44 Just a few decades ago, sheet music was made by cutting and
45 stamping the music into a zinc or pewter plate in mirror image.
46 The plate would be inked, the depressions caused by the cutting
47 and stamping would hold ink. An image was formed by pressing
48 paper to the plate. The stamping and cutting was completely done
49 by hand. Making a correction was cumbersome, if possible at all,
50 so the engraving had to be perfect in one go. Engraving was a
51 highly specialized skill; a craftsman had to complete around five
52 years of training before earning the title of master engraver, and
53 another five years of experience were necessary to become truly
56 Nowadays, all newly printed music is produced with computers.
57 This has obvious advantages; prints are cheaper to make, and
58 editorial work can be delivered by email. Unfortunately, the
59 pervasive use of computers has also decreased the graphical
60 quality of scores. Computer printouts have a bland, mechanical
61 look, which makes them unpleasant to play from.
64 @c introduce illustrating aspects of engraving, font...
65 The images below illustrate the difference between traditional
66 engraving and typical computer output, and the third picture shows
67 how LilyPond mimics the traditional look. The left picture shows
68 a scan of a flat symbol from an edition published in 2000. The
69 center depicts a symbol from a hand-engraved Bärenreiter edition
70 of the same music. The left scan illustrates typical flaws of
71 computer print: the staff lines are thin, the weight of the flat
72 symbol matches the light lines and it has a straight layout with
73 sharp corners. By contrast, the Bärenreiter flat has a bold,
74 almost voluptuous rounded look. Our flat symbol is designed
75 after, among others, this one. It is rounded, and its weight
76 harmonizes with the thickness of our staff lines, which are also
77 much thicker than lines in the computer edition.
79 @multitable @columnfractions .125 .25 .25 .25 .125
83 @image{henle-flat-gray,,4cm}
86 @image{henle-flat-gray,,,png}
91 @image{baer-flat-gray,,4cm}
94 @image{baer-flat-gray,,,png}
99 @image{lily-flat-bw,,4cm}
102 @image{lily-flat-bw,,,png}
106 @image{lilypond/henle-flat-bw,,,png} @image{lilypond/baer-flat-bw,,,png}
107 @image{lilypond/lily-flat-bw,,,png}
115 LilyPond Feta font (2003)
120 @cindex musical symbols
125 @c introduce illustrating aspects of engraving, spacing...
126 In spacing, the distribution of space should reflect the durations
127 between notes. However, many modern scores adhere to the
128 durations with mathematical precision, which leads to poor
129 results. In the next example a motive is printed twice: once
130 using exact mathematical spacing, and once with corrections. Can
131 you spot which fragment is which?
133 @cindex optical spacing
134 @c file spacing-optical.
135 @c need to include it here, because we want two images.
156 \override NoteSpacing #'stem-spacing-correction = #0.6
181 \override NoteSpacing #'stem-spacing-correction = #0.0
182 \override NoteSpacing #'same-direction-correction = #0.0
183 \override StaffSpacing #'stem-spacing-correction = #0.0
189 @cindex regular rhythms
190 @cindex regular spacing
192 Each bar in the fragment only uses notes that are played in a
193 constant rhythm. The spacing should reflect that. Unfortunately,
194 the eye deceives us a little; not only does it notice the distance
195 between note heads, it also takes into account the distance
196 between consecutive stems. As a result, the notes of an
197 up-stem/@/down-stem combination should be put farther apart, and
198 the notes of a down-stem/@/up-stem combination should be put
199 closer together, all depending on the combined vertical positions
200 of the notes. The upper two measures are printed with this
201 correction, the lower two measures without, forming
202 down-stem/@/up-stem clumps of notes.
206 Musicians are usually more absorbed with performing than with
207 studying the looks of a piece of music, so nitpicking about
208 typographical details may seem academical. But it is not. In
209 larger pieces with monotonous rhythms, spacing corrections lead to
210 subtle variations in the layout of every line, giving each one a
211 distinct visual signature. Without this signature all lines would
212 look the same, and they become like a labyrinth. If a musician
213 looks away once or has a lapse in concentration, the lines might
214 lose their place on the page.
216 Similarly, the strong visual look of bold symbols on heavy staff
217 lines stands out better when the music is far away from the
218 reader, for example, if it is on a music stand. A careful
219 distribution of white space allows music to be set very tightly
220 without cluttering symbols together. The result minimizes the
221 number of page turns, which is a great advantage.
223 This is a common characteristic of typography. Layout should be
224 pretty, not only for its own sake, but especially because it helps
225 the reader in her task. For performance material like sheet
226 music, this is of double importance: musicians have a limited
227 amount of attention. The less attention they need for reading,
228 the more they can focus on playing the music. In other words,
229 better typography translates to better performances.
231 These examples demonstrate that music typography is an art that is
232 subtle and complex, and that producing it requires considerable
233 expertise, which musicians usually do not have. LilyPond is our
234 effort to bring the graphical excellence of hand-engraved music to
235 the computer age, and make it available to normal musicians. We
236 have tuned our algorithms, font-designs, and program settings to
237 produce prints that match the quality of the old editions we love
238 to see and love to play from.
241 @node Automated engraving
242 @unnumberedsubsec Automated engraving
244 How do we go about implementing typography? If craftsmen need
245 over ten years to become true masters, how could we simple hackers
246 ever write a program to take over their jobs?
248 The answer is: we cannot. Typography relies on human judgment of
249 appearance, so people cannot be replaced completely. However,
250 much of the dull work can be automated. If LilyPond solves most
251 of the common situations correctly, this will be a huge
252 improvement over existing software. The remaining cases can be
253 tuned by hand. Over the course of years, the software can be
254 refined to do more and more things automatically, so manual
255 overrides are less and less necessary.
257 When we started, we wrote the LilyPond program entirely in the C++
258 programming language; the program's functionality was set in stone
259 by the developers. That proved to be unsatisfactory for a number
264 @item When LilyPond makes mistakes, users need to override
265 formatting decisions. Therefore, the user must have access to the
266 formatting engine. Hence, rules and settings cannot be fixed by
267 us at compile-time but must be accessible for users at run-time.
269 @item Engraving is a matter of visual judgment, and therefore a
270 matter of taste. As knowledgeable as we are, users can disagree
271 with our personal decisions. Therefore, the definitions of
272 typographical style must also be accessible to the user.
274 @item Finally, we continually refine the formatting algorithms, so
275 we need a flexible approach to rules. The C++ language forces a
276 certain method of grouping rules that do not match well with how
277 music notation works.
281 These problems have been addressed by integrating an interpreter
282 for the Scheme programming language and rewriting parts of
283 LilyPond in Scheme. The current formatting architecture is built
284 around the notion of graphical objects, described by Scheme
285 variables and functions. This architecture encompasses formatting
286 rules, typographical style and individual formatting decisions.
287 The user has direct access to most of these controls.
289 Scheme variables control layout decisions. For example, many
290 graphical objects have a direction variable that encodes the
291 choice between up and down (or left and right). Here you see two
292 chords, with accents and arpeggios. In the first chord, the
293 graphical objects have all directions down (or left). The second
294 chord has all directions up (right).
296 @lilypond[quote,ragged-right]
298 \override SpacingSpanner #'spacing-increment = #3
299 \override TimeSignature #'transparent = ##t
301 \stemDown <e g b>4_>-\arpeggio
302 \override Arpeggio #'direction = #RIGHT
303 \stemUp <e g b>4^>-\arpeggio
308 The process of formatting a score consists of reading and writing
309 the variables of graphical objects. Some variables have a preset
310 value. For example, the thickness of many lines -- a
311 characteristic of typographical style -- is a variable with a
312 preset value. You are free to alter this value, giving your score
313 a different typographical impression.
315 @lilypond[quote,ragged-right]
318 c'4-~ c'16 as g f e16 g bes c' des'4
323 \override Beam #'thickness = #0.3
324 \override Stem #'thickness = #0.5
325 \override Bar #'thickness = #3.6
326 \override Tie #'thickness = #2.2
327 \override StaffSymbol #'thickness = #3.0
328 \override Tie #'extra-offset = #'(0 . 0.3)
334 Formatting rules are also preset variables: each object has
335 variables containing procedures. These procedures perform the
336 actual formatting, and by substituting different ones, we can
337 change the appearance of objects. In the following example, the
338 rule which note head objects are used to produce their symbol is
339 changed during the music fragment.
341 @lilypond[quote,ragged-right]
342 #(set-global-staff-size 30)
344 #(define (mc-squared grob orig current)
345 (let* ((interfaces (ly:grob-interfaces grob))
346 (pos (ly:grob-property grob 'staff-position)))
347 (if (memq 'note-head-interface interfaces)
349 (ly:grob-set-property! grob 'stencil ly:text-interface::print)
350 (ly:grob-set-property! grob 'font-family 'roman)
351 (ly:grob-set-property! grob 'text
352 (make-raise-markup -0.5
354 ((-5) (make-simple-markup "m"))
355 ((-3) (make-simple-markup "c "))
356 ((-2) (make-smaller-markup (make-bold-markup "2")))
357 (else (make-simple-markup "bla")))))))))
359 \new Voice \relative c' {
361 \set autoBeaming = ##f
364 \once \override NoteHead #'stencil = #ly:note-head::brew-ez-stencil
365 \once \override NoteHead #'font-size = #-7
366 \once \override NoteHead #'font-family = #'sans
367 \once \override NoteHead #'font-series = #'bold
369 \once \override NoteHead #'style = #'cross
371 \applyOutput #'Voice #mc-squared
374 { d8[ es-( fis^^ g] fis2-) }
375 \repeat unfold 5 { \applyOutput #'Voice #mc-squared s8 }
381 @node What symbols to engrave?
382 @unnumberedsubsec What symbols to engrave?
387 The formatting process decides where to place symbols. However,
388 this can only be done once it is decided @emph{what} symbols
389 should be printed, in other words what notation to use.
391 Common music notation is a system of recording music that has
392 evolved over the past 1000 years. The form that is now in common
393 use dates from the early renaissance. Although the basic form
394 (i.e., note heads on a 5-line staff) has not changed, the details
395 still evolve to express the innovations of contemporary notation.
396 Hence, it encompasses some 500 years of music. Its applications
397 range from monophonic melodies to monstrous counterpoints for
400 How can we get a grip on such a many-headed beast, and force it
401 into the confines of a computer program? Our solution is to break
402 up the problem of notation (as opposed to engraving, i.e.,
403 typography) into digestible and programmable chunks: every type of
404 symbol is handled by a separate module, a so-called plug-in. Each
405 plug-in is completely modular and independent, so each can be
406 developed and improved separately. Such plug-ins are called
407 @code{engraver}s, by analogy with craftsmen who translate musical
408 ideas to graphic symbols.
410 In the following example, we see how we start out with a plug-in
411 for note heads, the @code{Note_heads_engraver}.
413 @lilypond[quote,ragged-right]
414 \include "engraver-example.ily"
421 \remove "Stem_engraver"
422 \remove "Phrasing_slur_engraver"
423 \remove "Slur_engraver"
424 \remove "Script_engraver"
425 \remove "Beam_engraver"
426 \remove "Auto_beam_engraver"
430 \remove "Accidental_engraver"
431 \remove "Key_engraver"
432 \remove "Clef_engraver"
433 \remove "Bar_engraver"
434 \remove "Time_signature_engraver"
435 \remove "Staff_symbol_engraver"
436 \consists "Pitch_squash_engraver"
443 Then a @code{Staff_symbol_engraver} adds the staff
445 @lilypond[quote,ragged-right]
446 \include "engraver-example.ily"
453 \remove "Stem_engraver"
454 \remove "Phrasing_slur_engraver"
455 \remove "Slur_engraver"
456 \remove "Script_engraver"
457 \remove "Beam_engraver"
458 \remove "Auto_beam_engraver"
462 \remove "Accidental_engraver"
463 \remove "Key_engraver"
464 \remove "Clef_engraver"
465 \remove "Bar_engraver"
466 \consists "Pitch_squash_engraver"
467 \remove "Time_signature_engraver"
474 the @code{Clef_engraver} defines a reference point for the staff
476 @lilypond[quote,ragged-right]
477 \include "engraver-example.ily"
484 \remove "Stem_engraver"
485 \remove "Phrasing_slur_engraver"
486 \remove "Slur_engraver"
487 \remove "Script_engraver"
488 \remove "Beam_engraver"
489 \remove "Auto_beam_engraver"
493 \remove "Accidental_engraver"
494 \remove "Key_engraver"
495 \remove "Bar_engraver"
496 \remove "Time_signature_engraver"
503 and the @code{Stem_engraver} adds stems.
505 @lilypond[quote,ragged-right]
506 \include "engraver-example.ily"
513 \remove "Phrasing_slur_engraver"
514 \remove "Slur_engraver"
515 \remove "Script_engraver"
516 \remove "Beam_engraver"
517 \remove "Auto_beam_engraver"
521 \remove "Accidental_engraver"
522 \remove "Key_engraver"
523 \remove "Bar_engraver"
524 \remove "Time_signature_engraver"
531 The @code{Stem_engraver} is notified of any note head coming
532 along. Every time one (or more, for a chord) note head is seen, a
533 stem object is created and connected to the note head. By adding
534 engravers for beams, slurs, accents, accidentals, bar lines, time
535 signature, and key signature, we get a complete piece of notation.
537 @lilypond[quote,ragged-right]
538 \include "engraver-example.ily"
542 This system works well for monophonic music, but what about
543 polyphony? In polyphonic notation, many voices can share a staff.
545 @lilypond[quote,ragged-right]
546 \include "engraver-example.ily"
547 \new Staff << \topVoice \\ \botVoice >>
550 In this situation, the accidentals and staff are shared, but the
551 stems, slurs, beams, etc., are private to each voice. Hence,
552 engravers should be grouped. The engravers for note heads, stems,
553 slurs, etc., go into a group called @q{Voice context,} while the
554 engravers for key, accidental, bar, etc., go into a group called
555 @q{Staff context.} In the case of polyphony, a single Staff
556 context contains more than one Voice context. Similarly, multiple
557 Staff contexts can be put into a single Score context. The Score
558 context is the top level notation context.
562 Internals Reference: @rinternals{Contexts}.
564 @lilypond[quote,ragged-right]
565 \include "engraver-example.ily"
568 \new Staff << \topVoice \\ \botVoice >>
569 \new Staff << \pah \\ \hoom >>
575 @node Music representation
576 @unnumberedsubsec Music representation
578 Ideally, the input format for any high-level formatting system is
579 an abstract description of the content. In this case, that would
580 be the music itself. This poses a formidable problem: how can we
581 define what music really is? Instead of trying to find an answer,
582 we have reversed the question. We write a program capable of
583 producing sheet music, and adjust the format to be as lean as
584 possible. When the format can no longer be trimmed down, by
585 definition we are left with content itself. Our program serves as
586 a formal definition of a music document.
588 The syntax is also the user-interface for LilyPond, hence it is
598 to create a quarter note C1 (middle C) and an eighth note D1 (D
607 On a microscopic scale, such syntax is easy to use. On a larger
608 scale, syntax also needs structure. How else can you enter
609 complex pieces like symphonies and operas? The structure is
610 formed by the concept of music expressions: by combining small
611 fragments of music into larger ones, more complex music can be
612 expressed. For example
614 @lilypond[quote,verbatim,fragment,relative=1]
619 Simultaneous notes can be constructed by enclosing them with
620 @code{<<} and @code{>>}:
626 @lilypond[quote,fragment,relative=1]
627 \new Voice { <<c4 d4 e>> }
631 This expression is put in sequence by enclosing it in curly braces
632 @code{@{@tie{}@dots{}@tie{}@}}:
635 @{ f4 <<c4 d4 e4>> @}
638 @lilypond[quote,relative=1,fragment]
643 The above is also an expression, and so it may be combined again
644 with another simultaneous expression (a half note) using
645 @code{<<}, @code{\\}, and @code{>>}:
648 << g2 \\ @{ f4 <<c4 d4 e4>> @} >>
651 @lilypond[quote,fragment,relative=2]
652 \new Voice { << g2 \\ { f4 <<c d e>> } >> }
655 Such recursive structures can be specified neatly and formally in
656 a context-free grammar. The parsing code is also generated from
657 this grammar. In other words, the syntax of LilyPond is clearly
658 and unambiguously defined.
660 User-interfaces and syntax are what people see and deal with most.
661 They are partly a matter of taste, and also subject of much
662 discussion. Although discussions on taste do have their merit,
663 they are not very productive. In the larger picture of LilyPond,
664 the importance of input syntax is small: inventing neat syntax is
665 easy, while writing decent formatting code is much harder. This
666 is also illustrated by the line-counts for the respective
667 components: parsing and representation take up less than 10% of
671 @node Example applications
672 @unnumberedsubsec Example applications
674 We have written LilyPond as an experiment of how to condense the
675 art of music engraving into a computer program. Thanks to all
676 that hard work, the program can now be used to perform useful
677 tasks. The simplest application is printing notes.
679 @lilypond[quote,relative=1]
687 By adding chord names and lyrics we obtain a lead sheet.
689 @lilypond[quote,ragged-right]
691 \chords { c2 c f2 c }
692 \new Staff \relative c' { \time 2/4 c4 c g'4 g a4 a g2 }
693 \new Lyrics \lyricmode { twin4 kle twin kle lit tle star2 }
697 Polyphonic notation and piano music can also be printed. The
698 following example combines some more exotic constructs.
702 title = "Screech and boink"
703 subtitle = "Random complex notation"
704 composer = "Han-Wen Nienhuys"
708 \context PianoStaff <<
713 \revert Stem #'direction
715 \set subdivideBeams = ##t
727 \set followVoice = ##t
728 c'''32([ b''16 a''16 gis''16 g''32)]
730 s4 \times 2/3 { d'16[ f' g'] } as'32[ b''32 e'' d'']
732 s4 \autoBeamOff d''8.. f''32
738 \new Staff = "down" {
741 \set subdivideBeams = ##f
742 \override Stem #'french-beaming = ##t
743 \override Beam #'thickness = #0.3
744 \override Stem #'thickness = #4.0
751 \override Staff.Arpeggio #'arpeggio-direction =#down
752 <cis, e, gis, b, cis>4\arpeggio
759 tempoWholesPerMinute = #(ly:make-moment 60 8)
765 \consists Horizontal_bracket_engraver
771 The fragments shown above have all been written by hand, but that
772 is not a requirement. Since the formatting engine is mostly
773 automatic, it can serve as an output means for other programs that
774 manipulate music. For example, it can also be used to convert
775 databases of musical fragments to images for use on websites and
776 multimedia presentations.
778 This manual also shows an application: the input format is text,
779 and can therefore be easily embedded in other text-based formats
780 such as @LaTeX{}, HTML, or in the case of this manual, Texinfo.
781 By means of a special program, the input fragments can be replaced
782 by music images in the resulting PDF or HTML output files. This
783 makes it easy to mix music and text in documents.
786 @node About the documentation
787 @section About the documentation
789 This section explains the different portions of the documentation.
791 @c leave these lines wrapping around. It's some texinfo 4.12 thing. -gp
793 * About the Learning Manual (LM):: this manual introduces LilyPond, giving in-depth explanations of how to create notation.
795 * About the Music Glossary (MG):: this manual explains musical terms and gives translations of terms in other languages.
797 * About the Notation Reference (NR):: this manual is the main portion of the documentation. It provides detailed information about creating notation. This book assumes that the reader knows basic material covered in the LM and is familiar with the English musical terms presented in the MG.
799 * About the Application Usage (AU):: this discusses the actual programs and operating system-specific issues.
801 * About the Snippet List (SL):: this is a collection of short LilyPond examples.
803 * About the Internals Reference (IR):: this document gives reference information about LilyPond's internal structures, which is required for constructing tweaks.
805 * Other documentation:: there are a few other portions of the documentation, such as News items and the mailist archives.
810 @node About the Learning Manual (LM)
811 @unnumberedsubsec About the Learning Manual (LM)
813 This book explains how to begin learning LilyPond, as well as
814 explaining some key concepts in easy terms. You should read these
815 chapters in a linear fashion.
820 @ref{Introduction}: explains the background and overall goal of
824 @ref{Tutorial}: gives a gentle introduction to typesetting music.
825 First time users should start here.
828 @ref{Fundamental concepts}: explains some general concepts about
829 the LilyPond file format. If you are not certain where to place a
830 command, read this chapter!
833 @ref{Tweaking output}: shows how to change the default engraving
834 that LilyPond produces.
837 @ref{Working on LilyPond projects}: discusses practical uses of
838 LilyPond and how to avoid some common problems. Read this before
839 undertaking large projects!
843 The LM also contains appendices which are not part of the
844 recommended linear reading. They may be useful for later
850 @ref{Templates}: shows ready-made templates of LilyPond pieces.
851 Just cut and paste a template into a file, add notes, and you're
855 @ref{Scheme tutorial}: presents a short introduction to Scheme,
856 the programming language that music functions use. This is
857 material for advanced tweaks; many users never touch Scheme at
863 @node About the Music Glossary (MG)
864 @unnumberedsubsec About the Music Glossary (MG)
869 @cindex foreign languages
872 @ref{Top,Music glossary,,music-glossary}:
873 this explains musical terms, and includes translations to various
874 languages. If you are not familiar with music notation or music
875 terminology (especially if you are a non-native English speaker),
876 it is highly advisable to consult the glossary.
879 @node About the Notation Reference (NR)
880 @unnumberedsubsec About the Notation Reference (NR)
882 This book explains all the LilyPond commands which produce
883 notation. It assumes that readers are familiar with the concepts
884 in the Learning manual.
889 @ruser{Musical notation}:
890 discusses topics grouped by notation construct. This section
891 gives details about basic notation that will be useful in almost
892 any notation project.
895 @ruser{Specialist notation}:
896 discusses topics grouped by notation construct. This section
897 gives details about special notation that will only be useful for
898 particular instrument (or vocal) groups.
901 @ruser{General input and output}:
902 discusses general information about LilyPond input files and
906 @ruser{Spacing issues}:
907 discusses issues which affect the global output, such as selecting
908 paper size or specifying page breaks.
911 @ruser{Changing defaults}:
912 explains how to tweak LilyPond to produce exactly the notation you
916 @ruser{Interfaces for programmers}:
917 explains how to create music functions with scheme.
921 The NR also contains appendices with useful reference charts.
926 @ruser{Literature list}:
927 contains a set of useful reference books for those who wish to
928 know more on notation and engraving.
931 @ruser{Notation manual tables}:
932 are a set of tables showing the chord names, MIDI instruments, a
933 list of color names, and the Feta font.
937 is a handy reference of the most common LilyPond commands.
940 @ruser{LilyPond command index}:
941 an index of all LilyPond @code{\commands}.
944 @ruser{LilyPond index}:
950 @node About the Application Usage (AU)
951 @unnumberedsubsec About the Application Usage (AU)
953 This book explains how to execute the program and how to integrate
954 LilyPond notation with other programs.
960 explains how to install LilyPond (including compilation if
965 describes how to configure your computer for optimum LilyPond
966 usage, such as using special environments for certain text
970 @rprogram{Running LilyPond}:
971 shows how to run LilyPond and its helper programs. In addition,
972 this section explains how to upgrade input files from previous
973 versions of LilyPond.
976 @rprogram{LilyPond-book}:
977 explains the details behind creating documents with in-line music
978 examples, like this manual.
981 @rprogram{Converting from other formats}:
982 explains how to run the conversion programs. These programs are
983 supplied with the LilyPond package, and convert a variety of music
984 formats to the @code{.ly} format.
989 @node About the Snippet List (SL)
990 @unnumberedsubsec About the Snippet List (SL)
995 @ref{Top,LilyPond Snippet List,,lilypond-snippets}: this shows a
996 selected set of LilyPond snippets from the
997 @uref{http://lsr@/.dsi@/.unimi@/.it,LilyPond Snippet Repository}
998 (LSR). All the snippets are in the public domain.
1000 Please note that this document is not an exact subset of LSR. LSR
1001 is running a stable LilyPond version, so any snippet which
1002 demonstrates new features of a development version must be added
1003 separately. These are stored in @file{input/new/} in the LilyPond
1006 The list of snippets for each subsection of the Notation Reference
1007 (NR) are also linked from the @strong{See also} portion.
1010 @node About the Internals Reference (IR)
1011 @unnumberedsubsec About the Internals Reference (IR)
1013 @ref{Top,Internals Reference,,lilypond-internals}: this is a set
1014 of heavily cross linked HTML pages which document the nitty-gritty
1015 details of each and every LilyPond class, object, and function.
1016 It is produced directly from the formatting definitions in the
1019 Almost all formatting functionality that is used internally is
1020 available directly to the user. For example, most variables that
1021 control thickness values, distances, etc., can be changed in input
1022 files. There are a huge number of formatting options, and all of
1023 them are described in this document. Each section of the Notation
1024 Reference has a @b{See also} subsection, which refers to the
1025 generated documentation. In the HTML document, these subsections
1026 have clickable links.
1029 @node Other documentation
1030 @unnumberedsubsec Other documentation
1032 There are a number of other sources of information which may be
1037 @item News: This is a summary of important changes
1038 and new features in LilyPond since the previous version.
1040 @item @uref{http://lists.gnu.org/archive/html/lilypond-user/, The
1041 lilypond-user mailist archives}: this is a collection of previous
1042 emails sent to the user list. Many questions have been asked
1043 multiple times; there is a very good chance that if you have a
1044 question, the answer might be found in these archives.
1046 @item @uref{http://lists.gnu.org/archive/html/lilypond-devel/, The
1047 lilypond-devel mailist archives}: this is a collection of previous
1048 emails sent to the developer's list. The discussion here is more
1049 technical; if you have an advanced question about lilypond
1050 internals, the answer might be in these archives.
1052 @item Embedded music fragments: in all HTML documents that have
1053 music fragments embedded, the exact LilyPond input that was used
1054 to produce that image can be viewed by clicking the image.
1056 @item Init files: The location of the documentation files that are
1057 mentioned here can vary from system to system. On occasion, this
1058 manual refers to initialization and example files. Throughout
1059 this manual, we refer to input files relative to the top-directory
1060 of the source archive. For example,
1061 @file{input/@/lsr/@/dirname/@/bla@/.ly} may refer to the file
1062 @file{lilypond@/2.x.y/@/input/@/lsr/@/dirname/@/bla@/.ly}. On
1063 binary packages for the UNIX platform, the documentation and
1064 examples can typically be found somewhere below
1065 @file{/usr/@/share/@/doc/@/lilypond/}. Initialization files, for
1066 example @file{scm/@/lily@/.scm}, or
1067 @file{ly/@/engraver@/-init@/.ly}, are usually found in the
1068 directory @file{/usr/@/share/@/lilypond/}.