version that you are working on. See TRANSLATION for details.
@end ignore
+@c \version "2.11.38"
+
@ignore
Tutorial guidelines: (different from policy.txt!)
- unless you have a really good reason, use either
@menu
* Compiling a file::
* Simple notation::
-* Working on text files::
-* How to read the manual::
+* Working on input files::
+* How to read the manual::
@end menu
@node Compiling a file
@subsection Compiling a file
-@qq{Compiling} is the term used for processing an input text file
+@qq{Compiling} is the term used for processing an input file
in LilyPond format to produce a file which can be printed and
-(optionally) a MIDI file which can be played. The first example
-shows what a simple input text file looks like.
+(optionally) a MIDI file which can be played. LilyPond input
+files are simple text files. The first example
+shows what a simple input file looks like.
-To create sheet music, we write a text file that specifies the
+To create sheet music, we write an input file that specifies the
notation. For example, if we write:
@example
what LilyPond has done to the file. If any errors occur, please
examine this file.
-@subsubheading Unix
+@subsubheading UNIX
Create a text file called @file{test.ly} and enter:
works in practice. Starting from a B, which is on the middle line
in a treble clef, you can reach a C, D and E within 3 staff spaces
going up, and an A, G and F within 3 staff spaces going down. So
-if the note following a B is a C, D or F it will be assumed to be
+if the note following a B is a C, D or E it will be assumed to be
above the B, and an A, G or F will be assumed to be below.
@lilypond[verbatim,quote,ragged-right]
@ruser{Time signature}, @ruser{Clef}.
-@node Working on text files
-@subsection Working on text files
+@node Working on input files
+@subsection Working on input files
LilyPond input files are similar to source files in many common
programming languages. They are case sensitive, and white-space
@subsection How to read the manual
LilyPond input must be surrounded by @{ @} marks or a
-@code{\relative c'' @{ ... @}}, as we saw in @ref{Working on text
+@code{\relative c'' @{ ... @}}, as we saw in @ref{Working on input
files}. For the rest of this manual, most examples will omit
this. To replicate the examples, you may copy and paste the
displayed input but you @strong{must} add the @code{\relative c''
There are more tips for constructing input files in
-@ref{Suggestions for writing LilyPond files}. But it might be
+@ref{Suggestions for writing LilyPond input files}. But it might be
best to read through the rest of the tutorial first.
@cindex phrasing slurs
@subheading Phrasing slurs
-Music Glossary: @rglos{slurs}, @rglos{phrasing}.
+Music Glossary: @rglos{slur}, @rglos{phrasing}.
Slurs to indicate longer @notation{phrasing} can be entered with
@code{\(} and @code{\)}. You can have both @notation{slurs}
little) space there is at the beginning of a line, but indenting
LilyPond code like this makes it much easier for humans to read.
-@c FIXME: number of backslashes?! works in html but not pdf.
@warning{each note is relative to the previous note in
the input, not relative to the @code{c''} in the initial
-@code{\\relative} command.}
+@code{@bs{}relative} command.}
@subheading Simultaneous music expressions: single staff
Time signatures entered in one staff affects all other staves by
default. On the other hand, the key signature of one staff does
-@emph{not} affect other staves. This different default behaviour
+@emph{not} affect other staves. This different default behavior
is because scores with transposing instruments are more common
than polyrhythmic scores.
was used to write the file:
@example
-\version "2.11.38"
+\version @w{"@version{}"}
@end example
@noindent
underneath the @ref{Version number}.
@example
-\version "2.11.38"
+\version @w{"@version{}"}
\header @{
title = "Symphony"
composer = "Me"