-@c -*-texinfo-*-
+@c -*- coding: utf-8; mode: texinfo; -*-
+@c This file is part of lilypond.tely
@node Introduction
@chapter Introduction
-LilyPond is a program to print sheet music. If you have used notation
-programs before, then the way to use this program might be surprising
-at first sight. To print music with lilypond, you have to enter
-musical codes in a file. Then you run LilyPond on the file, and the
-music is produced without any further intervention. For example,
-something like this:
-
-@lilypond[fragment,verbatim, relative 1, intertext="produces this
-
-"]
-\key c \minor r8 c16 b c8 g as c16 b c8 d | g,4
-@end lilypond
-
-@cindex encoding music
-
-Encoding music using letters and digits may appear strange,
-intimidating or even clumsy at first. Nevertheless, when you take the
-effort to learn the codes and the program you will find that it is
-easier than it seems. Entering music can be done quickly, and you
-never have to remember how you made the program do something
-complicated: it is all in the input code, and you only have to read
-the file to see how it works. Moreover, when you use LilyPond, you are
-rewarded with very nicely looking output.
-
-In this chapter, we will explain the reasoning behind this unusual
-design, and how this approach affects you as a user.
@menu
-* Batch processing::
-* Music engraving::
+* Engraving::
+* Automated engraving::
+* What symbols to engrave?::
* Music representation::
-* Program design::
* Example applications::
* About this manual::
@end menu
-@node Batch processing
-@section Batch processing
-@cindex GUI
-@cindex Batch
-@cindex UNIX
+@node Engraving
+@section Engraving
+
+The art of music typography is called @emph{(plate) engraving}. The
+term derives from the traditional process of music printing. Just a
+few decades ago, sheet music was made by cutting and stamping the
+music into a zinc or pewter plate in mirror image. The plate would be
+inked, the depressions caused by the cutting and stamping would hold
+ink. An image was formed by pressing paper to the plate. The
+stamping and cutting was completely done by hand. Making a correction
+was cumbersome, if possible at all, so the engraving had to be perfect
+in one go. Engraving was a highly specialized skill; a craftsman had
+to complete around five years of training before earning the title of
+master engraver, and another five years of experience were
+necessary to become truly skilled.
+
+Nowadays, all newly printed music is produced with computers. This
+has obvious advantages; prints are cheaper to make, and editorial work
+can be delivered by email. Unfortunately, the pervasive use of
+computers has also decreased the graphical quality of scores.
+Computer printouts have a bland, mechanical look, which makes them
+unpleasant to play from.
+
+
+@c introduce illustrating aspects of engraving, font...
+The images below illustrate the difference between traditional
+engraving and typical computer output, and the third picture shows how
+LilyPond mimics the traditional look. The left picture shows a scan
+of a flat symbol from an edition published in 2000. The center
+depicts a symbol from a hand-engraved B@"{a}renreiter edition of the
+same music. The left scan illustrates typical flaws of computer
+print: the staff lines are thin, the weight of the flat symbol matches
+the light lines and it has a straight layout with sharp corners. By
+contrast, the B@"{a}renreiter flat has a bold, almost voluptuous
+rounded look. Our flat symbol is designed after, among others, this
+one. It is rounded, and its weight harmonizes with the thickness of
+our staff lines, which are also much thicker than lines in the
+computer edition.
+
+@multitable @columnfractions .125 .25 .25 .25 .125
+@item @tab
+@ifnotinfo
+@iftex
+@image{henle-flat-gray,,4cm}
+@end iftex
+@ifnottex
+@image{henle-flat-gray,,,png}
+@end ifnottex
+
+@tab
+@iftex
+@image{baer-flat-gray,,4cm}
+@end iftex
+@ifnottex
+@image{baer-flat-gray,,,png}
+@end ifnottex
+
+@tab
+@iftex
+@image{lily-flat-bw,,4cm}
+@end iftex
+@ifnottex
+@image{lily-flat-bw,,,png}
+@end ifnottex
+@end ifnotinfo
+@ifinfo
+@c workaround for makeinfo-4.6: line breaks and multi-column cookies
+@image{henle-flat-bw,,,png} @image{baer-flat-bw,,,png}
+@image{lily-flat-bw,,,png}
+@end ifinfo
+
+@item @tab
+Henle (2000)
+@tab
+B@"{a}renreiter (1950)
+@tab
+LilyPond Feta font (2003)
+
+@end multitable
+
+
+@cindex musical symbols
+@cindex font
+@cindex blackness
+@cindex balance
+
+@c introduce illustrating aspects of engraving, spacing...
+In spacing, the distribution of space should reflect the durations
+between notes. However, many modern scores adhere to the durations
+with mathematical precision, which leads to poor results. In the
+next example a motive is printed twice. It is printed once using
+exact mathematical spacing, and once with corrections. Can you
+spot which fragment is which?
+
+@cindex optical spacing
+@c file spacing-optical.
+@c need to include it here, because we want two images.
+@lilypond
+\paper {
+ ragged-right = ##t
+ indent = #0.0
+}
+
+music = {
+ c'4 e''4 e'4 b'4 |
+ \stemDown
+ b'8[ e'' a' e'']
+ \stemNeutral
+ e'8[ e'8 e'8 e'8]
+}
+
+\score
+{
+ \music
+ \layout {
+ \context {
+ \Staff
+ \override NoteSpacing #'stem-spacing-correction = #0.6
+ }
+ }
+}
+@end lilypond
+
+@lilypond
+\paper {
+ ragged-right = ##t
+ indent = #0.0
+}
+
+music = {
+ c'4 e''4 e'4 b'4 |
+ \stemDown
+ b'8[ e'' a' e'']
+ \stemNeutral
+ e'8[ e'8 e'8 e'8]
+}
+\score
+{
+ \music
+ \layout {
+ \context {
+ \Staff
+ \override NoteSpacing #'stem-spacing-correction = #0.0
+ \override NoteSpacing #'same-direction-correction = #0.0
+ \override StaffSpacing #'stem-spacing-correction = #0.0
+ }
+ }
+}
+@end lilypond
+
+@cindex regular rhythms
+@cindex regular spacing
+
+Each bar in the fragment only uses notes that are played in a
+constant rhythm. The spacing should reflect that. Unfortunately, the
+eye deceives us a little; not only does it notice the distance between
+note heads, it also takes into account the distance between
+consecutive stems. As a result, the notes of an up-stem/@/down-stem
+combination should be put farther apart, and the notes of a
+down-stem/@/up-stem
+combination should be put closer together, all depending on the
+combined vertical positions of the notes. The upper two measures are
+printed with this correction, the lower two measures without, forming
+down-stem/@/up-stem clumps of notes.
-When we started developing LilyPond, we were still studying at the
-university. We were interested in music notation, not as publishers
-or musicians, but as students and scientists. We wanted to figure to
-what extent formatting sheet music could be automated. Back then GUIs
-were not as ubiquitous as they are today, and we were immersed in the
-UNIX operating system, where it is very common to use compilers to
-achieve computing tasks, so our computerized music engraving
-experiment took on the form of a compiler.
+@cindex typography
+Musicians are usually more absorbed with performing than with studying
+the looks of a piece of music, so nitpicking about typographical details
+may seem academical. But it is not. In larger pieces with monotonous
+rhythms, spacing corrections lead to subtle variations in the layout
+of every line, giving each one a distinct visual signature. Without
+this signature all lines would look the same, and they become like a
+labyrinth. If a musician looks away once or has a lapse in
+concentration, the lines might lose their place on the page.
+
+Similarly, the strong visual look of bold symbols on heavy staff lines
+stands out better when the music is far away from the reader, for example,
+if it is on a music stand. A careful distribution of white space allows
+music to be set very tightly without cluttering symbols together. The
+result minimizes the number of page turns, which is a great advantage.
+
+This is a common characteristic of typography. Layout should be
+pretty, not only for its own sake, but especially because it helps the
+reader in her task. For performance material like sheet music, this is
+of double importance: musicians have a limited amount of attention. The
+less attention they need for reading, the more they can focus on
+playing the music. In other words, better typography translates to better
+performances.
+
+These examples demonstrate that music typography is an art that is
+subtle and complex, and that producing it requires considerable
+expertise, which musicians usually do not have. LilyPond is our
+effort to bring the graphical excellence of hand-engraved music to the
+computer age, and make it available to normal musicians. We have
+tuned our algorithms, font-designs, and program settings to produce
+prints that match the quality of the old editions we love to see and
+love to play from.
+
+
+
+
+@node Automated engraving
+@section Automated engraving
+
+How do we go about implementing typography? If craftsmen need over
+ten years to become true masters, how could we simple hackers ever
+write a program to take over their jobs?
+
+The answer is: we cannot. Typography relies on human judgment of
+appearance, so people cannot be replaced completely. However, much of
+the dull work can be automated. If LilyPond solves most of the common
+situations correctly, this will be a huge improvement over existing
+software. The remaining cases can be tuned by hand. Over the course
+of years, the software can be refined to do more and more things
+automatically, so manual overrides are less and less necessary.
+
+When we started, we wrote the LilyPond program entirely in the C++
+programming language; the program's functionality was set in stone by
+the developers. That proved to be unsatisfactory for a number of
+reasons:
+
+@itemize @bullet
+@item When LilyPond makes mistakes,
+users need to override formatting decisions. Therefore, the user must
+have access to the formatting engine. Hence, rules and settings cannot
+be fixed by us at compile-time but must be accessible for users at
+run-time.
+
+@item Engraving is a matter of visual judgment, and therefore a matter of
+taste. As knowledgeable as we are, users can disagree with our
+personal decisions. Therefore, the definitions of typographical style
+must also be accessible to the user.
+
+@item Finally, we continually refine the formatting algorithms, so we
+need a flexible approach to rules. The C++ language forces a certain
+method of grouping rules that do not match well with how music
+notation works.
+@end itemize
-@ignore
-@cindex free software
-@cindex sharing software
+These problems have been addressed by integrating an interpreter for
+the Scheme programming language and rewriting parts of LilyPond in
+Scheme. The current formatting architecture is built around the
+notion of graphical objects, described by Scheme variables and
+functions. This architecture encompasses formatting rules,
+typographical style and individual formatting decisions. The user has
+direct access to most of these controls.
+
+Scheme variables control layout decisions. For example, many
+graphical objects have a direction variable that encodes the choice
+between up and down (or left and right). Here you see two chords,
+with accents and arpeggios. In the first chord, the graphical objects
+have all directions down (or left). The second chord has all
+directions up (right).
+
+@lilypond[quote,ragged-right]
+\new Score \with {
+ \override SpacingSpanner #'spacing-increment = #3
+ \override TimeSignature #'transparent = ##t
+} \relative {
+ \stemDown <e g b>4_>-\arpeggio
+ \override Arpeggio #'direction = #RIGHT
+ \stemUp <e g b>4^>-\arpeggio
+}
+@end lilypond
-You can freely use, modify and redistribute LilyPond. This choice was
-also motivated by our academic background. In the scientific community
-it has always been a tradition to share knowledge, also if that
-knowledge was packaged as software. One of the most visible groups
-that stimulated this philosophy, was the Free Software Foundation,
-whose popular GNU project aimed to replace closed and proprietary
-computing solutions with free (as in ``Libre'') variants. We jumped on
-that bandwagon, and released LilyPond as free software. That is the
-reason that you can get LilyPond at no cost and without any strings
-attached.
-@end ignore
+@noindent
+The process of formatting a score consists of reading and writing the
+variables of graphical objects. Some variables have a preset value. For
+example, the thickness of many lines -- a characteristic of typographical
+style -- is a variable with a preset value. You are free to alter this
+value, giving your score a different typographical impression.
+
+@lilypond[quote,ragged-right]
+fragment = {
+ \clef bass f8 as8
+ c'4-~ c'16 as g f e16 g bes c' des'4
+}
+<<
+ \new Staff \fragment
+ \new Staff \with {
+ \override Beam #'thickness = #0.3
+ \override Stem #'thickness = #0.5
+ \override Bar #'thickness = #3.6
+ \override Tie #'thickness = #2.2
+ \override StaffSymbol #'thickness = #3.0
+ \override Tie #'extra-offset = #'(0 . 0.3)
+ }
+ \fragment
+>>
+@end lilypond
+Formatting rules are also preset variables: each object has variables
+containing procedures. These procedures perform the actual
+formatting, and by substituting different ones, we can change the
+appearance of objects. In the following example, the rule which note
+head objects are used to produce their symbol is changed during the music
+fragment.
+
+@lilypond[quote,ragged-right]
+#(set-global-staff-size 30)
+
+#(define (mc-squared grob orig current)
+ (let* ((interfaces (ly:grob-interfaces grob))
+ (pos (ly:grob-property grob 'staff-position)))
+ (if (memq 'note-head-interface interfaces)
+ (begin
+ (ly:grob-set-property! grob 'stencil ly:text-interface::print)
+ (ly:grob-set-property! grob 'font-family 'roman)
+ (ly:grob-set-property! grob 'text
+ (make-raise-markup -0.5
+ (case pos
+ ((-5) (make-simple-markup "m"))
+ ((-3) (make-simple-markup "c "))
+ ((-2) (make-smaller-markup (make-bold-markup "2")))
+ (else (make-simple-markup "bla")))))))))
+
+\new Voice \relative c' {
+ \stemUp
+ \set autoBeaming = ##f
+ \time 2/4
+ <d f g>4
+ \once \override NoteHead #'stencil = #ly:note-head::brew-ez-stencil
+ \once \override NoteHead #'font-size = #-7
+ \once \override NoteHead #'font-family = #'sans
+ \once \override NoteHead #'font-series = #'bold
+ <d f g>
+ \once \override NoteHead #'style = #'cross
+ <d f g>
+ \applyOutput #'Voice #mc-squared
+ <d f g>
+ <<
+ { d8[ es-( fis^^ g] fis2-) }
+ \repeat unfold 5 { \applyOutput #'Voice #mc-squared s8 }
+ >>
+}
+@end lilypond
-@node Music engraving
-@section Music engraving
+@node What symbols to engrave?
+@section What symbols to engrave?
@cindex engraving
@cindex typography
-Making sheet music may seem trivial at first (``you print 5 lines, and
-then put in the notes at different heights''), @emph{music engraving},
-i.e. professional music typography, is in another ballpark. The term
-`music engraving' derives from the traditional process of music
-printing. Only a few decades ago, sheet music was made by cutting and
-stamping the music into zinc or pewter plates, mirrored. The plate
-would be inked, and the depressions caused by the cutting and stamping
-would hold ink. A positive image was formed by pressing paper to the
-plate. Stamping and cutting was completely done by hand. Making
-corrections was cumbersome, so engraving had to be done correctly in
-one go. As you can imagine this was a highly specialized skill, much
-more so than the traditional process of printing books.
-@cindex craftsmanship
-@cindex master
-In the traditional German craftsmanship six years of full-time
-training, more than any other craft, were required before a student
-could call himself a master of the art. After that many more years of
-practical experience were needed to become an established music
-engraver. Even today, with the use of high-speed computers and
-advanced software, music requires lots of manual fine tuning before it
-acceptable to be published.
-
-When we wanted to write a computer program to do create music
-typography, we encountered the first problem: there were no sets of
-musical symbols available: either they were not available freely, or
-they did not look well to our taste. Not let down, we decided to try
-font design ourselves. We created a font of musical symbols, relying
-on nice printouts of hand-engraved music. The experience helped
-develop a typographical taste, and it made us appreciate subtle design
-details. Without that experience, we would not have realized how ugly
-the fonts were that we admired at first.
-
-
-@lilypond[noindent]
-#(define magfact 3.0)
-\score { \notes { as'2 r4 }
- \paper {
- linewidth = -1.
- \translator {
- \ScoreContext
- AccidentalPlacement \override #'right-padding = #3.0
- StaffSymbol \override #'transparent = ##t
- Clef \override #'transparent = ##t
- TimeSignature \override #'transparent = ##t
- Accidental \override #'font-magnification = #magfact
- Rest \override #'font-magnification = #magfact
- NoteHead \override #'font-magnification = #magfact
- Stem \override #'transparent = ##t
- } } }
+The formatting process decides where to place
+symbols. However, this can only be done once it is decided @emph{what}
+symbols should be printed, in other words what notation to use.
+
+Common music notation is a system of recording music that has evolved
+over the past 1000 years. The form that is now in common use dates
+from the early renaissance. Although the basic form (i.e., note heads on a
+5-line staff) has not changed, the details still evolve to express the
+innovations of contemporary notation. Hence, it encompasses some 500
+years of music. Its applications range from monophonic melodies to
+monstrous counterpoints for large orchestras.
+
+How can we get a grip on such a many-headed beast, and force it into
+the confines of a computer program? Our solution is to break up the
+problem of notation (as opposed to engraving, i.e., typography) into
+digestible and programmable chunks: every type of symbol is handled by
+a separate module, a so-called plug-in. Each plug-in is completely
+modular and independent, so each can be developed and improved
+separately. Such plug-ins are called @code{engraver}s, by analogy with
+craftsmen who translate musical ideas to graphic symbols.
+
+In the following example, we see how we start out with a plug-in for
+note heads, the @code{Note_heads_engraver}.
+
+@lilypond[quote,ragged-right]
+\include "engraver-example.ily"
+
+\score {
+ \topVoice
+ \layout {
+ \context {
+ \Voice
+ \remove "Stem_engraver"
+ \remove "Phrasing_slur_engraver"
+ \remove "Slur_engraver"
+ \remove "Script_engraver"
+ \remove "Beam_engraver"
+ \remove "Auto_beam_engraver"
+ }
+ \context {
+ \Staff
+ \remove "Accidental_engraver"
+ \remove "Key_engraver"
+ \remove "Clef_engraver"
+ \remove "Bar_engraver"
+ \remove "Time_signature_engraver"
+ \remove "Staff_symbol_engraver"
+ \consists "Pitch_squash_engraver"
+ }
+}
+}
@end lilypond
-@cindex musical symbols
-@cindex font
-@cindex blackness
-@cindex balance
-
-The figure above shows a few notable glyphs. For example, the
-half-notehead is not elliptic but slightly diamond shaped. The
-vertical stem of a flat symbol should be slightly brushed,
-i.e. becoming wider at the top. Fine endings, such as the one on the
-bottom of the quarter rest, should not end in sharp points, but rather
-in rounded shapes. Taken together, the blackness of the font must be
-carefully tuned together with the thickness of lines, beams and slurs
-to give a strong yet balanced overall impression.
-
-Producing a strong and balanced look is the real challenge of music
-engraving. It is a recurring theme with many variations. In spacing,
-the balance is in a distribution that reflects the character of the
-music. The spacing should not lead to unnatural clusters of black and
-big gaps with white space. The distances between notes should reflect
-the durations between notes, but adhering with mathematical precision
-to the duration will lead to a poor result. Shown here is an example
-of a motive, printed twice. It is printed using both exact,
-mathematical spacing, and with some corrections. Can you spot which is
-which?
+@noindent
+Then a @code{Staff_symbol_engraver} adds the staff
+
+@lilypond[quote,ragged-right]
+\include "engraver-example.ily"
+
+\score {
+ \topVoice
+ \layout {
+ \context {
+ \Voice
+ \remove "Stem_engraver"
+ \remove "Phrasing_slur_engraver"
+ \remove "Slur_engraver"
+ \remove "Script_engraver"
+ \remove "Beam_engraver"
+ \remove "Auto_beam_engraver"
+ }
+ \context {
+ \Staff
+ \remove "Accidental_engraver"
+ \remove "Key_engraver"
+ \remove "Clef_engraver"
+ \remove "Bar_engraver"
+ \consists "Pitch_squash_engraver"
+ \remove "Time_signature_engraver"
+ }
+ }
+}
+@end lilypond
+@noindent
+the @code{Clef_engraver} defines a reference point for the staff
+
+@lilypond[quote,ragged-right]
+\include "engraver-example.ily"
+
+\score {
+ \topVoice
+ \layout {
+ \context {
+ \Voice
+ \remove "Stem_engraver"
+ \remove "Phrasing_slur_engraver"
+ \remove "Slur_engraver"
+ \remove "Script_engraver"
+ \remove "Beam_engraver"
+ \remove "Auto_beam_engraver"
+ }
+ \context {
+ \Staff
+ \remove "Accidental_engraver"
+ \remove "Key_engraver"
+ \remove "Bar_engraver"
+ \remove "Time_signature_engraver"
+ }
+ }
+}
+@end lilypond
-@cindex optical spacing
-@lilypond[noindent]
- \score { \notes {
- \property Staff.NoteSpacing \set #'stem-spacing-correction
- = #0.6
- c'4 e''4 e'4 b'4 |
- \stemDown b'4 e''4 a'4 e''4| \stemBoth
- \property Staff.NoteSpacing \override #'stem-spacing-correction
- = #0.0
- \property Staff.StaffSpacing \override #'stem-spacing-correction
- = #0.0
- c'4 e''4 e'4 b'4 |
- \stemDown b'4 e''4 a'4 e''4|
+@noindent
+and the @code{Stem_engraver} adds stems.
+
+@lilypond[quote,ragged-right]
+\include "engraver-example.ily"
+
+\score {
+ \topVoice
+ \layout {
+ \context {
+ \Voice
+ \remove "Phrasing_slur_engraver"
+ \remove "Slur_engraver"
+ \remove "Script_engraver"
+ \remove "Beam_engraver"
+ \remove "Auto_beam_engraver"
+ }
+ \context {
+ \Staff
+ \remove "Accidental_engraver"
+ \remove "Key_engraver"
+ \remove "Bar_engraver"
+ \remove "Time_signature_engraver"
}
- \paper { linewidth = -1. } }
+ }
+}
@end lilypond
-@cindex regular rhythms
-@cindex regular spacing
+@noindent
+The @code{Stem_engraver} is notified of any note head coming along.
+Every time one (or more, for a chord) note head is seen, a stem
+object is created and connected to the note head. By adding
+engravers for beams, slurs, accents, accidentals, bar lines,
+time signature, and key signature, we get a complete piece of
+notation.
+
+@lilypond[quote,ragged-right]
+\include "engraver-example.ily"
+\score { \topVoice }
+@end lilypond
-The fragment that was printed uses only quarter notes: notes that are
-played in a constant rhythm. The spacing should reflect
-that. Unfortunately, the eye deceives us a little: the eye not only
-notices the distance between note heads, but also between consecutive
-stems. The notes of a up-stem/down-stem combination should be put
-farther apart, and the notes of a down-up combination should be put
-closer together, all depending on the combined vertical positions of
-the notes. The first two measures are printed with this correction,
-the last two measures without. The notes in the last two measures form
-downstem/upstems clumps of notes.
+This system works well for monophonic music, but what about
+polyphony? In polyphonic notation, many voices can share a staff.
-We hope that these examples show that music typography is a subtle
-business, and that it requires skill and knowledge to produce good
-engraving. It was our challenge to see if we could put such knowledge
-into a computer program.
+@lilypond[quote,ragged-right]
+\include "engraver-example.ily"
+\new Staff << \topVoice \\ \botVoice >>
+@end lilypond
+In this situation, the accidentals and staff are shared, but the stems,
+slurs, beams, etc., are private to each voice. Hence, engravers should
+be grouped. The engravers for note heads, stems, slurs, etc., go into a
+group called @q{Voice context,} while the engravers for key, accidental,
+bar, etc., go into a group called @q{Staff context.} In the case of
+polyphony, a single Staff context contains more than one Voice context.
+Similarly, multiple Staff contexts can be put into a single Score
+context. The Score context is the top level notation context.
+
+@seealso
+
+Program reference: @internalsref{Contexts}.
+
+@lilypond[quote,ragged-right]
+\include "engraver-example.ily"
+\score {
+ <<
+ \new Staff << \topVoice \\ \botVoice >>
+ \new Staff << \pah \\ \hoom >>
+ >>
+}
+@end lilypond
@node Music representation
@section Music representation
+Ideally, the input format for any high-level formatting system is an
+abstract description of the content. In this case, that would be the
+music itself. This poses a formidable problem: how can we define what
+music really is? Instead of trying to find an answer, we have reversed
+the question. We write a program capable of producing sheet music,
+and adjust the format to be as lean as possible. When the format can
+no longer be trimmed down, by definition we are left with content
+itself. Our program serves as a formal definition of a music
+document.
+
+The syntax is also the user-interface for LilyPond, hence it is easy
+to type
+
+@example
+c'4 d'8
+@end example
+
+@noindent
+a quarter note C1 (middle C) and an eighth note D1 (D above middle C)
+
+@lilypond[quote,fragment]
+c'4 d'8
+@end lilypond
+
+On a microscopic scale, such syntax is easy to use. On a larger
+scale, syntax also needs structure. How else can you enter complex
+pieces like symphonies and operas? The structure is formed by the
+concept of music expressions: by combining small fragments of music
+into larger ones, more complex music can be expressed. For example
+
+@lilypond[quote,verbatim,fragment,relative=1]
+c4
+@end lilypond
+
+@noindent
+Chords can be constructed with @code{<<} and @code{>>} enclosing the notes
+
+@c < > is not a music expression,
+@c so we use <<>> iso. <> to drive home the point of
+@c expressions. Don't change this back --hwn.
+@example
+<<c4 d4 e4>>
+@end example
+
+@lilypond[quote,fragment,relative=1]
+\new Voice { <<c4 d4 e>> }
+@end lilypond
+
+@noindent
+This expression is put in sequence by enclosing it in curly braces
+@code{@{@tie{}@dots{}@tie{}@}}
+
+@example
+@{ f4 <<c4 d4 e4>> @}
+@end example
+
+@lilypond[quote,relative=1,fragment]
+{ f4 <<c d e4>> }
+@end lilypond
+
+@noindent
+The above is also an expression, and so it may be combined
+again with another simultaneous expression (a half note) using <<,
+@code{\\}, and >>
+
+@example
+<< g2 \\ @{ f4 <<c4 d4 e4>> @} >>
+@end example
+
+@lilypond[quote,fragment,relative=2]
+\new Voice { << g2 \\ { f4 <<c d e>> } >> }
+@end lilypond
+
+Such recursive structures can be specified neatly and formally in a
+context-free grammar. The parsing code is also generated from this
+grammar. In other words, the syntax of LilyPond is clearly and
+unambiguously defined.
+
+User-interfaces and syntax are what people see and deal with
+most. They are partly a matter of taste, and also subject of much
+discussion. Although discussions on taste do have their merit, they
+are not very productive. In the larger picture of LilyPond, the
+importance of input syntax is small: inventing neat syntax is easy, while
+writing decent formatting code is much harder. This is also
+illustrated by the line-counts for the respective components: parsing
+and representation take up less than 10% of the source code.
-One of the big questions when making programs, is what kind of input
-the program should expect. Many music notation programs offer a
-graphical interface that shows notation, and allow you to enter the
-music by placing notes on a staff. From our point of view, this design
-is a form of cheating. After all, the core message of a piece of music
-notation simply is the music itself. If you start by offering notation
-to the user, you have already skipped one conversion, even if it is
-implicit. If we want to generate music notation from something else,
-then the obvious candidate for the source is the music itself.
-
-On paper this theory sounds very good. In practice, it opens a can of
-worms. What really @emph{is} music? Many philosophical treatises must
-have been written on the subject. Instead of losing ourselves in
-philosophical arguments over the essence of music, we have reversed
-the question to yield a more practical approach. Our assumption is
-that the printed score contains all of the music of piece. We build a
-program that uses some input format to produce such a score. Over the
-course of time, the program evolves. While this happens, we can remove
-more and more elements of the input format: as the program improves,
-it can fill in irrelevant details of the input by itself. At some
-(hypothetical) point, the program is finished: there is no possibility
-to remove any more elements from the syntax. What we have left is by
-definition exactly the musical meaning of the score.
-
-There are also more practical concerns. Our users have to key in the
-music into the file directly, so the input format should have a
-friendly syntax. As programmers and scientists, we want a
-clean formal definition. After all, producing music notation is a
-difficult problem, and in the scientific world, problems can only be
-solved if they are well-specified. Moreover, formally defined formats
-are easier to write programs for.
-
-
-These ideas shaped our music representation: it is a compact format
-that can easily be typed by hand. It complex musical constructs from
-simple entities like notes and rests, in much the same way that one
-builds complex formulas from simple expressions such as numbers and
-mathematical operators.
-
-@node Program design
-@section Program design
-
-The strict separation between musical information and typesetting also
-gives a blueprint of the program: first it reads the music
-representation, then it interprets the music---reading it
-`left-to-right', and translating the musical information to a layout
-specification. When the layout is computed, the resulting symbols are
-written to an output file.
-
-TODO: more about design?
@node Example applications
@section Example applications
-TODO: show what sort of things lily can be used for.
+We have written LilyPond as an experiment of how to condense the art
+of music engraving into a computer program. Thanks to all that hard
+work, the program can now be used to perform useful tasks. The
+simplest application is printing notes.
+
+@lilypond[quote,relative=1,fragment]
+\time 2/4 c4 c g'4 g a4 a g2
+@end lilypond
+
+@noindent
+By adding chord names and lyrics we obtain a lead sheet.
+
+@lilypond[quote,ragged-right]
+<<
+ \chords { c2 c f2 c }
+ \new Staff \relative c' { \time 2/4 c4 c g'4 g a4 a g2 }
+ \new Lyrics \lyricmode { twin4 kle twin kle lit tle star2 }
+>>
+@end lilypond
+
+Polyphonic notation and piano music can also be printed. The following
+example combines some more exotic constructs.
+
+@lilypondfile[quote,ragged-right]{screech-boink.ly}
+
+The fragments shown above have all been written by hand, but that is
+not a requirement. Since the formatting engine is mostly automatic, it
+can serve as an output means for other programs that manipulate
+music. For example, it can also be used to convert databases of
+musical fragments to images for use on websites and multimedia
+presentations.
+
+This manual also shows an application: the input format is text, and
+can therefore be easily embedded in other text-based formats such as
+La@TeX{}, HTML, or in the case of this manual, Texinfo. By means of a
+special program, the input fragments can be replaced by music images
+in the resulting PDF or HTML output files. This makes it easy
+to mix music and text in documents.
@node About this manual
@section About this manual
-[
+The manual is divided into the following chapters:
+@itemize @bullet
-The manual is divided into the following chapters
-@itemize
-@item Tutorial
-gives a gentle introduction into using lilypond
@item
-Reference manual: each aspect of typesetting music is discussed
+@ifhtml
+The
+@end ifhtml
+@emph{@ref{Tutorial}}
+gives a gentle introduction to typesetting music. First time
+users should start here.
+
@item
-Advanced topics: how it works from the inside, scripting lilypond.
+@emph{@ref{Putting it all together}}
+explains some general concepts about the lilypond file format. If
+you are not certain where to place a command, read this chapter!
+
@item
-Invoking: running LilyPond and its helper programs.
-@end itemize
+@emph{@ref{Working on LilyPond projects}}
+discusses practical uses of LilyPond and how to avoid some common
+problems.
-This manual is not complete: a part of the functionality is available
-through a generic system of properties: variables that can be set by
-the user to override certain functionality. Accompanying this manual
-is a document that describes all properties available, and all types
-of typographic and musical objects.
-
-TODO: rewrite rest of this section too.
-]
-
-As you will notice in the coming pages the program makes good
-decisions in a lot of cases: what comes out of LilyPond generally
-looks good. The default layout of lilypond even is suitable for
-publication for some specific files. However, some aspects of the
-formatting are not yet very good. For us programmers, this gives
-inspiration for improving the program. However, most users are more
-interested in improving their printouts, and then they have to make
-manual adjustments to the output. Another aspect of our system of
-encoding through ASCII then shows: it can be complicated to fine tune
-the layout of a piece. There is no graphical user interface, where you
-can simply click and drag a symbol. On the other hand, if you have
-written the code for tuning one specific aspect of the layout, then
-you can simply store the file on disk, retrieve it when you need it:
-there is no need to remember how you did it, since it is all in the
-input file.
+@item
+@emph{@ref{Tweaking output}}
+shows how to change the default engraving that LilyPond
+produces.
-@cindex snippets
-@cindex adjusting output
+@item
+@emph{@ref{Basic notation}}
+discusses topics grouped by notation construct. This section gives
+details about basic notation that will be useful in almost any
+notation project.
-Lilypond also comes with a huge collection of snippets that show all
-kinds of tricks. This collection is much needed, because of the way
-LilyPond is structured. It is a large program, but almost all of the
-internal functionality is exported: that is, the variables that are
-internally used for formatting the sheet music are available directly
-to the user. These are variables to control thicknesses, distances,
-and other formatting options. There are a huge number of them, and it
-would be impossible to describe them all in a hand-written
-manual. There is no need to despair, there is an `automatic' manual,
-that lists all of the variables that are available. It is directly
-generated from the definitions that LilyPond itself uses, so it is
-always up to date. If you are reading this from a screen: it is
-available from the web, and is included with most binary
-distributions. If you are reading this from paper, then we advise you
-to use the digital version anyway: the hyperlinks make finding topics
-in the lilypond-internals manual much easier.
+@item
+@emph{@ref{Instrument-specific notation}}
+discusses topics grouped by notation construct. This section gives
+details about special notation that will only be useful for particular
+instrument (or vocal) groups.
-@cindex variables
-@cindex properties
-@cindex lilypond-internals
-@cindex internal documentation
+@item
+@emph{@ref{Advanced notation}}
+discusses topics grouped by notation construct. This section gives
+details about complicated or unusual notation.
+
+@item
+@emph{@ref{Changing defaults}}
+explains how to fine tune layout.
-For those who really want to get their hands dirty: it is even
-possible to add your own functionality, by extending LilyPond in the
-built-in scripting language, a dialect of the powerful programming
-language Scheme. There is no real distinction between what a user can
-do and what a programmer is allowed to do.
+@item
+@emph{@ref{Non-musical notation}}
+discusses non-musical output such as titles, multiple movements,
+and how to select which MIDI instruments to use.
-@cindex Scheme
-@cindex extending lilypond
+@item
+@emph{@ref{Spacing issues}}
+discusses issues which affect the global output, such as selecting
+paper size or specifying page breaks.
+
+@item
+@emph{@ref{Interfaces for programmers}}
+explains how to create music functions.
+
+@item
+@emph{@ref{Running LilyPond}}
+shows how to run LilyPond and its helper
+programs. In addition, this section explains how to upgrade input
+files from previous versions of LilyPond.
+
+@item
+@emph{@ref{LilyPond-book}} explains the details behind creating
+documents with in-line music examples, like this manual.
+
+@item
+@emph{@ref{Converting from other formats}}
+explains how to run the conversion programs. These programs
+are supplied with the LilyPond package, and convert a variety of music
+formats to the @code{.ly} format.
+
+@item
+@ifhtml
+The
+@end ifhtml
+@emph{@ref{Literature list}}
+contains a set of useful reference books for those who wish to know
+more on notation and engraving.
+
+@item
+The
+@emph{@ref{Scheme tutorial}}
+presents a short introduction to scheme, the programming
+language that music functions use.
+
+@item
+@emph{@ref{Notation manual tables}}
+are a set of tables showing the chord names, MIDI instruments,
+a list of color names, and the Feta font.
+
+@item
+@emph{@ref{Example templates}}
+provides templates of LilyPond pieces. Just cut and paste a
+template into a file, add notes, and you're done!
+
+@item
+The
+@emph{@ref{Cheat sheet}}
+is a handy reference of the most common LilyPond commands.
+
+@item
+The
+@emph{@ref{LilyPond command index}}
+is an index of all LilyPond @code{\commands}.
+
+@item
+The
+@emph{@ref{LilyPond index}}
+is a complete index.
-In summary, this manual does not pretend to be exhaustive, but it is
-merely a guide that tries to explain the most important principles,
-and shows popular input idioms. The rest of the manual is structured
-as follows: it starts with a tutorial that explains how to use
-lilypond. In the tutorial, a number of fragments of increasing
-complexity are shown and explained. Then comes the reference manual,
-which gives more detailed information on all features. If you are new
-to lilypond, then you should start reading the tutorial, and
-experiment for yourself. If you already have some experience, then
-you can simply use the manual as reference: there is an extensive
-index@footnote{If you are looking for something, and you cannot find it
-by using the index, that is considered a bug. In that case, please
-file a bug report}, but the document is also available in One Big Page,
-@c should have hyperlink?
-which is is available for text search using your browser's search
-facility.
-
-@cindex searchin manual
+@end itemize
+
+
+Once you are an experienced user, you can use the manual as reference:
+there is an extensive index@footnote{If you are looking for something,
+and you cannot find it in the manual, that is considered a bug. In
+that case, please file a bug report.}, but the document is also
+available in
+@iftex
+a big HTML page,
+@end iftex
+@ifhtml
+@uref{source/Documentation/user/lilypond.html, one big page},
+@end ifhtml
+which can be searched easily using the search facility of a web
+browser.
+@cindex search in manual
@cindex using the manual
-@cindex bugreport
-@cindex index
-@cindex tutorial
-@cindex overview of manual
+
+@c FIXME:
+@c add/integrate glossary, put in list above
+If you are not familiar with music notation or music terminology
+(especially if you are a non-native English speaker), it is advisable
+to consult the glossary as well.
+@iftex
+The music glossary explains musical terms, and includes translations
+to various languages. It is a separate document, available in HTML
+and PDF.
+@end iftex
+@ifnottex
+The @ref{Top,Music glossary,,music-glossary}, explains musical terms and
+includes translations to various languages. It is also available in
+PDF.
+@end ifnottex
@cindex idiom
+@cindex jargon
+@cindex terminology
+@cindex foreign languages
+@cindex language
-[TODO: edit following]
-This is the end of the tutorial. If you read everything until this point
-(and understood everything!) then you are now an accomplished lilypond
-hacker. From here you should try fiddling with input files or making your
-own input files. Come back to the reference manual for more information
-if you get stuck!
+This manual is not complete without a number of other documents. They
+are not available in print, but should be included with the
+documentation package for your platform
-Do not forget to check out the
+@itemize @bullet
+@item
+@iftex
+Program reference
+@end iftex
+@ifnottex
+@ref{Top,Program reference,,lilypond-internals}.
+@end ifnottex
+
+The program reference is a set of heavily cross linked HTML pages,
+which document the nitty-gritty details of each and every LilyPond
+class, object, and function. It is produced directly from the
+formatting definitions used.
+
+Almost all formatting functionality that is used internally, is
+available directly to the user. For example, all variables that
+control thickness values, distances, etc., can be changed in input
+files. There are a huge number of formatting options, and all of them
+are described in this document. Each section of the
+notation manual has a @b{See also} subsection, which refers to the
+generated documentation. In the HTML document, these subsections
+have clickable links.
+
+@cindex snippets
+@item
+@ifnothtml
+Various input examples.
+@end ifnothtml
@ifhtml
-@uref{../../../../input/template/out-www/template.html,templates},
-@uref{../../../../input/test/out-www/test.html,examples} and
-@uref{../../../../input/regression/out-www/regression.html,feature tests}.
+@c Works, but link name is not so nice; so write-out macro
+@c @inputfileref{input/test,Various input examples}.
+@uref{source/input/test/collated-files.html,Various input examples}.
@end ifhtml
+
+This collection of files shows various tips and tricks, and is
+available as a big HTML document, with pictures and explanatory texts
+included.
+
+@item
@ifnothtml
-templates, examples and feature tests.
+The regression tests.
@end ifnothtml
-If you want to see real action LilyPond, head over to
-@uref{http://www.mutopiaproject.org}, which has many examples of
-classical music typeset with LilyPond.
+@ifhtml
+@c Works, but link name is not so nice; so write-out macro
+@c @inputfileref{input/regression,The regression tests}.
+@uref{source/input/regression/collated-files.html,The regression tests}.
+@end ifhtml
+
+This collection of files tests each notation and engraving feature of
+LilyPond in one file. The collection is primarily there to help us
+debug problems, but it can be instructive to see how we exercise the
+program. The format is similar to the tips and tricks document.
+@end itemize
+
+
+In all HTML documents that have music fragments embedded, the LilyPond
+input that was used to produce that image can be viewed by clicking
+the image.
+
+The location of the documentation files that are mentioned here can
+vary from system to system. On occasion, this manual refers to
+initialization and example files. Throughout this manual, we refer to
+input files relative to the top-directory of the source archive. For
+example, @file{input/@/test/@/bla@/.ly} may refer to the file
+@file{lilypond@/-2.8.0/@/input/@/test/@/bla@/.ly}. On binary packages
+for the Unix platform, the documentation and examples can typically be
+found somewhere below @file{/usr/@/share/@/doc/@/lilypond/}.
+Initialization files, for example @file{scm/@/lily@/.scm}, or
+@file{ly/@/engraver@/-init@/.ly}, are usually found in the directory
+@file{/usr/@/share/@/lilypond/}.
+
+@cindex adjusting output
+@cindex variables
+@cindex properties
+@cindex lilypond-internals
+@cindex internal documentation
+@cindex Scheme
+@cindex extending lilypond
+@cindex index
+
+Finally, this and all other manuals, are available online both as PDF
+files and HTML from the web site, which can be found at
+@uref{http://@/www@/.lilypond@/.org/}.
+
projects / lilypond.git / blobdiff