version that you are working on. See TRANSLATION for details.
@end ignore
-@c \version "2.11.38"
+@c \version "2.11.61"
@node Working on LilyPond projects
@chapter Working on LilyPond projects
@menu
-* Suggestions for writing LilyPond input files::
-* When things don't work::
-* Scores and parts::
+* Suggestions for writing LilyPond input files::
+* When things don't work::
+* Scores and parts::
@end menu
@node Suggestions for writing LilyPond input files
@section Suggestions for writing LilyPond input files
-Now you're ready to begin writing larger LilyPond input files --
+Now you're ready to begin writing larger LilyPond input files --
not just the little examples in the tutorial, but whole pieces.
But how should you go about doing it?
@end itemize
@menu
-* General suggestions::
-* Typesetting existing music::
-* Large projects::
-* Saving typing with variables and functions::
-* Style sheets::
+* General suggestions::
+* Typesetting existing music::
+* Large projects::
+* Saving typing with variables and functions::
+* Style sheets::
@end menu
using a few years ago. @command{convert-ly} requires you to declare
which version of LilyPond you used.
-@item @strong{Include checks}: @ruser{Bar and barnumber checks},
-@ruser{Octave check}. If you include checks every so often, then
+@item @strong{Include checks}: @ruser{Bar and bar number checks},
+@ruser{Octave checks}. If you include checks every so often, then
if you make a mistake, you can pinpoint it quicker. How often is
@q{every so often}? It depends on the complexity of the music.
For very simple music, perhaps just once or twice. For very
per line. Saving screen space by cramming eight bars per line just isn't
worth it if you have to @q{debug} your input files.
-@item @strong{Comment your input files}. Use either bar numbers
+@item @strong{Comment your input files}. Use either bar numbers
(every so often) or
references to musical themes (@q{second theme in violins,} @q{fourth
variation,} etc.). You may not need comments when you're writing the piece
@item Enter one manuscript (the physical copy) system at a time (but still
only one bar per line of text), and
check each system when you finish it. You may use the
-@code{showLastLength} command to speed up processing -- see
-@ruser{Skipping corrected music}.
+@code{showLastLength} or @code{showFirstLength} properties to speed up
+processing -- see @ruser{Skipping corrected music}.
@item Define @code{mBreak = @{ \break @}} and insert @code{\mBreak}
in the input file whenever the manuscript has a line break. This
You may even realize that this could be useful in minimalist music:
@lilypond[quote,verbatim,ragged-right]
-fragA = \relative c'' { a4 a8. b16 }
-fragB = \relative c'' { a8. gis16 ees4 }
-violin = \new Staff { \fragA \fragA \fragB \fragA }
+fragmentA = \relative c'' { a4 a8. b16 }
+fragmentB = \relative c'' { a8. gis16 ees4 }
+violin = \new Staff { \fragmentA \fragmentA \fragmentB \fragmentA }
\score {
{
\violin
@}
@end example
+@c TODO Replace the following with a better example -td
+@c Skylining handles this correctly without padText
+
So far we've seen static substitution -- when LilyPond
sees @code{\padText}, it replaces it with the stuff that
we've defined it to be (ie the stuff to the right of
@section When things don't work
@menu
-* Updating old input files::
-* Troubleshooting (taking it all apart)::
-* Minimal examples::
+* Updating old input files::
+* Troubleshooting (taking it all apart)::
+* Minimal examples::
@end menu
@node Updating old input files