Files of priority 1 should be submitted along all files generated by
starting a new language in the same commit and thus a unique patch, and
the translation of files marked with priority 2 should be committed to
-Git at the same time and thus sent in a single patch. Files
+Git at the same time and thus sent in a single patch. Files
marked with priority 3 or more may be submitted individually. Word
counts (excluding LilyPond snippets) are given for each file. For
knowing how to commit your work to Git, then make patches of your new
@enumerate
@item
-Tell us where the addition should be placed. Please include both
+Tell us where the addition should be placed. Please include both
the section number and title (i.e. "LM 2.13 Printing lyrics").
@item
@item
A formal patch to the source code is @emph{not} required; we can
-take care of the technical details. Here is an example of a
+take care of the technical details. Here is an example of a
perfect documentation report:
@verbatim
@subheading Larger contributions
To replace large sections of the documentation, the guidelines are
-stricter. We cannot remove parts of the current documentation
+stricter. We cannot remove parts of the current documentation
unless we are certain that the new version is an improvement.
@enumerate
@end enumerate
Once you have followed these guidelines, please send a message to
-lilypond-devel with your documentation submissions. Unfortunately
+lilypond-devel with your documentation submissions. Unfortunately
there is a strict “no top-posting” check on the mailing list; to avoid
this, add:
@item
Avoid long stretches of input code. Nobody is going to read
-them in print. Create small examples. However, this does not mean
+them in print. Create small examples. However, this does not mean
it has be minimal.
@item
@code{subscribe} and an empty message body. Unless mentioned explicitly,
or except if a translations coordinator contacts you privately, you
should send questions, remarks and patches to the list
-@code{translations@@lilynet.net}. Please note that traffic is high
+@code{translations@@lilynet.net}. Please note that traffic is high
on the English-speaking list @code{lilypond-user@@gnu.org}, so it may
take some time before your request or contribution is handled.
@@@var{section_commmand} @@translationof} trio mentioned above) in the
expected source file and define all its parent nodes; for each node you
have defined this way but have not translated, insert a line that
-contains @code{@@untranslated}. That is, you should end up
+contains @code{@@untranslated}. That is, you should end up
for each untranslated node with something like
@example
comments i.e. lines starting with @q{@code{@@c}}.
Finally, press in Emacs @key{C-c C-u C-a} to update or generate
-menus. This process should be made easier in the future, when the helper
+menus. This process should be made easier in the future, when the helper
script @command{texi-langutils.py} and the makefile target are updated.
Some pieces of text manipulated by build scripts that appear in the
@item
Checking all issues: we try to mark each Issue @q{fixed} when we
fix it, but occasionally one or two issues will slip through the
-cracks. It is therefore good to check all Issues. If you see the
+cracks. It is therefore good to check all Issues. If you see the
same (broken) output as the initial report, then simply post a
@qq{Problem still exists in 2.x.y} message to the issue.
begins.
Each type of music event has an associated iterator. Iterators are defined in
-*-iterator.cc. During iteration, an
+*-iterator.cc. During iteration, an
event's iterator is called to deliver that music event to the appropriate
context(s).
When making changes or fixing bugs in LilyPond, one of the initial
challenges is finding out where in the code tree the functions to
be modified live. With nearly 3000 files in the source tree,
-trial-and-error searching is generally ineffective. This section
+trial-and-error searching is generally ineffective. This section
describes a process for finding interesting code.
@subsection Using the ROADMAP
@node Indentation
@subsection Indentation
-Standard GNU coding style is used. In emacs:
+Standard GNU coding style is used. In emacs:
@verbatim
(add-hook 'c++-mode-hook
guide helping programmers writing consistent messages for all GNU
programs.
-Non-preferred messages are marked with `+'. By convention,
+Non-preferred messages are marked with `+'. By convention,
ungrammatical examples are marked with `*'. However, such ungrammatical
examples may still be preferred.
@item
Every message to the user should be localized (and thus be marked
-for localization). This includes warning and error messages.
+for localization). This includes warning and error messages.
@item
Do not localize/gettextify:
error (_f ("cannot open file: `%s'", file_name));
@end example
-In some rare cases you may need to call `gettext ()' by hand. This
+In some rare cases you may need to call `gettext ()' by hand. This
happens when you pre-define (a list of) string constants for later
-use. In that case, you'll probably also need to mark these string
-constants for translation, using `_i (STRING)'. The `_i' macro is
+use. In that case, you'll probably also need to mark these string
+constants for translation, using `_i (STRING)'. The `_i' macro is
a no-op, it only serves as a marker for `xgettext'.
@example
See also `flower/getopt-long.cc' and `lily/main.cc'.
@item
-Do not use leading or trailing whitespace in messages. If you need
+Do not use leading or trailing whitespace in messages. If you need
whitespace to be printed, prepend or append it to the translated
message
@end example
Messages containing a final verb, or a gerund (`-ing'-form) always
-start with a capital. Other (simpler) messages start with a
+start with a capital. Other (simpler) messages start with a
lowercase letter
@example
rather than `can't' or `don't'
To avoid having a number of different messages for the same
situation, well will use quoting like this `"message: `%s'"' for all
-strings. Numbers are not quoted:
+strings. Numbers are not quoted:
@example
_f ("cannot open file: `%s'", name_str)
@end example
@item
-Think about translation issues. In a lot of cases, it is better to
-translate a whole message. English grammar must not be imposed on the
-translator. So, instead of
+Think about translation issues. In a lot of cases, it is better to
+translate a whole message. English grammar must not be imposed on the
+translator. So, instead of
@example
stem at + moment.str () + does not fit in beam
@end example
@item
-Split up multi-sentence messages, whenever possible. Instead of
+Split up multi-sentence messages, whenever possible. Instead of
@example
warning (_f ("out of tune! Can't find: `%s'", "Key_engraver"));
@item
If you must have multiple-sentence messages, use full punctuation.
-Use two spaces after end of sentence punctuation. No punctuation
+Use two spaces after end of sentence punctuation. No punctuation
(esp. period) is used at the end of simple messages.
@example
@item
Do not modularize too much; words frequently cannot be translated
-without context. It is probably safe to treat most occurrences of
+without context. It is probably safe to treat most occurrences of
words like stem, beam, crescendo as separately translatable words.
@item
When translating, it is preferable to put interesting information
at the end of the message, rather than embedded in the middle.
This especially applies to frequently used messages, even if this
-would mean sacrificing a bit of eloquency. This holds for original
+would mean sacrificing a bit of eloquency. This holds for original
messages too, of course.
@example
The first nl message, although grammatically and stylistically
correct, is not friendly for parsing by humans (even if they speak
-dutch). I guess we would prefer something like (2) or (3).
+dutch). I guess we would prefer something like (2) or (3).
@item
Do not run make po/po-update with GNU gettext < 0.10.35
@section Tracing object relationships
Understanding the LilyPond source often boils down to figuring out what
-is happening to the Grobs. Where (and why) are they being created,
+is happening to the Grobs. Where (and why) are they being created,
modified and destroyed? Tracing Lily through a debugger in order to
identify these relationships can be time-consuming and tedious.
Joe Neeman answered:
We create lots of extra grobs (eg. a BarNumber at every bar line) but
-most of them are not drawn. See the break-visibility property in
+most of them are not drawn. See the break-visibility property in
item-interface.
@subheading Figuring out how things work.
I must admit that when I want to know how a program works, I use grep
-and emacs and dive into the source code. The comments and the code
+and emacs and dive into the source code. The comments and the code
itself are usually more revealing than technical documents.
@subheading What's a grob, and how is one used?
There are two other derived classes System (derived from Spanner,
containing a "line of music") and Paper_column (derived from Item, it
-contains all items that happen at the same moment). They are separate
+contains all items that happen at the same moment). They are separate
classes because they play a special role in the linebreaking process.
@subheading What's a smob, and how is one used?
Engravers
Executive branch of Contexts, plugins that create grobs, usually one
-engraver per grob type. Created together with context.
+engraver per grob type. Created together with context.
@item
Layout Objects
@item
Grob Interfaces
-These are not C++ classes per se. The idea of a Grob interface hasn't
-crystallized well. ATM, an interface is a symbol, with a bunch of grob
-properties. They are not objects that are created or destroyed.
+These are not C++ classes per se. The idea of a Grob interface hasn't
+crystallized well. ATM, an interface is a symbol, with a bunch of grob
+properties. They are not objects that are created or destroyed.
@item
Iterators
@subheading Can you get to Context properties from a Music object?
You can create music object with a Scheme function that reads context
-properties (the \applycontext syntax). However, that function is
+properties (the \applycontext syntax). However, that function is
executed during Interpreting, so you can not really get Context
properties from Music objects, since music objects are not directly
-connected to Contexts. That connection is made by the Music_iterators
+connected to Contexts. That connection is made by the Music_iterators
@subheading Can you get to Music properties from a Context object?
Yes, if you are given the music object within a Context
-object. Normally, the music objects enter Contexts in synchronized
+object. Normally, the music objects enter Contexts in synchronized
fashion, and the synchronization is done by Music_iterators.
@subheading What is the relationship between C++ classes and Scheme objects?
-Smobs are C++ objects in Scheme. Scheme objects (lists, functions) are
+Smobs are C++ objects in Scheme. Scheme objects (lists, functions) are
manipulated from C++ as well using the GUILE C function interface
(prefix: scm_)
Good question. Things used to be clear-cut, but we have Scheme
and SMOBs now, which means that interactions do not follow a very
-rigid format anymore. See below for an overview, though.
+rigid format anymore. See below for an overview, though.
@subheading Does the parser make Scheme procedure calls or C++ function calls?
-Both. And the Scheme calls can call C++ and vice versa. It's nested,
+Both. And the Scheme calls can call C++ and vice versa. It's nested,
with the SCM datatype as lubrication between the interactions
(I think the word "lubrication" describes the process better than the
@subheading How do the front-end and back-end get started?
-Front-end: a file is parsed, the rest follows from that. Specifically,
+Front-end: a file is parsed, the rest follows from that. Specifically,
Parsing leads to a Music + Music_output_def object (see parser.yy,
definition of toplevel_expression )
Contexts (see Global_translator::run_iterator_on_me ()).
After interpreting, Global_context contains a Score_context (which
-contains staves, lyrics etc.) as a child. Score_context::get_output ()
+contains staves, lyrics etc.) as a child. Score_context::get_output ()
spews a Music_output object (either a Paper_score object for notation
or Performance object for MIDI).
@end itemize
Interactions between grobs and putting things into .tex and .ps files
-have gotten a little more complex lately. Jan has implemented
+have gotten a little more complex lately. Jan has implemented
page-breaking, so now the backend also involves Paper_book,
-Paper_lines and other things. This area is still heavily in flux, and
+Paper_lines and other things. This area is still heavily in flux, and
perhaps not something you should want to look at.
@subheading How do the front-end and back-end communicate?
-There is no communication from backend to front-end. From front-end to
+There is no communication from backend to front-end. From front-end to
backend is simply the program flow: music + definitions gives
contexts, contexts yield output, after processing, output is written
to disk.
Engravers and Contexts
Music_iterators can send "synthetic" music events (which aren't in
-the input) to a context. These are caught by Engravers. This is
+the input) to a context. These are caught by Engravers. This is
mostly a one way communication channel.
part-combine-status is part of such a synthetic event, used by
a Music property?
\autochange is one of these extra strange beasts: it requires
-look-ahead to decide when to change staves. This is achieved by
+look-ahead to decide when to change staves. This is achieved by
running the interpreting step twice (see scm/part-combiner.scm , at
the bottom), and storing the result of the first step (where to switch
staves) in a Music property. Since you want to influence that
where-to-switch list, your must affect the code in
-make-autochange-music (scm/part-combiner.scm). That code is called
+make-autochange-music (scm/part-combiner.scm). That code is called
directly from the parser and there are no official "parsing
-properties" yet, so there is no generic way to tune \autochange. We
+properties" yet, so there is no generic way to tune \autochange. We
would have to invent something new for this, or add a separate
argument,
first place. I only know a little bit about Flex and Bison, so reading those
files helped only a little bit.
-@emph{Han-Wen:} GDB can be of help here. Set a breakpoint in C++, and run. When you
-hit the breakpoint, do a backtrace. You can inspect Scheme objects
+@emph{Han-Wen:} GDB can be of help here. Set a breakpoint in C++, and run. When you
+hit the breakpoint, do a backtrace. You can inspect Scheme objects
along the way by doing
@example
Before release:
-* write release notes. note: stringent size requirements for
+* write release notes. note: stringent size requirements for
various websites, so be brief.
* write preface section for manual.
@example
-# Please enter the commit message for your changes. Lines starting
+# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
@subsection Git GUI
Almost all subsequent work will use the Git Graphical User
-Interface, which avoids having to type command line commands. To
+Interface, which avoids having to type command line commands. To
start Git GUI first start the Git bash shell by clicking on the
desktop icon, and type
while the newer edition seems cold and mechanical.
It is hard to immediately see what makes the difference with the newer
-edition. Everything looks neat and tiny, possibly even @qq{better}
-because it looks more computerized and uniform. This really puzzled us
-for quite a while. We wanted to improve computer notation, but we first
+edition. Everything looks neat and tiny, possibly even @qq{better}
+because it looks more computerized and uniform. This really puzzled us
+for quite a while. We wanted to improve computer notation, but we first
had to figure out what was wrong with it.
The answer lies in the precise, mathematical uniformity of the newer
There are other differences as well: in the hand-engraved edition the
vertical lines are all stronger, the slurs lie closer to the note heads,
-and there is more variety in the slopes of the beams. Although such
+and there is more variety in the slopes of the beams. Although such
details may seem like nitpicking, the result is a score that is easier
-to read. In the computer-generated output, each line is nearly identical
+to read. In the computer-generated output, each line is nearly identical
and if the musician looks away for a moment she will be lost on the
page.
The spacing algorithms in LilyPond even take the barlines into account,
which is why the final up-stem in the properly spaced example has been
given a little more space before the barline to keep it from looking
-crowded. A down-stem would not need this adjustment.
+crowded. A down-stem would not need this adjustment.
@node Ledger lines
@unnumberedsubsec Ledger lines
choose the least ugly configuration.
For example, here are three possible slur configurations, and LilyPond
-has given each one a score in @q{ugly points}. The first example gets
+has given each one a score in @q{ugly points}. The first example gets
15.39 points for grazing one of the noteheads:
@lilypond
the subject returns in a three-part stretto and leads into the closing
section. In the Finale version, we have resisted the temptation to make
any adjustments to the default output because we are trying to show the
-things that each software package gets right without assistance. The
+things that each software package gets right without assistance. The
only major edits that we made were adjusting the page size to match this
essay and forcing the music onto two systems to make the comparison
-easier. By default Finale would have engraved two systems of three
+easier. By default Finale would have engraved two systems of three
measures each and a final, full-width system containing a single
measure.
@end itemize
This example is not intended to suggest that Finale cannot be used to
-produce publication-quality output. On the contrary, in the hands of a
-skilled user it can and does, but it requires skill and time. One of the
+produce publication-quality output. On the contrary, in the hands of a
+skilled user it can and does, but it requires skill and time. One of the
fundamental differences between LilyPond and commercial scorewriters is
that LilyPond hopes to reduce the amount of human intervention to an
absolute minimum, while other packages try to provide an attractive
If you are interested in examining these examples in more detail, the
full seven-measure excerpt can be found at the end of this essay along
-with four different published engravings. Close examination reveals that
+with four different published engravings. Close examination reveals that
there is some acceptable variation among the hand-engravings, but that
-LilyPond compares reasonably well to that acceptable range. There are
+LilyPond compares reasonably well to that acceptable range. There are
still some shortcomings in the LilyPond output, for example, it appears
a bit too aggressive in shortening some of the stems, so there is room
for further development and fine-tuning.
the source code.
When designing the structures used in LilyPond, we made some different
-decisions than are apparent in other software. Consider the hierarchical
+decisions than are apparent in other software. Consider the hierarchical
nature of music notation:
@lilypond[quote,fragment]
here, the @code{box-padding} values are hard coded, and cannot be
changed by the user. Also, it would be better to distinguish the
padding between the two boxes, from the padding between the inner box
-and the text. So we will introduce a new property,
-@code{inter-box-padding}, for the padding between the two boxes. The
+and the text. So we will introduce a new property,
+@code{inter-box-padding}, for the padding between the two boxes. The
@code{box-padding} will be used for the inner padding. The new code is
now as follows:
@uref{http://@/www@/.schemers@/.org}.
LilyPond uses the GNU Guile implementation of Scheme, which is
-based on the Scheme @qq{R5RS} standard. If you are learning Scheme
+based on the Scheme @qq{R5RS} standard. If you are learning Scheme
to use with LilyPond, working with a different implementation (or
-referring to a different standard) is not recommended. Information
+referring to a different standard) is not recommended. Information
on guile can be found at @uref{http://www.gnu.org/software/guile/}.
The @qq{R5RS} Scheme standard is located at
@uref{http://www.schemers.org/Documents/Standards/R5RS/}.
opening a terminal window and typing @q{guile}. On some systems,
notably Windows, you may need to set the environment variable
@code{GUILE_LOAD_PATH} to the directory @code{../usr/shr/guile/1.8}
-in the LilyPond installation. For the full path to this directory
+in the LilyPond installation. For the full path to this directory
see @rlearning{Other sources of information}. Alternatively, Windows
users may simply choose @q{Run} from the Start menu and enter
@q{guile}.
\header {
texidoc = " Chord names are generated from a list pitches. The
-functions which construct these names can be customised. Here are shown
+functions which construct these names can be customised. Here are shown
Jazz chords, following Ignatzek (pp. 17-18, 1995) and
an alternative Jazz chord notation.
First, install the relevant dependencies using MacPorts.
Next, add the following to your relevant shell initialization
-files. This is @code{~/.profile} by default. You should create
+files. This is @code{~/.profile} by default. You should create
this file if it does not exist.
@example
@end example
At this point, you should verify that you have the appropriate
-fonts installed with your ghostscript installation. Check @code{ls
+fonts installed with your ghostscript installation. Check @code{ls
/opt/local/share/ghostscript/fonts} for: 'c0590*' files (.pfb,
.pfb and .afm). If you don't have them, run the following
commands to grab them from the ghostscript SVN server and install
rm -rf urw-fonts-1.07pre44
@end example
-Now run the @code{./configure} script. To avoid complications with
+Now run the @code{./configure} script. To avoid complications with
automatic font detection, add
@example
It can be useful to have both the stable and the development versions
-of Lilypond available at once. One way to do this on GNU/Linux is to
+of Lilypond available at once. One way to do this on GNU/Linux is to
install the stable version using the precompiled binary, and run the
-development version from the source tree. After running @command{make
+development version from the source tree. After running @command{make
all} from the top directory of the Lilypond source files, there will
be a binary called @code{lilypond} in the @code{out} directory:
@end example
This binary can be run without actually doing the @code{make
-install} command. The advantage to this is that you can have all
+install} command. The advantage to this is that you can have all
of the latest changes available after pulling from git and running
@code{make all}, without having to uninstall the old version and
reinstall the new.
Since it is not possible to compile Lilypond on Windows, some
developers may find it useful to install a GNU/Linux virtual
-machine. A disk image with a special remix of @strong{Ubuntu}
-has been created for this purpose. It has all of the Lilypond
+machine. A disk image with a special remix of @strong{Ubuntu}
+has been created for this purpose. It has all of the Lilypond
build dependencies in place, so that once installed, it is
ready to compile both Lilypond and the Documentation.
The @code{lilybuntu} remix is available for download here:
We do not necessarily recommend any one virtualization tool,
however the @code{lilybuntu} remix is known to work well on
@uref{http://www.virtualbox.org/wiki/Downloads, Sun VirtualBox},
-which is a free download. Consult your virtualization software's
+which is a free download. Consult your virtualization software's
documentation for instructions on setting up the software and
for general instructions on installing a virtual machine.
@enumerate
@item Download the @code{lilybuntu} disk image.
-@item Install @code{lilybuntu}. You will use the @code{.iso}
-file as the boot disk. It should not be necessary to burn it
+@item Install @code{lilybuntu}. You will use the @code{.iso}
+file as the boot disk. It should not be necessary to burn it
to a DVD, but consult the documentation for your virtualization
-software for specific instructions. If possible, use at least
+software for specific instructions. If possible, use at least
the recommended amount of RAM for the virtual machine (384 MB on
VirtualBox), and use a dynamically expanding virtual hard drive.
A virtual hard drive with 6 GB will be enough to compile LilyPond,
Edit local.make for local Makefile overrides.
@end example
-@item First type @code{make all} to build Lilypond. This will take
+@item First type @code{make all} to build Lilypond. This will take
a while.
@item When Lilypond is finished building, build the documentation
@sourceimage{Learning_Win7_Welcome_File_Whole,,,}
From the menus that appear along the top of the example file,
-select @w{@code{File > Save as}}. Do not use the @w{@code{File > Save}}
+select @w{@code{File > Save as}}. Do not use the @w{@code{File > Save}}
for the example file as this will not work until you have given it a
valid LilyPond file name.
@subsubheading Step 3. View output
During the compilation of the @file{test.ly} file, a command window
-will, very briefly open and then close. Three additional files will
+will, very briefly open and then close. Three additional files will
have been created during this process.
@sourceimage{Learning_Win7_All_Files_Created,,,}
This log file is overwritten each time you compile your LilyPond file.
The PS file is used internally by LilyPond to create the PDF file and
-can be ignored. It also gets overwritten each time you compile your
+can be ignored. It also gets overwritten each time you compile your
file.
If you are viewing your file in a PDF viewer, then you must close the
Polyphonic music in lilypond, while not difficult, uses concepts
that we haven't discussed yet, so we're not going to introduce
-them here. Instead, the following sections introduce these concepts
+them here. Instead, the following sections introduce these concepts
and explain them thoroughly.
@seealso
@end lilypond
It is not necessary to use a separate @code{<< \\ >>} construct
-for each bar. For music with few notes in each bar this layout
+for each bar. For music with few notes in each bar this layout
can help the legibility of the code, but if there are many
notes in each bar it may be better to split out each voice
separately, like this:
voices downward ones. The stems for voices 1 and 2 are right,
but the stems in voice 3 should go down in this particular piece
of music. We can correct this by skipping voice three
-and placing the music in voice four. This is done by simply
+and placing the music in voice four. This is done by simply
adding another pair of @code{\\}.
@lilypond[quote,verbatim,fragment,ragged-right]
in opposite directions, but the notes from the third and fourth voices
are displaced, if necessary, to avoid the note heads colliding. This
usually works well, but in this example the notes of the lowest voice
-are clearly not well placed by default. LilyPond provides several ways
+are clearly not well placed by default. LilyPond provides several ways
to adjust the horizontal placing of notes. We are not quite ready yet
to see how to correct this, so we shall leave this problem until a
later section --- see the @code{force-hshift} property in @ref{Fixing
The @code{\shiftOn}, @code{\shiftOnn}, @code{\shiftOnnn}, and
@code{\shiftOff} commands specify the degree to which notes and
chords of the voice should be shifted if a collision
-would otherwise occur. By default, the outer voices (normally
+would otherwise occur. By default, the outer voices (normally
voices one and two) have @code{\shiftOff} specified, while the
inner voices (three and four) have @code{\shiftOn} specified.
When a shift is applied, voices one and three are shifted to
Line thickness, generally measured in @code{line-thickness}
@end example
-This looks a good bet to change the heaviness. It tells us that
+This looks a good bet to change the heaviness. It tells us that
the value of @code{thickness} is a simple @emph{number},
that the default value is 1.2, and that the units are
in another property called @code{line-thickness}.
@code{outside-staff-priority}. The outside-staff objects are
taken one by one, beginning with the object with the lowest
@code{outside-staff-priority}, and placed so that they do not
-collide with any objects that have already been placed. That is,
+collide with any objects that have already been placed. That is,
if two outside-staff grobs are competing for the same space, the
one with the lower @code{outside-staff-priority} will be placed
closer to the staff. If two objects have the same
@cindex rehearsal marks, tweaking placement
Note that bar numbers, metronome marks and rehearsal marks are not
-shown. By default these are created in the @code{Score} context and
+shown. By default these are created in the @code{Score} context and
their @code{outside-staff-priority} is ignored relative to the layout
objects which are created in the @code{Staff} context. If you wish to
place bar numbers, metronome marks or rehearsal marks in accordance
@end example
We will refer to this file using the @code{\include} command near
-the top of the music file. (The extension @code{.ily} is used to
+the top of the music file. (The extension @code{.ily} is used to
distinguish this included file, which is not meant to be compiled
on its own, from the main file.)
Now let's modify our music (let's save this file as @file{"music.ly"}).
FI: kohotahti.
An anacrusis (also known as pickup or upbeat) is an incomplete measure
-of music before a section of music. It also refers to the initial
+of music before a section of music. It also refers to the initial
note(s) of a melody occurring in that incomplete measure.
@lilypond[quote,relative=1]
@item Music prepared for photoreproduction by freehand drawing, with
the aid of a straightedge ruler and T-square only, which attempts to
-emulate engraving. This required more skill than did engraving.
+emulate engraving. This required more skill than did engraving.
@end itemize
S: balk,
FI: palkki.
-Line connecting a series of notes (shorter than a quarter note). The
+Line connecting a series of notes (shorter than a quarter note). The
number of beams determines the note value of the connected notes.
@lilypond[quote,notime,relative=2,line-width=13\cm]
FI: sointu.
Three or more tones sounding simultaneously. In traditional European music
-the base chord is a @emph{triad} consisting of two thirds. @emph{Major}
+the base chord is a @emph{triad} consisting of two thirds. @emph{Major}
(major + minor third) as well as @emph{minor} (minor + major third) chords
-may be extended with more thirds. Four-tone @emph{seventh chords} and
+may be extended with more thirds. Four-tone @emph{seventh chords} and
five-tone @emph{ninth} major chords are most often used as dominants
(functional harmony). Chords having no third above the lower notes to
define their mood are a special case called @q{open chords}. The lack of
Staves of five lines are usually used, and the clef superimposed on them
indicates which five lines have been selected from this @notation{grand
-staff}. For example, the treble or G clef indicates that the top five lines
+staff}. For example, the treble or G clef indicates that the top five lines
have been selected:
@lilypond[quote]
S: diatonisk skala,
FI: diatoninen asteikko.
-A scale consisting of 5@w{ }whole tones and 2@w{ }semitones (S). Scales
+A scale consisting of 5@w{ }whole tones and 2@w{ }semitones (S). Scales
played on the white keys of a piano keyboard are diatonic. These scales
are sometimes called, somewhat inaccurately, @q{church modes}).
FI: käännös.
When a chord sounds with a bass note that differs from the root of the
-chord, it is said to be @emph{inverted}. The number of inversions that a
+chord, it is said to be @emph{inverted}. The number of inversions that a
chord can have is one fewer than the number of constituent notes. For
example, triads (which have three constituent notes) can have three
positions, two of which are inversions:
@table @dfn
@item Root position
-The root note is in the bass, and above that are the third and the fifth. A
+The root note is in the bass, and above that are the third and the fifth. A
triad built on the first scale degree, for example, is marked @notation{I}.
@item First inversion
-The third is in the bass, and above it are the fifth and the root. This
+The third is in the bass, and above it are the fifth and the root. This
creates an interval of a sixth and a third above the bass note, and so is
-marked in figured Roman notation as @notation{6/3}. This is commonly
+marked in figured Roman notation as @notation{6/3}. This is commonly
abbreviated to @notation{I6} (or @notation{Ib}) since the sixth is the
characteristic interval of the inversion, and so always implies
@notation{6/3}.
@item Second inversion
-The fifth is in the bass, and above it are the root and the third. This
+The fifth is in the bass, and above it are the root and the third. This
creates an interval of a sixth and a fourth above the bass note, and so is
-marked as @notation{I6/4} or @notation{Ic}. Second inversion is the most
+marked as @notation{I6/4} or @notation{Ic}. Second inversion is the most
unstable chord position.
@end table
FI: antaa väristä.
[French: @q{Let vibrate}] Most frequently associated with harp
-parts. Marked @notation{l.v.} in the score.
+parts. Marked @notation{l.v.} in the score.
@seealso
No cross-references.
FI: largo, hitaasti, leveästi.
[Italian: @q{wide}.] Very slow in tempo, usually combined with great
-expressiveness. @emph{Larghetto} is less slow than largo.
+expressiveness. @emph{Larghetto} is less slow than largo.
@node leading note
Multi-measure rests are conventionally typeset with a combination of
longa, breve and whole rests for shorter and a long horizontal bar for
longer spans of rest, with a number above to indicate the duration (in
-measures) of the rest. The former style is called @q{Kirchenpausen} in
+measures) of the rest. The former style is called @q{Kirchenpausen} in
German, as a reminiscence of its use in Renaissance vocal polyphony.
@lilypond[quote,relative=2]
[Italian: past participle of @emph{portare}, @q{to carry}]
A stroke in which each of several notes is separated slightly within a slur,
-without changing the bow's direction. It is used for passages of a
+without changing the bow's direction. It is used for passages of a
@notation{cantabile} character.
@seealso
intervals. Tertian triads can be described as a series of three notes. The
first element is the root note (or simply @q{root}) of the chord, the second
note is the @q{third} of the chord, and the last note is the @q{fifth} of
-the chord. These are described below:
+the chord. These are described below:
@multitable {Chord name} {Component intervals} {Example} {C, CM, Cma, Cmaj, CΔ}
@headitem Chord name
There are various types of seventh chords depending on the quality of the
original chord and the quality of the seventh added.
-Five common types of seventh chords have standard symbols. The chord quality
+Five common types of seventh chords have standard symbols. The chord quality
indications are sometimes superscripted and sometimes not (e.g. Dm7, Dm^7,
-and D^m7 are all identical). The last three chords are not commonly used
+and D^m7 are all identical). The last three chords are not commonly used
except in jazz.
@seealso
@node Score - the master of all contexts
@unnumberedsubsubsec Score - the master of all contexts
-This is the top level notation context. No other context can
-contain a Score context. By default the Score context handles
+This is the top level notation context. No other context can
+contain a Score context. By default the Score context handles
the administration of time signatures and makes sure that items
such as clefs, time signatures, and key-signatures are aligned
across staves.
@strong{@emph{StaffGroup}}
Groups staves while adding a bracket on the left side, grouping
-the staves together. The bar lines of the contained staves are
+the staves together. The bar lines of the contained staves are
connected vertically. @code{StaffGroup} only consists of a collection
of staves, with a bracket in front and spanning bar lines.
Chords entered using chord mode are music elements, and can be
transposed just like chords entered using simultaneous music.
@code{\chordmode} is absolute, as @code{\relative} has no effect
-on @code{chordmode} blocks. However, in @code{\chordmode} the
+on @code{chordmode} blocks. However, in @code{\chordmode} the
absolute pitches are one octave higher than in note mode.
Chord mode and note mode can be mixed in sequential music:
@item majorSevenSymbol
This property contains the markup object used to follow the output
-of @code{chordRootNamer} to identify a major 7 chord. Predefined
+of @code{chordRootNamer} to identify a major 7 chord. Predefined
options are @code{whiteTriangleMarkup} and
@code{blackTriangleMarkup}.
When the chord name contains additional pitches other than the root
(e.g., an added bass note), this function is used to print the
additional pitch. By default the pitch is printed using
-@code{chordRootNamer}. The @code{chordNoteNamer} property can be set
+@code{chordRootNamer}. The @code{chordNoteNamer} property can be set
to a specialized function to change this behavior. For example, the
bass note can be printed in lower case.
c2 <c \parenthesize e g>
@end lilypond
-Non-note objects may be parenthesized as well. For articulations,
+Non-note objects may be parenthesized as well. For articulations,
a hyphen is needed before the @code{\parenthesize} command.
@lilypond[verbatim,quote,relative=2]
you can add a string number indication to the pitch name. If you
define pitch names and string numbers without a chord construct
(@code{<>}) the string number indications do not appear in traditional
-notation. It is much more comfortable to define the playing position
+notation. It is much more comfortable to define the playing position
by using the value of @code{minimumFret}. The default value for
minimumFret is 0.
@end lilypond
Another playing technique (especially used on electric guitars) is
-called @notation{palm mute}. The string is hereby partly muted by the
-palm of the striking hand (hence the name). Lilypond supports
+called @notation{palm mute}. The string is hereby partly muted by the
+palm of the striking hand (hence the name). Lilypond supports
the notation of palm mute-style notes by changing the note head to a
triangle shape.
@code{\include} statements are not interpreted until they have
been brought into the main file, so the file names they specify
must all be relative to the directory containing the main file,
-not the directory containing the included file. However,
+not the directory containing the included file. However,
this behavior can be changed by passing the option
@code{-drelative-includes} option at the command line
(or by adding @code{#(ly:set-option 'relative-includes #t)}
-at the top of the main input file). With @code{relative-includes}
+at the top of the main input file). With @code{relative-includes}
set, the path for each @code{\include} command will be taken
-relative to the file containing that command. This behavior is
+relative to the file containing that command. This behavior is
recommended and it will become the default behavior in a future
version of lilypond.
see @ref{MIDI block}.
Due to some limitations on Windows, the default extension for
-MIDI files on Windows is @code{.mid}. Other operating systems still
-use the extension @code{.midi}. If a different extension is preferred,
+MIDI files on Windows is @code{.mid}. Other operating systems still
+use the extension @code{.midi}. If a different extension is preferred,
insert the following line at the top-level of the input file,
before the start of any @code{\book}, @code{\bookpart} or @code{\score} blocks:
@itemize
@item Pitches
-@item Microtones (See @ref{Accidentals}. Rendering needs a
+@item Microtones (See @ref{Accidentals}. Rendering needs a
player that supports pitch bend.)
@item Chords entered as chord names
@item Rhythms entered as note durations, including tuplets
@cindex pedal diagrams, harp
Harps have seven strings per octave that may be sounded at the natural,
-flattened, or sharpened pitch. In lever harps, each string is adjusted
+flattened, or sharpened pitch. In lever harps, each string is adjusted
individually, but in pedal harps every string with the same pitch name
-is controlled by a single pedal. From the player's left to right, the
+is controlled by a single pedal. From the player's left to right, the
pedals are D, C, and B on the left and E, F, G, and A on the right.
The position of the pedals may be indicated with text marks:
The @code{\harp-pedal} command accepts a string of characters, where
@code{^} is the highest pedal position (flattened pitch), @code{-} is
the middle pedal position (natural pitch), @code{v} is the lowest pedal
-position (sharpened pitch), and @code{|} is the divider. A prefixed
+position (sharpened pitch), and @code{|} is the divider. A prefixed
@code{o} will circle the following pedal symbol.
@seealso
Note for editors and translators: In the following menu, two entries
are needed to link to a pair of automatically generated sections.
Please keep them and, if using emacs, do not run
-texinfo-all-menus-update without manually restoring them back. These
+texinfo-all-menus-update without manually restoring them back. These
menu entries are:
* Text markup commands::
@cindex percussion clef
Note that the normal notation of pitches (such as @code{cis4}) in a
-@code{DrumStaff} context will cause an error message. Percussion clefs
+@code{DrumStaff} context will cause an error message. Percussion clefs
are added automatically to a @code{DrumStaff} context but they can also
be set explicitly. Other clefs may be used as well.
@funindex \clef
@funindex clef
-The clef may be altered. Middle C is shown in every example. The
+The clef may be altered. Middle C is shown in every example. The
following clef names can (but do not need to) be enclosed in quotes.
@lilypond[verbatim,quote,relative=1]
@funindex tremolo
Tremolos can take two forms: alternation between two chords or two
-notes, and rapid repetition of a single note or chord. Tremolos
+notes, and rapid repetition of a single note or chord. Tremolos
consisting of an alternation are indicated by adding beams between the
notes or chords being alternated, while tremolos consisting of the
rapid repetition of a single note are indicated by adding beams or
@funindex \grace
@funindex grace
-Grace notes are ornaments that are written out. Grace notes
+Grace notes are ornaments that are written out. Grace notes
are printed in a smaller font and take up no logical time
in a measure.
@end lilypond
The space between the main note and the grace note may also be
-specified using spacers. The following example places the grace
+specified using spacers. The following example places the grace
note after a space lasting 7/8 of the main note.
@lilypond[quote,verbatim,relative=2]
@end lilypond
@noindent
-Here, voices are instantiated explicitly and are given names. The
+Here, voices are instantiated explicitly and are given names. The
@code{\voiceOne} ... @code{\voiceFour} commands set up the voices
so that first and third voices get stems up, second and fourth
voices get stems down, third and fourth voice note heads are
when one of the voices is explicitly named in order to attach lyrics to
it, the partcombining stops working.
-@code{\partcombine} only observes onset times of notes. It cannot
+@code{\partcombine} only observes onset times of notes. It cannot
determine whether a previously started note is playing or not, leading
to various problems.
Actually I found, that the @internalsref{StaffSymbol} at line 481
sends to an incomplete
-documentation. The property staff-space is not explained here. I
+documentation. The property staff-space is not explained here. I
thought Y-extent might be of
help, but it is in turn explained by x-space which again is
-missing from the list. Who has the
+missing from the list. Who has the
knowledge to fix this?
space increases when a page is stretched.
If this is zero, the distance to the next staff will not stretch at all;
@item @var{minimum-distance} -- the minimum distance to place between
-the baseline of a title and the center of the staff that follows it. This differs
+the baseline of a title and the center of the staff that follows it. This differs
from @var{padding} in that the height of a staff has no effect on
the application of @var{minimum-distance} (whereas the height of a
staff is crucial for @var{padding}).
@end example
-If a page has a ragged bottom, @var{space} is not stretched. In particular, the
+If a page has a ragged bottom, @var{space} is not stretched. In particular, the
resulting distance on such a page is the largest of
@itemize @bullet
@item @var{space},
@funindex between-scores-system-spacing
Specifies the spacing between two systems if they are in different scores, but
-there is no title between them. See @var{after-title-spacing}.
+there is no title between them. See @var{after-title-spacing}.
@item between-system-spacing
@funindex between-system-spacing
@end table
-If some values are not set, defaults will be taken. Their exact
+If some values are not set, defaults will be taken. Their exact
value is adjusted, depending on the paper size specified. Currently,
the following values are affected by this scaling:
@funindex check-consistency
If set to true, check whether @code{left-margin}, @code{right-margin} and
-@code{line-width} fit each other. Also make sure that their combination
+@code{line-width} fit each other. Also make sure that their combination
does not exceed the available @code{paper-width}. Default: @code{##t}.
@item first-page-number
@code{#1}.
@item max-systems-per-page
-The maximum number of systems that will be placed on a page. This
+The maximum number of systems that will be placed on a page. This
is currently supported only by the @code{ly:optimal-breaking} algorithm.
Default: unset.
@item min-systems-per-page
-The minimum number of systems that will be placed on a page. This
-may cause pages to be overfilled if it is made too large. This is
+The minimum number of systems that will be placed on a page. This
+may cause pages to be overfilled if it is made too large. This is
currently supported only by the @code{ly:optimal-breaking} algorithm.
Default: unset.
@cindex line breaks
@cindex breaking lines
-Line breaks are normally determined automatically. They are chosen
+Line breaks are normally determined automatically. They are chosen
so that lines look neither cramped nor loose, and consecutive
lines have similar density. Occasionally you might want to
override the automatic breaks; you can do this by specifying
-@code{\break}. This will force a line break at this point. However,
+@code{\break}. This will force a line break at this point. However,
line breaks can only occur at the end of @q{complete} bars, i.e.,
where there are no notes or tuplets left @q{hanging} over the bar
line. If you want to have a line break where there is no bar line,
bar line where it is inserted.
The most basic settings influencing line spacing are @code{indent}
-and @code{line-width}. They are set in the @code{\layout} block.
+and @code{line-width}. They are set in the @code{\layout} block.
They control the indentation of the first line of music, and the
lengths of the lines.
If @code{ragged-right} is set to true in the @code{\layout} block,
then systems end at their natural horizontal length, instead of
-being spread horizontally to fill the whole line. This is useful
+being spread horizontally to fill the whole line. This is useful
for short fragments, and for checking how tight the natural
spacing is.
\layout {
\context {
\Lyrics
- % By default, Lyrics are placed close together. Here, we allow them to
+ % By default, Lyrics are placed close together. Here, we allow them to
% be stretched more widely.
\override VerticalAxisGroup
#'inter-loose-line-spacing #'stretchability = #1000
There are two more @code{\paper} block variables that affect vertical
spacing: if @var{ragged-bottom} is set to @code{##t} then no pages will
be stretched (which means that neither the space between systems nor the
-space within systems will be stretched). If @var{ragged-last-bottom}
+space within systems will be stretched). If @var{ragged-last-bottom}
is set to @code{##t} then the last page will not be stretched.
@seealso
Note that the LilyPond's proportional notation package expects
that all proportional scores set the SpacingSpanner's
-'uniform-stretching attribute to ##t. Setting
+'uniform-stretching attribute to ##t. Setting
proportionalNotationDuration without also setting the
SpacingSpanner's 'uniform-stretching attribute to ##t will, for
example, cause Skips to consume an incorrect amount of horizontal
space.
The SpacingSpanner is an abstract grob that lives in the Score
-context. As with our settings of proportionalNotationDuration,
+context. As with our settings of proportionalNotationDuration,
overrides to the SpacingSpanner can occur in any of three
different places in our input file – in the Score \with block, in
a Score \context block, or in note entry directly.
@end lilypond
Both scores are proportional, but the spacing in the first score
-is too loose because of the clef change. The spacing of the second
+is too loose because of the clef change. The spacing of the second
score remains strict, however, because strict-note-spacing is
turned on. Turning on strict-note-spacing causes the width of
time signatures, key signatures, clefs and accidentals to play no
part in the spacing algorithm.
In addition to the settings given here, there are other settings
-that frequently appear in proportional scores. These include:
+that frequently appear in proportional scores. These include:
@itemize
@item @code{\override SpacingSpanner #'strict-grace-spacing = ##t}
of the units specified in the @code{\paper} or @code{\layout} block.
In the above example, @code{paper-height} has a value of 59.75
@code{staff-spaces}, and the @code{staff-size} is 20 points (the
-default value). Note that:
+default value). Note that:
@multitable {1 staff-space} {staff-size)/4 * (25.4/72.27) mm}
@noindent
In this case, one @code{staff-space} is approximately equal to
-1.757mm. Thus the @code{paper-height} measurement of 59.75
+1.757mm. Thus the @code{paper-height} measurement of 59.75
@code{staff-spaces} is equivalent to 105 millimeters, the height
of @code{a6} paper in landscape orientation. The pairs
(@var{a},@var{b}) are intervals, where @var{a} is the lower
being typeset by default, will sometimes cause more systems to
be fitted onto each page, as an estimation step is then bypassed,
giving a more accurate fit to each page. Also, forcing an actual
-reduction in the number of systems may save a further page. For
+reduction in the number of systems may save a further page. For
example, if the default layout has 11 systems, the following
assignment will force a layout with 10 systems.
@code{RhythmicStaff} creates a single-line staff that only
displays the rhythmic values of the input. Real durations are
-preserved. For details, see @ref{Showing melody rhythms}.
+preserved. For details, see @ref{Showing melody rhythms}.
@lilypond[verbatim,quote,relative=2]
\new RhythmicStaff { c4 d e f }
dynamic marks} and @ref{Manual repeat marks}.
@c \concat is actually documented in Align (it is not
-@c a font-switching command). But we need it here. -vv
+@c a font-switching command). But we need it here. -vv
When used inside a word, some font-switching or formatting commands
may produce an unwanted blank space. This can easily be solved by
\line \bold { Acto I }
\wordwrap \italic {
(La escena representa el corral de una casa de
- gitanos en el Albaicín de Granada. Al fondo una
+ gitanos en el Albaicín de Granada. Al fondo una
puerta por la que se ve el negro interior de
una Fragua, iluminado por los rojos resplandores
del fuego.)
\line \bold { Acto II }
\override #'(line-width . 50)
\justify \italic {
- (Calle de Granada. Fachada de la casa de Carmela
+ (Calle de Granada. Fachada de la casa de Carmela
y su hermano Manuel con grandes ventanas abiertas
a través de las que se ve el patio
donde se celebra una alegre fiesta)
Be careful when defining a variable with lyrics that creates a new
-context, for example, using the deprecated @code{\lyrics} command. See
+context, for example, using the deprecated @code{\lyrics} command. See
the next erroneous example:
@example
@c duplicated: TODO fix
Additionally, you can make an extender line to be typeset to indicate
the melisma in the score, writing a double underscore next to the
-first syllable of the melisma. This example shows the three elements
+first syllable of the melisma. This example shows the three elements
that are used for this purpose (all of them surrounded by spaces):
double hyphens to separate syllables in a word, underscores to add
notes to a melisma, and a double underscore to put an extender line.
-@c wrong: extender line only on last syllable of a word. Change example
+@c wrong: extender line only on last syllable of a word. Change example
@lilypond[relative=1,verbatim,fragment,quote]
{ \set melismaBusyProperties = #'()
c d( e) f f( e) e e }
This method is recommended only if the music in the @code{Devnull}
context does not contain melismata. Melismata are defined by the
-@code{Voice} context. Connecting lyrics to a @code{Devnull} context
+@code{Voice} context. Connecting lyrics to a @code{Devnull} context
makes the voice/lyrics links to get lost, and so does the info on
melismata. Therefore, if you link lyrics to a @code{Devnull} context,
the implicit melismata get ignored.
with slurs, see @ref{Articulations and ornamentations} and @ref{List of
articulations}.
@item Flutter tonguing is usually indicated by placing a tremolo mark
-and a text markup on the note. See @ref{Tremolo repeats}.
+and a text markup on the note. See @ref{Tremolo repeats}.
@end itemize
There are also other aspects of musical notation that can apply to wind
@item Many wind instruments are transposing instruments, see
@ref{Instrument transpositions}.
@item The slide glissando are characteristic of the trombone, but other
-winds may perform keyed or valved glissandi. See @ref{Glissando}.
+winds may perform keyed or valved glissandi. See @ref{Glissando}.
@item Harmonic series glissandi, which are possible on all brass
instruments but common for French Horns, are usually written out as
@ref{Grace notes}.
and doits}.
@item Key slaps or valve slaps are often shown by the @code{cross} style
of @ref{Special note heads}.
-@item Woodwinds can overblow low notes to sound harmonics. These are
-shown by the @code{flageolet} articulation. See @ref{List of articulations}.
+@item Woodwinds can overblow low notes to sound harmonics. These are
+shown by the @code{flageolet} articulation. See @ref{List of articulations}.
@item The use of brass mutes is usually indicated by a text markup, but
where there are many rapid changes it is better to use the
-@code{stopped} and @code{open} articulations. See @ref{Articulations and
+@code{stopped} and @code{open} articulations. See @ref{Articulations and
ornamentations} and @ref{List of articulations}.
@item Stopped horns are indicated by the @code{stopped} articulation.
See @ref{Articulations and ornamentations}.
@item
There is not a complete consistency, sometimes even in the same
text on how key signatures for particular maqams should be
-specified. It is common, however, to use a key signature per
+specified. It is common, however, to use a key signature per
group, rather than a different key signature for each different
maqam.
@macro manualIntro
This document shows a selected set of LilyPond snippets from the
@uref{http://lsr@/.dsi@/.unimi@/.it,LilyPond Snippet Repository}
-(LSR). It is in the public domain.
+(LSR). It is in the public domain.
We would like to address many thanks to Sebastiano Vigna for maintaining
LSR web site and database, and the University of Milano for hosting LSR.
For compiling and running LilyPond see the installation instructions.
These instructions can be found when you unpack lilypond, as
-@file{lilypond-x.y.z/INSTALL.txt}. They are also available on the web
+@file{lilypond-x.y.z/INSTALL.txt}. They are also available on the web
at
@uref{http://lilypond.org/doc/v2.12/Documentation/topdocs/INSTALL.html}.
\section{LilyPond-book + LaTeX}
-This is an examplefile for mixing LilyPond and Latex. It is also
-used to test lilypond-book. View the source to see how it is done.
+This is an examplefile for mixing LilyPond and Latex. It is also
+used to test lilypond-book. View the source to see how it is done.
A simple scale:
\end{lilypond}
LilyPond-book search for the \verb|\score| command when it decides
-if the code is only a fragment. Thus, in the following code, you have
+if the code is only a fragment. Thus, in the following code, you have
to use \verb|fragment| option, because the comment confuses lilypond-book.
\begin{lilypond}[fragment]
\end{lilypond}
has also the \verb|eps| options, but is not floating because there
-are an empty line before and after the lilypond block. That is
+are an empty line before and after the lilypond block. That is
correct behaviour because it follows La\TeX{} convention that an
-empty line signals a new paragraph. The \verb|eps| option
+empty line signals a new paragraph. The \verb|eps| option
is not necessary when you want the music in a paragraph on its own.
\subsection{More examples}
\pagebreak
-Testing of spacing. The next music is surrounded by an empty line.
+Testing of spacing. The next music is surrounded by an empty line.
text text text text text text text text text text text text
text text text text text text text text text text text text
For inserting LilyPond snippets it is good to keep the conformity of our
DocBook document, thus allowing us to use DocBook editors, validation
-etc. So we don't use custom tags, only specify a convention based on the
+etc. So we don't use custom tags, only specify a convention based on the
standard DocBook elements.
@subheading Common conventions
@item indent=@var{size}\@var{unit}
Set indentation of the first music system to @var{size}, using
-@var{unit} as units. @var{unit} is one of the following strings:
+@var{unit} as units. @var{unit} is one of the following strings:
@code{cm}, @code{mm}, @code{in}, or @code{pt}. This option affects
LilyPond, not the text layout.
Specify the document type to process: @code{html}, @code{latex},
@code{texi} (the default) or @code{docbook}. If this option is missing,
@command{lilypond-book} tries to detect the format automatically, see
-@ref{Filename extensions}. Currently, @code{texi} is the same as
+@ref{Filename extensions}. Currently, @code{texi} is the same as
@code{texi-html}.
@c This complicated detail is not implemented, comment it out -jm
example.
@itemx --left-padding=@var{amount}
-Pad EPS boxes by this much. @var{amount} is measured in millimeters,
+Pad EPS boxes by this much. @var{amount} is measured in millimeters,
and is 3.0 by default. This option should be used if the lines of
music stick out of the right margin.
The fonts of snippets set with LilyPond will have to be set from
inside
-of the snippet. For this you should read the AU on how to use
+of the snippet. For this you should read the AU on how to use
lilypond-book.
\selectlanguage{ngerman}
information.
@item -w,--warranty
-Show the warranty with which GNU LilyPond comes. (It comes with
+Show the warranty with which GNU LilyPond comes. (It comes with
@strong{NO WARRANTY}!)
@end table
@cindex make
Pretty well all the platforms Lilypond can run on support a software
-facility called @code{make}. This software reads a special file called a
+facility called @code{make}. This software reads a special file called a
@code{Makefile} that defines what files depend on what others and what
commands you need to give the operating system to produce one file from
-another. For example the makefile would spell out how to produce
+another. For example the makefile would spell out how to produce
@code{ballad.pdf} and @code{ballad.midi} from @code{ballad.ly} by
running Lilypond.
different output options (e.g. full score, parts, conductor's
score, piano reduction, etc.), or for projects that
require difficult commands to build them (such as
-@code{lilypond-book} projects). Makefiles vary greatly in
+@code{lilypond-book} projects). Makefiles vary greatly in
complexity and flexibility, according to the needs and skills of
-the authors. The program GNU Make comes installed on GNU/Linux
+the authors. The program GNU Make comes installed on GNU/Linux
distributions and on MacOS X, and it is also available for Windows.
See the @strong{GNU Make Manual} for full details on using
The commands to define rules in a makefile differ
according to platform; for instance the various forms of Linux and
-MacOS use @code{bash}, while Windows uses @code{cmd}. Note that on
+MacOS use @code{bash}, while Windows uses @code{cmd}. Note that on
MacOS X, you need to configure the system to use the command-line
-interpreter. Here are some example makefiles, with versions for both
+interpreter. Here are some example makefiles, with versions for both
Linux/MacOS and Windows.
The first example is for an orchestral work in four
The makefile will have targets of @code{score} (entire piece in
full score), @code{movements} (individual movements in full score),
-and @code{parts} (individual parts for performers). There
+and @code{parts} (individual parts for performers). There
is also a target @code{archive} that will create a tarball of
-the source files, suitable for sharing via web or email. Here is
-the makefile for GNU/Linux or MacOS X. It should be saved with the
+the source files, suitable for sharing via web or email. Here is
+the makefile for GNU/Linux or MacOS X. It should be saved with the
name @code{Makefile} in the top directory of the project:
@warning{When a target or pattern rule is defined, the
@end example
-There are special complications on the Windows platform. After
+There are special complications on the Windows platform. After
downloading and installing GNU Make for Windows, you must set the
correct path in the system's environment variables so that the
-DOS shell can find the Make program. To do this, right-click on
+DOS shell can find the Make program. To do this, right-click on
"My Computer," then choose @code{Properties} and
-@code{Advanced}. Click @code{Environment Variables}, and then
+@code{Advanced}. Click @code{Environment Variables}, and then
in the @code{System Variables} pane, highlight @code{Path}, click
@code{edit}, and add the path to the GNU Make executable file, which
will look something like this:
The makefile itself has to be altered to handle different shell
commands and to deal with spaces that are present
-in some default system directories. The @code{archive} target
+in some default system directories. The @code{archive} target
is eliminated since Windows does not have the @code{tar} command,
and Windows also has a different default extension for midi files.
The next Makefile is for a @command{lilypond-book} document done in
-LaTeX. This project has an index, which requires that the
-@command{latex} command be run twice to update links. Output files are
+LaTeX. This project has an index, which requires that the
+@command{latex} command be run twice to update links. Output files are
all stored in the @code{out} directory for .pdf output and in the
@code{htmlout} directory for the html output.
TODO: make this thing work on Windows
-The previous makefile does not work on Windows. An alternative
+The previous makefile does not work on Windows. An alternative
for Windows users would be to create a simple batch file
-containing the build commands. This will not
+containing the build commands. This will not
keep track of dependencies the way a makefile does, but it at
-least reduces the build process to a single command. Save the
+least reduces the build process to a single command. Save the
following code as @command{build.bat} or @command{build.cmd}.
The batch file can be run at the DOS prompt or by simply
double-clicking its icon.
@item
Locate the downloaded file and double-click on it to start the
-installer. Follow the instructions given to you by the installer;
+installer. Follow the instructions given to you by the installer;
we recommend that you leave all the install options checked and
-use the default installation location. Click the @q{Finish} button
-when the installer has completed. LilyPond is now installed.
+use the default installation location. Click the @q{Finish} button
+when the installer has completed. LilyPond is now installed.
@end enumerate
@item
Locate the LilyPond folder from the @q{Start} menu and click on the
-@q{Uninstall} icon. Click the @q{Finish} button when the uninstaller
+@q{Uninstall} icon. Click the @q{Finish} button when the uninstaller
has completed.
@item
Or from within the Control Panel, locate and select LilyPond and then
-choose the option to uninstall/remove the software. Click the @q{Finish}
+choose the option to uninstall/remove the software. Click the @q{Finish}
button when the uninstaller has completed.
@end enumerate
Put fragments of music into texts without cutting and pasting
pictures. Integrate music into @LaTeX{} or HTML seamlessly, or add
-music to OpenOffice.org with OOoLilyPond. Plugins are also available
+music to OpenOffice.org with OOoLilyPond. Plugins are also available
to allow LilyPond code in various blogs and wikis, making online
collaboration possible.
Several developers, themselves active LilyPond users, have also
written tools specifically aimed at making the process of editing
-LilyPond files faster and more effective. For some examples, see
+LilyPond files faster and more effective. For some examples, see
@ref{Easier editing}.
@divEnd
@unnumberedsec Examples
LilyPond is a powerful and flexible tool for engraving tasks of
-all kinds. Please browse our gallery of examples and be inspired!
+all kinds. Please browse our gallery of examples and be inspired!
@newsItem
@newsItem
@subsubheading Schenker Graphs
-Standard output can be modified heavily. Here is an impressive
+Standard output can be modified heavily. Here is an impressive
Schenkerian analysis, created by Kris Schaffer, for an article
in @uref{http://www.linuxjournal.com/article/8364 , Linux Journal.}.
The colors have been added for better visibility.
Delen van KENNIS zonder WINSTBEJAG} (Non-profit sharing of
knowlegde) in its @q{DS2 bijlage}. LilyPond is used as an example
and the article is interspersed with quotes from an email
-interview with Jan Nieuwenhuizen. This marks LilyPond's first
+interview with Jan Nieuwenhuizen. This marks LilyPond's first
appearance in mainstream printed press.
@item
Denemo is a graphical editor which generates LilyPond source code,
and also allows audio playback. It allows users to view the
-LilyPond source code in parallel to the graphical view. Extra
+LilyPond source code in parallel to the graphical view. Extra
LilyPond tweaks can be attached to notes, chords etc. and are stored
with the Denemo file, so that users can continue to edit graphically.
the text view when printed from there.
@warning{Denemo officially supports an outdated Lilypond version 2.8.7,
-which lacks many of the features added since then. The Denemo developers
+which lacks many of the features added since then. The Denemo developers
are actively working to bring it up to our present stable version, 2.12.}
@divEnd
many different computer languages. Emacs is a highly extensible
editor and can be used as an Integrated Development Environment.
There is a @q{lilypond mode} which supplies the language
-definitions for working with LilyPond source files. As well, one of
+definitions for working with LilyPond source files. As well, one of
our developers has written @uref{http://nicolas.sceaux.free.fr/
lilypond/lyqi.html,lyqi}, an Emacs major mode.
@item
@uref{http://canorus.org,Canorus} can also export to LilyPond, but
-is still beta-software. Testers are welcome, though.
+is still beta-software. Testers are welcome, though.
@item
@uref{http://www.volny.cz/smilauer/rumor/rumor.html,Rumor}, a realtime
projects / lilypond.git / commitdiff