[lilypond.git] / Documentation / de / learning / working.itely

@c -*- coding: utf-8; mode: texinfo; documentlanguage: de -*-

@ignore
    Translation of GIT committish: d96023d8792c8af202c7cb8508010c0d3648899d

    When revising a translation, copy the HEAD committish of the
    version that you are working on.  See TRANSLATION for details.
@end ignore

@c \version "2.12.0"

@node An LilyPond-Projekten arbeiten
@chapter An LilyPond-Projekten arbeiten
@translationof Working on LilyPond projects

Dieses Kapitel erklärt, wie bestimmte häufige Probleme zu 
lösen oder ganz zu vermeiden sind.  Wenn Sie schon 
Programmiererfahrung mitbringen, erscheinen diese Hinweise 
vielleicht überflüssig, aber es wird dennoch empfohlen, dieses Kapitel 
zu lesen.


@menu
* Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen::
* Wenn etwas nicht funktioniert::
* Partituren und Stimmen::
* Make und Makefiles::
@end menu


@node Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen
@section Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen
@translationof Suggestions for writing LilyPond input files

Jetzt sind Sie so weit, größere Stücke mit LilyPond zu schreiben -- 
nicht nur die kleinen Beispiele aus der Übung, sondern ganze Stücke.
Aber wie geht man das am besten an?

Solange LilyPond Ihre Dateien versteht und die Noten so setzt, 
wie Sie das wollen, spielt es eigentlich keine Rolle, wie Ihre 
Dateien aussehen.  Es gibt aber trotzdem ein paar Dinge, die man 
beim Schreiben von LilyPond-Code berücksichtigen sollte.

@itemize @bullet
@item Was ist, wenn Sie einen Fehler machen?  Die Struktur einer 
LilyPond-Datei kann es erleichtern (oder erschweren), bestimmte 
Fehler zu finden.

@item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen 
wollen?  Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten 
wollen?  Manche LilyPond-Dateien versteht man auf den ersten Blick, 
über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.

@item Was ist, wenn sie Ihre Dateien auf eine neuere LilyPond-Version 
aktualisieren wollen?  Die Syntax der Eingabesprache verändert sich 
allmählich mit Verbesserungen im Programm.  Die meisten Veränderungen 
können automatisch durch @code{convert-ly} gelöst werden, aber 
bestimmte Änderungen brauchen Handarbeit.  LilyPond-Dateien können 
strukturiert werden, damit sie einfacher aktualisierbar sind.
@end itemize

@menu
* Allgemeine Vorschläge::
* Das Kopieren von bereits vorhandener Musik::
* Große Projekte::
* Tipparbeit sparen durch Bezeichner und Funktionen::
* Stil-Dateien::
@end menu


@node Allgemeine Vorschläge
@subsection Allgemeine Vorschläge
@translationof General suggestions

Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:

@itemize @bullet
@item @strong{Schreiben Sie immer mit @code{\version} die 
Versionsnummer 
in jede Datei}.  Beachten Sie, dass in allen Vorlagen die Versionsnummer  
@code{\version "2.12.0"} eingetragen ist.  Es empfiehlt sich, in alle 
Dateien, unabhängig von ihrer Größe, den @code{\version}-Befehl 
einzufügen.  Persönliche Erfahrung hat gezeigt, dass es ziemlich 
frustrierend sein kann zu erinnern, welche Programmversion man etwa 
vor einem Jahr verwendet hat.  Auch @code{convert-ly} benötigt die 
Versionsnummer.

@item @strong{Benutzen Sie Überprüfungen}: @ruser{Oktavenüberprüfung}, und
@ruser{Takt- und Taktzahlüberprüfung}.  Wenn Sie hier und da diese
Überprüfungen einfügen, finden Sie einen möglichen Fehler weit
schneller.  Wie oft aber ist @qq{hier und da}?  Das hängt von der
Komplexität der Musik ab.  ei einfachen Stücken reicht es vielleicht
ein- oder zweimal, in sehr komplexer Musik sollte man sie vielleicht
in jeden Takt einfügen.

@item @strong{Ein Takt pro Textzeile}.  Wenn irgendetwas kompliziertes 
vorkommt, entweder in der Musik selber oder in der Anpassung der 
Ausgabe,
empfiehlt es sich oft, nur einen Takt pro Zeile zu schreiben. 
Bildschirmplatz zu sparen, indem Sie acht Takte in eine Zeile zwängen, 
hilft nicht weiter, wenn Sie ihre Datei @qq{debuggen} müssen.

@item @strong{Kommentieren Sie ihre Dateien}.  Benutzen Sie entweder 
Taktnummern (in regelmäßigen Abständen) oder Verweise auf musikalische 
Themen (@qq{Zweites Thema in den Geigen}, @qq{vierte Variation} usw.). 
Sie brauchen diese Kommentare vielleicht noch nicht, wenn Sie das Stück  
notieren, aber spätestens wenn Sie nach ein paar Jahren etwas 
verändern 
wollen oder Sie den Quelltext an einen Freund weitergeben wollen, 
ist es weitaus komplizierter, die Dateistruktur ohne Kommentare zu 
verstehen, als wenn Sie sie rechtzeitig eingefügt hätten.

@item @strong{Schreiben Sie Klammern mit Einrückung}.  Viele 
Probleme entstehen durch ungerade Anzahl von  @code{@{} and 
@code{@}}-Klammern.

@item @strong{Schreiben Sie Tondauerangaben} am Anfang von 
Abschnitten und Bezeichnern.  Wenn Sie beispielsweise 
 @code{c4 d e} am Anfang eines Abschnittes schreiben, 
ersparen Sie sich viele Probleme, wenn Sie ihre Musik 
eines Tages umarrangieren wollen.

@item @strong{Trennen Sie Einstellungen} von den eigentlichen 
Noten.  Siehe auch @ref{Tipparbeit sparen durch Bezeichner und Funktionen} 
und
@ref{Stil-Dateien}.

@end itemize


@node Das Kopieren von bereits vorhandener Musik
@subsection Das Kopieren von bereits vorhandener Musik
@translationof Typesetting existing music

Wenn Sie Musik aus einer fertigen Partitur kopieren (z. B. die 
LilyPond-Eingabe einer gedruckten Partitur):

@itemize @bullet

@item Schreiben Sie ein System ihrer Quelle nach dem anderen 
(aber trotzdem nur einen Takt pro Textzeile) und überprüfen 
Sie jedes System, nachdem Sie es fertig kopiert haben.  Mit dem 
@code{showLastLength}- oder @code{showFirstLenght}-Befehl können Sie den Übersetzungsprozess 
beschleunigen. Siehe auch 
@ruser{Korrigierte Musik überspringen}.

@item Definieren Sie @code{mBreak = @{ \break @}} und schreiben Sie
 @code{\mBreak} in der Quelldatei immer dann, wenn im Manuskript 
ein Zeilenumbruch vorkommt.  Das macht es einfacher, die gesetzte 
Zeile mit den ursprünglichen Noten zu vergleichen.  Wenn Sie die 
Partitur fertig gestellt haben, könne Sie  @code{mBreak = @{ @}}, 
also leer definieren, um diese manuellen Zeilenumbrüche zu entfernen. 
Damit kann dann LilyPond selber entscheiden, wohin es passende 
Zeilenumbrüche platziert.

@item Wenn Sie eine Stimme für ein transponierendes Instrument als eine
Variable notieren, wird empfohlen, dass die Noten von

@example
\transpose c klingende-Tonhöhe @{...@}
@end example

eingefasst werden (wobei @code{klingende-Tonhöhe} die klingende Tonhöhe
des Instruments ist), sodass die Noten innerhalb der Variable für klingendes C
geschrieben sind.  Sie können die Variable zurücktransponieren, wenn es
nötig ist, aber Sie müssen es nicht tun.  Fehler in Transpositionen sind
treten seltener auf, wenn alle Noten in den Variablen für die gleiche
Ausgangstonhöhe geschrieben werden.

Denken Sie auch daran, dass Sie nur von/nach C transponieren.  Das heißt,
dass die einzigen anderen Tonhöhen, die Sie in Transpositionen benutzen,
die Tonhöhen der Instrumente sind, für die Sie schreiben: @code{bes} für
eine B-Trompete oder @code{aes} für eine As-Klarinette usw.

@end itemize


@node Große Projekte
@subsection Große Projekte
@translationof Large projects

Besonders wenn Sie an größeren Projekten arbeiten, ist es 
unumgänglich, dass Sie ihre LilyPond-Dateien klar strukturieren.

@itemize @bullet

@item @strong{Verwenden Sie Variablen für jede Stimme}, innerhalb 
der Definition sollte so wenig Struktur wie möglich sein.  Die 
Struktur des @code{\score}-Abschnittes verändert sich am ehesten, 
während die @code{violine}-Definition sich wahrscheinlich mit einer 
neuen Programmversion nicht verändern wird.

@example
violine = \relative c'' @{
g4 c'8. e16
@}
...
\score @{
  \new GrandStaff @{
    \new Staff @{
      \violine
    @}
  @}
@}
@end example

@item @strong{Trennen Sie Einstellungen von den Noten}.  Diese 
Empfehlung wurde schon im Abschnitt @ref{Allgemeine Vorschläge} gegeben, 
aber für große Projekte ist es unumgänglich.  Muss z. B. die 
Definition für @code{fdannp} verändert werden, so braucht 
man es nur einmal vorzunehmen und die Noten in der Geigenstimme, 
@code{violin}, bleiben unberührt.

@example
fdannp = _\markup@{
  \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
violin = \relative c'' @{
g4\fdannp c'8. e16
@}
@end example

@end itemize


@node Tipparbeit sparen durch Bezeichner und Funktionen
@subsection Tipparbeit sparen durch Bezeichner und Funktionen
@translationof Saving typing with variables and functions

@cindex Variable
@cindex Bezeichner

Bis jetzt haben Sie immer etwa solche Noten gesehen:

@lilypond[quote,verbatim,ragged-right]
hornNotes = \relative c'' { c4 b dis c }
\score {
  {
    \hornNotes
  }
}
@end lilypond

Das könnte auch nützlich in Minimal-Music sein:

@lilypond[quote,verbatim,ragged-right]
fragmentA = \relative c'' { a4 a8. b16 }
fragmentB = \relative c'' { a8. gis16 ees4 }
violin = \new Staff { \fragmentA \fragmentA \fragmentB \fragmentA }
\score {
  {
    \violin
  }
}
@end lilypond

Sie können diese Bezeichner oder Variablen aber auch für 
(eigene) Einstellungen verwenden:

@lilypond[quote,verbatim,ragged-right]
dolce = \markup{ \italic \bold dolce }
padText = { \once \override TextScript #'padding = #5.0 }
fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p }
violin = \relative c'' {
  \repeat volta 2 {
    c4._\dolce b8 a8 g a b |
    \padText
    c4.^"hi there!" d8 e' f g d |
    c,4.\fthenp b8 c4 c-. |
  }
}
\score {
  {
    \violin
  }
\layout{ragged-right=##t}
}
@end lilypond

Die Variablen haben in diesem Beispiel deutlich die 
Tipparbeit erleichtert.  Aber es lohnt sich, sie zu 
einzusetzen, auch wenn man sie nur einmal anwendet, 
denn sie vereinfachen die Struktur. 
Hier ist das vorangegangene Beispiel ohne 
Variablen.  Es ist sehr viel komplizierter zu lesen, 
besonders die letzte Zeile. 

@example
violin = \relative c'' @{
  \repeat volta 2 @{
    c4._\markup@{ \italic \bold dolce @} b8 a8 g a b |
    \once \override TextScript #'padding = #5.0
    c4.^"hi there!" d8 e' f g d |
    c,4.\markup@{ \dynamic f \italic \small @{ 2nd @}
      \hspace #0.1 \dynamic p @} b8 c4 c-. |
  @}
@}
@end example

@c TODO Replace the following with a better example  -td
@c Skylining handles this correctly without padText

Bis jetzt wurde nur statische Substitution vorgestellt 
-- wenn LilyPond den Befehl @code{\padText} findet, wird 
er ersetzt durch durch unsere vorherige Definition (alles, 
was nach dem @code{padtext =} kommt).

LilyPond kennt aber auch nicht-statische Substitutionen (man 
kann sie sich als Funktionen vorstellen).

@lilypond[quote,verbatim,ragged-right]
padText =
#(define-music-function (parser location padding) (number?)
  #{
    \once \override TextScript #'padding = #$padding
  #})

\relative c''' {
  c4^"piu mosso" b a b
  \padText #1.8
  c4^"piu mosso" d e f
  \padText #2.6
  c4^"piu mosso" fis a g
}
@end lilypond

Die Benutzung von Variablen hilft auch, viele Schreibarbeit zu 
vermeiden, wenn die Eingabesyntax von LilyPond sich verändert 
(siehe auch @ref{Alte Dateien aktualisieren}).  Wenn nur eine einzige 
Definition (etwa @code{\dolce}) für alle Dateien verwendet wird 
(vgl. @ref{Stil-Dateien}), muss nur diese einzige Definition 
verändert werden, wenn sich die Syntax ändert.  Alle Verwendungen 
des Befehles beziehen sich dann auf die neue Definition.

@node Stil-Dateien
@subsection Stil-Dateien
@translationof Style sheets

Die Ausgabe, die LilyPond erstellt, kann sehr stark modifiziert 
werden, siehe @ref{Die Ausgabe verändern} für Einzelheiten.  Aber wie 
kann man diese Änderungen auf eine ganze Serie von Dateien 
anwenden?  Oder die Einstellungen von den Noten trennen?  Das 
Verfahren ist ziemlich einfach.

Hier ist ein Beispiel.  Es ist nicht schlimm, wenn Sie nicht auf 
Anhieb die Abschnitte mit den ganzen @code{#()} verstehen.  Das 
wird im Kapitel @ref{Fortgeschrittene Optimierungen mit Scheme} erklärt.

@lilypond[quote,verbatim,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))

inst = #(define-music-function (parser location string) (string?)
  (make-music
    'TextScriptEvent
    'direction UP
    'text (markup #:bold (#:box string))))

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \inst "Clarinet"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

Es treten einige Probleme mit überlappenden Symbolen auf. Sie 
werden beseitigt mit den Tricks aus dem Kapitel @ref{Verschieben von Objekten}.
Aber auch die @code{mpdolce} und @code{inst}-Definitionen 
können verbessert werden.  Sie produzieren das Ergebnis, das 
gewünscht ist, aber es wäre schön, sie auch in anderen Stücken 
verwenden zu können.  Man könnte sie natürlich einfach kopieren 
und in die anderen Dateien einfügen, aber das ist lästig.  Die 
Definitionen verbleiben auch in der Notendatei und diese @code{#()} 
sehen nicht wirklich schön aus.  Sie sollen in einer anderen 
Datei versteckt werden:

@example
%%% speichern in einer Datei "definitions.ily"
mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))

inst = #(define-music-function (parser location string) (string?)
  (make-music
    'TextScriptEvent
    'direction UP
    'text (markup #:bold (#:box string))))
@end example

Auf diese Datei kann dann später mit dem @code{\include}-Befehl
im oberen Teil der LilyPond-Datei zurückgegriffen werden. (Die
Erweiterung @code{.ily} wird benutzt, um diese eingefügte Datei,
die nicht alleine kompiliert werden kann, von der Hauptdatei zu
unterscheiden.)
Jetzt muss natürlich noch die Notendatei angepasst werden (gespeichert 
unter dem Namen @file{"music.ly"}).

@c  We have to do this awkward example/lilypond-non-verbatim
@c  because we can't do the \include stuff in the manual.

@example
\include "definitions.ily"

\relative c'' @{
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \inst "Clarinet"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))

inst = #(define-music-function (parser location string) (string?)
  (make-music
    'TextScriptEvent
    'direction UP
    'text (markup #:bold (#:box string))))

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \inst "Clarinet"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

Das sieht schon besser aus, aber es sind noch einige Verbesserungen 
möglich. 
Das Glissando ist schwer zu sehen, also soll es etwas dicker erscheinen 
und dichter an den Notenköpfen gesetzt werden.  Das Metronom-Zeichen 
soll über dem Schlüssel erscheinen, nicht über der ersten Note.  Und 
schließlich kann unser Kompositionsprofessor @qq{C}-Taktangaben 
überhaupt nicht leiden, also 
müssen sie in @qq{4/4} verändert werden.

Diese Veränderungen sollten Sie aber nicht in der @file{music.ly}-Datei 
vornehmen.  Ersetzen Sie die @file{definitions.ily}-Datei hiermit:

@example
%%%  definitions.ily
mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))

inst = #(define-music-function (parser location string) (string?)
  (make-music
    'TextScriptEvent
    'direction UP
    'text (markup #:bold (#:box string))))

\layout@{
  \context @{ \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  @}
  \context @{ \Staff
    \override TimeSignature #'style = #'numbered
  @}
  \context @{ \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  @}
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))

inst = #(define-music-function (parser location string) (string?)
  (make-music
    'TextScriptEvent
    'direction UP
    'text (markup #:bold (#:box string))))

\layout{
  \context { \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  }
  \context { \Staff
    \override TimeSignature #'style = #'numbered
  }
  \context { \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  }
}

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \inst "Clarinet"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

Das sieht schon besser aus!  Aber angenommen Sie möchten dieses 
Stück jetzt veröffentlichen.  Ihr Kompositionsprofessor mag 
die @qq{C}-Taktangaben nicht, aber Sie finden sie irgendwie 
schöner.  Also kopieren Sie die Datei @file{definitions.ily} nach 
@file{web-publish.ily} und verändern diese.  Weil die Noten 
in einer PDF-Datei auf dem Bildschirm angezeigt werden sollen, 
bietet es sich auch an, die gesamte Ausgabe zu vergrößern.

@example
%%%  definitions.ily
mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))

inst = #(define-music-function (parser location string) (string?)
  (make-music
    'TextScriptEvent
    'direction UP
    'text (markup #:bold (#:box string))))

#(set-global-staff-size 23)
\layout@{
  \context @{ \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  @}
  \context @{ \Staff
  @}
  \context @{ \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  @}
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))

inst = #(define-music-function (parser location string) (string?)
  (make-music
    'TextScriptEvent
    'direction UP
    'text (markup #:bold (#:box string))))

#(set-global-staff-size 23)
\layout{
  \context { \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  }
  \context { \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  }
}

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \inst "Clarinet"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

In der Notendatei muss jetzt nur noch @code{\include "definitions.ily"}
durch @code{\include "web-publish.ily"} ausgetauscht werden. 
Das könnte man natürlich noch weiter vereinfachen.  Also 
eine Datei @file{definitions.ily}, die nur die Definitionen 
von @code{mpdolce} und @code{inst} enthält, eine Datei 
@file{web-publish.ily}, die alle die Änderungen für den 
@code{\layout}-Abschnitt enthält und eine Datei @file{university.ily} 
für eine Ausgabe, die den Wünschen des Professors entspricht. 
Der Anfang der @file{music.ly}-Datei würde dann so aussehen:

@example
\include "definitions.ily"

%%%  Nur eine der beiden Zeilen auskommentieren!
\include "web-publish.ily"
%\include "university.ily"
@end example

Durch diese Herangehensweise kann auch bei der Erstellung 
von nur einer Ausgabeversion Arbeit gespart werden.  Ich 
benutze ein halbes Dutzend verschiedener Stilvorlagen 
für meine Projekte.  Jede Notationsdatei fängt an mit 
@code{\include "../global.ily"}, welches folgenden Inhalt hat:


@example
%%%   global.ly
\version "2.12.0"
#(ly:set-option 'point-and-click #f)
\include "../init/init-defs.ily"
\include "../init/init-layout.ily"
\include "../init/init-headers.ily"
\include "../init/init-paper.ily"
@end example


@node Wenn etwas nicht funktioniert
@section Wenn etwas nicht funktioniert
@translationof When things don't work

@menu
* Alte Dateien aktualisieren::
* Fehlersuche (alles auseinandernehmen)::
* Minimalbeispiele::
@end menu

@node Alte Dateien aktualisieren
@subsection Alte Dateien aktualisieren
@translationof Updating old files

Die Syntax von LilyPond verändert sich ab und zu.  Wenn LilyPond 
besser wird, muss auch die Syntax (Eingabesprache) entsprechend 
angepasst werden.  Teilweise machen diese Veränderungen die 
Eingabesprache einfacher lesbar, teilweise dienen sie dazu, neue 
Eigenschaften des Programmes benutzbar zu machen.

LilyPond stellt ein Programm bereit, das Aktualisierungen 
vereinfacht: @code{convert-ly}.  Einzelheiten zur Programmbenutzung 
finden sich in @rprogram{Dateien mit convert-ly aktualisieren}.

Leider kann @code{convert-ly} nicht alle Veränderungen der Syntax
berücksichtigen.  Hier werden einfache @qq{Suchen und
Ersetzen}-Veränderungen vorgenommen (wie etwa @code{raggedright} zu
@code{ragged-right}), aber einige Veränderungen sind zu
kompliziert.  Die Syntax-Veränderungen, die das Programm nicht
berücksichtigt, sind im Kapitel @rprogram{Dateien mit convert-ly aktualisieren} aufgelistet.

Zum Beispiel wurden in LilyPond 2.4 und früheren Versionen 
Akzente und Umlaute mit LaTeX-Befehlen eingegeben, ein 
@qq{No\"el} etwa ergäbe das französische Wort für Weihnachten.
In LilyPond 2.6 und höher müssen diese Sonderzeichen direkt 
als utf-8-Zeichen eingegeben werden, in diesem Fall also @qq{ë}. 
@code{convert-ly} kann nicht alle dieser LaTeX-Befehle 
verändern, das muss manuell vorgenommen werden.


@node Fehlersuche (alles auseinandernehmen)
@subsection Fehlersuche (alles auseinandernehmen)
@translationof Troubleshooting (taking it all apart)

Früher oder später werden Sie in die Lage kommen, 
dass LilyPond Ihre Datei nicht kompilieren will.  Die 
Information, die LilyPond während der Übersetzung 
gibt, können Ihnen helfen, den Fehler zu finden, aber 
in vielen Fällen müssen Sie nach der Fehlerquelle 
auf die Suche gehen.

Die besten Hilfsmittel sind in diesem Fall das Zeilen- 
und Blockkommentar (angezeigt durch @code{%} bzw. 
@code{%@{ ... %@}}).  Wenn Sie nicht bestimmen können, 
wo sich das Problem befindet, beginnen Sie damit, große 
Teile des Quelltextes auszukommentieren.  Nachdem Sie 
einen Teil auskommentiert haben, versuchen Sie, die Datei 
erneut zu übersetzen.  Wenn es jetzt funktioniert, muss 
sich das Problem innerhalb der Kommentare befinden. 
Wenn es nicht funktioniert, müssen Sie weitere Teile 
auskommentieren bis sie eine Version haben, die funktioniert.

In Extremfällen bleibt nur noch solch ein Beispiel übrig:

@example
\score @{
  <<
    % \melody
    % \harmony
    % \bass
  >>
  \layout@{@}
@}
@end example

@noindent
(also eine Datei ohne Noten).

Geben Sie nicht auf, wenn das vorkommen sollte.  Nehmen 
Sie das Kommentarzeichen von einem Teil wieder weg, sagen 
wir der Bassstimme, und schauen Sie, ob es funktioniert. 
Wenn nicht, dann kommentieren Sie die gesamte Bassstimme 
aus, aber nicht den @code{\bass}-Befehl in dem 
 @code{\score}-Abschnitt:

@example
bass = \relative c' @{
%@{
  c4 c c c
  d d d d
%@}
@}
@end example

Jetzt beginnen Sie damit, langsam Stück für Stück der 
Bassstimme wieder hineinzunehmen, bis Sie die problematische 
Zeile finden.

Eine andere nützliche Technik zur Problemlösung ist es, 
@ref{Minimalbeispiele} zu konstruieren.


@node Minimalbeispiele
@subsection Minimalbeispiele
@translationof Minimal examples

Ein Minimalbeispiel ist eine Beispieldatei, die so klein wie 
möglich ist.  Diese Beispiele sind sehr viel einfacher zu 
verstehen als die langen Originaldateien.  Minimalbeispiele 
werden benutzt, um


@itemize
@item Fehlerberichte zu erstellen,
@item eine Hilfeanfrage an die E-Mail-Liste zu schicken,
@item Ein Beispiel zur @uref{http://lsr@/.dsi@/.unimi@/.it/,LilyPond
Schnipselsammlung} hinzuzufügen.
@end itemize

Um ein Beispiel zu konstruieren, das so klein wie möglich ist, 
gibt es eine einfache Regel:  Alles nicht Notwendige entfernen. 
Wenn Sie unnötige Teile einer Datei entfernen, bietet es sich an, 
sie auszukommentieren und nicht gleich zu löschen.  Auf diese Weise 
können Sie eine Zeile leicht wieder mit aufnehmen, sollten Sie sie 
doch brauchen, anstatt sie von Anfang an neu zu schreiben.

Es gibt zwei Ausnahmen dieser @qq{So klein wie möglich}-Regel:

@itemize
@item Fügen Sie immer einen @code{\version}Befehl ein.
@item Wenn es möglich ist, benutzen Sie @code{\paper@{ ragged-right = ##t @}}
am Beginn des Beispiels.
@end itemize

Der Sinn der Minimalbeispiele ist, dass sie einfach lesbar sind:

@itemize
@item Vermeiden Sie es, komplizierte Noten, Schlüssel oder Taktangaben 
zu verwenden, es sei denn, Sie wollen genau an diesen Elementen 
etwas demonstrieren.
@item Benutzen Sie keine @code{\override}-Befehle, wenn sie nicht der 
Zweck des Beispieles sind.
@end itemize


@node Partituren und Stimmen
@section Partituren und Stimmen
@translationof Scores and parts

Orchesternoten werden alle zweimal gesetzt. Erstens als Stimmen für 
die Musiker, und dann als große Partitur für den Dirigenten.  Mit 
Variablen 
kann hier doppelte Arbeit erspart werden. Die Musik muss nur einmal 
eingegeben werden und wird in einer Variable abgelegt.  Der Inhalt 
dieser 
Variable wird dann benutzt, um sowohl die Stimme als auch die Partitur 
zu erstellen.

Es bietet sich an, die Noten in eigenen Dateien zu speichern.  Sagen wir 
beispielsweise, dass in der Datei @file{Horn-Noten.ly} die folgenden 
Noten eines Duetts für Horn und Fagott gespeichert sind:

@example
HornNoten = \relative c @{
  \time 2/4
  r4 f8 a cis4 f e d
@}
@end example

@noindent
Daraus wird dann eine eigene Stimme gemacht, indem folgende Datei 
erstellt 
wird:

@example
\include "Horn-Noten.ly"
\header @{
  instrument = "Horn in F"
@}

@{
 \transpose f c' \HornNoten
@}
@end example

Die Zeile

@example
\include "Horn-Noten.ly"
@end example

@noindent
setzt den Inhalt der Datei @file{Horn-Noten.ly} an die Stelle des 
Befehls in die aktuelle Datei.  Damit besteht also eine Definition 
für @code{HornNoten}, so dass die Variable verwendet werden kann. 
Der Befehl @code{\transpose f@tie{}c'} zeigt an, dass das Argument, 
also @code{\HornNoten}, um eine Quinte nach oben transponiert wird.
Klingendes @q{f} wird also als @code{c'} notiert.  Das entspricht 
der Notation eines Waldhorns in F.  Die Transposition zeigt die folgende 
Ausgabe:

@lilypond[quote,ragged-right]
\transpose f c' \relative c {
  \time 2/4
  r4 f8 a cis4 f e d
}
@end lilypond

In der Musik für mehrere Instrumente kommt es oft vor, dass eine Stimme 
für mehrere Takte nicht spielt.  Das wird mit einer besonderen Pause 
angezeigt, dem Pausenzeichen für mehrere Takte (engl. multi-measure 
rest).  Sie wird mit dem @emph{großen} Buchstaben @samp{R} eingegeben, 
gefolgt von einer Dauer (@code{1}@tie{}für eine Ganze, @code{2}@tie{}
für eine Halbe usw.).  Indem man die Dauer multipliziert, können längere  
Pausen erstellt werden.  Z. B. dauert diese Pause drei Takte eines 
2/4-Taktes:

@example
R2*3
@end example

Wenn die Stimme gedruckt wird, müssen diese Pausen zusammengezogen 
werden. 
Das wird durch eine Variable erreicht:

@example
\set Score.skipBars = ##t
@end example

@noindent
Dieser Befehl setzt die Eigenschaft des @code{skipBars} (@qq{überspringe 
Takte}) auf wahr (@code{##t}).  Wenn diese Option und die Pause 
zu der Musik des Beispiels gesetzt wird, erhält man folgendes Ergebnis:

@lilypond[quote,ragged-right]
\transpose f c' \relative c {
  \time 2/4
  \set Score.skipBars = ##t
  R2*3
  r4 f8 a cis4 f e d
}
@end lilypond

Die Partitur wird erstellt, indem alle Noten zusammengesetzt werden. 
Angenommen, die andere Stimme trägt den Namen @code{FagottNoten} 
 und ist in der Datei @file{Fagott-Noten.ly} gespeichert.  Die
Partitur sieht dann folgendermaßen aus:

@example
\include "Fagott-Noten.ly"
\include "Horn-Noten.ly"

<<
  \new Staff \HornNoten
  \new Staff \FagottNoten
>>
@end example

@noindent
Und mit LilyPond übersetzt:

@lilypond[quote,ragged-right]
\relative c <<
  \new Staff {
    \time 2/4 R2*3
    r4 f8 a cis4 f e d
  }
  \new Staff {
    \clef bass
    r4 d,8 f | gis4 c | b bes |
    a8 e f4 | g d | gis f
  }
>>
@end lilypond


@node Make und Makefiles
@section Make und Makefiles
@translationof Make and Makefiles

@cindex Makefile
@cindex Make-Dateien
@cindex make

Fast alle Betriebssysteme, auf denen LilyPond benutzt werden kann,
unterstützen ein Programm mit dem Namen @code{make}.  Dieses Programm
liest eine besondere Datei mit der Bezeichnung @code{Makefile},
die definiert, welche Dateien von welchen anderen Dateien abhängen und
welche Befehle für das Betriebssystem nötig sind, um eine Datei aus
einer anderen zu erstellen. Ein Makefile könnte etwa erklären, wie
@code{ballad.pdf} und @code{ballad.midi} aus @code{ballad.ly}
erstellt werden können, indem LilyPond aufgerufen wird.

Es gibt Fällen, wenn es sich sehr stark empfiehlt, ein @code{Makefile}
für das aktuelle Projekt zu erstellen, entweder zur eigenen Bequemlichkeit,
oder aber auch als Hilfe für andere, die vielleicht einmal die
Quelldateien lesen und verstehen wollen.  Insbesondere bei großen Projekten
mit vielen eingefügten Dateien und unterschiedlichen Ausgabeoptionen
(etwa Partitur, einzelne Stimmen, Dirigierpartitur, Klavierauszug usw.),
aber auch bei Projekten, die komplizierte Programmaufrufe zur Verarbeitung
erfordern (wenn man etwa mit @code{lilypond-book} arbeitet), lohnt
sich die Erstellung einer Make-Datei.  Diese Dateien können sehr
unterschiedliche ausfallen, und ihre Komplexität und Flexibilität kann
den Bedürfnissen aber auch Kenntnissen des Schreibers angepasst werden.
Das Programm GNU Make ist auf GNU/Linux Distributionen und MacOS X
installiert, aber es ist auch für Windows erhältlich.

Das @strong{GNU Make Manual} gibt eine vollständige Anleitung, wie
@code{make} benutzt werden kann.  Hier sollen nur einige kleine
Blicke auf die vielfältigen Möglichkeiten geworfen werden.

Die Befehle, um Regeln in einer Make-Datei zu erstellen, unterscheidet
sich zwischen den Betriebssystemen.  Die verschiedenen Linuxe und
MacOS X benutzen @code{bash}, während unter Windows @code{cmd} eingesetzt
wird.  Unter MacOS X muss man das System so konfigurieren, dass
die Kommandozeile benutzt wird.  Hier einige Beispiele für Make-Dateien,
mit Versionen für Linux/MacOS und Windows.

Das erste Beispiel ist für ein Orchesterstück in vier Stätzen unt mit
der folgenden Dateistruktur:

@example
Symphony/
|-- MIDI/
|-- Makefile
|-- Notes/
|   |-- cello.ily
|   |-- figures.ily
|   |-- horn.ily
|   |-- oboe.ily
|   |-- trioString.ily
|   |-- viola.ily
|   |-- violinOne.ily
|   `-- violinTwo.ily
|-- PDF/
|-- Parts/
|   |-- symphony-cello.ly
|   |-- symphony-horn.ly
|   |-- symphony-oboes.ly
|   |-- symphony-viola.ly
|   |-- symphony-violinOne.ly
|   `-- symphony-violinTwo.ly
|-- Scores/
|   |-- symphony.ly
|   |-- symphonyI.ly
|   |-- symphonyII.ly
|   |-- symphonyIII.ly
|   `-- symphonyIV.ly
`-- symphonyDefs.ily
@end example

Die @code{.ly}-Dateien un den Verzeichnissen @code{Scores} und
@code{Parts} erhalten ihrere Noten aus @code{.ily}-Dateien, die
sich im @code{Notes}-Verzeichnis befinden:

@example
%%% Kopfzeile der Datei "symphony-cello.ly"
\include ../definitions.ily
\include ../Notes/cello.ily
@end example

Die Make-Datei hat die Ziele @code{score} (das gesamte Stück als
große Partitur), @code{movements} (die einzelnen Sätze als große
Partitur) und @code{parts} (die einzelnen Stimmen für die Spieler).
Es gibt auch das Ziel @code{archive}, welches ein Tar-Archiv
der Quelldateien erstellt, etwa um die Quellen über das Internet
oder per E-Mail zu verteilen.  Hier die Make-Datei für GNU/Linux
oder MacOS X.  Sie sollte unter dem Namen @code{Makefile} im obersten
Verzeichnis des Projektes gespeichert werden:

@warning{Wenn ein Ziel oder eine Musterregel definiert ist, müssen
die folgenden Zeilen mit Tabulatoren, nicht mit Leerzeichen beginnen.}

@example
# Namensstamm der Ausgabedateien
piece = symphony
# finde heraus, wieviele Prozessoren vorhanden sind
CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
# Der Befehl, um lilypond aufzurufen
LILY_CMD = lilypond -ddelete-intermediate-files \
                    -dno-point-and-click -djob-count=$(CPU_CORES)

# Die Endungen, die im Makefile benutzt werden
.SUFFIXES: .ly .ily .pdf .midi

# Eingabe- und Ausgabedateien werden in den Verzeichnissen durchsucht,
# die sich in der VPATH-Variable befinden.  Alle sind Unterverzeichnisse
# des aktuellen Verzeichnisses (angegeben durch die GNU make-Variable
# `CURDIR').
VPATH = \
  $(CURDIR)/Scores \
  $(CURDIR)/PDF \
  $(CURDIR)/Parts \
  $(CURDIR)/Notes

# Die Musterregel, um PDF und MIDI-Dateien aus der LY-Eingabedatei
# zu erstellen.  Die .pdf-Ausgabedateien werden in das
# `PDF'-Unterverzeichnis abgelegt, die .midi-Dateien in das
# `MIDI'-Unterverzeichnis.
%.pdf %.midi: %.ly
        $(LILY_CMD) $<; \           # this line begins with a tab
        if test -f "$*.pdf"; then \
            mv "$*.pdf" PDF/; \
        fi; \
        if test -f "$*.midi"; then \
            mv "$*.midi" MIDI/; \
        fi

notes = \
  cello.ily \
  horn.ily \
  oboe.ily \
  viola.ily \
  violinOne.ily \
  violinTwo.ily

# Abhängigkeiten der einzelnen Sätze.
$(piece)I.pdf: $(piece)I.ly $(notes)
$(piece)II.pdf: $(piece)II.ly $(notes)
$(piece)III.pdf: $(piece)III.ly $(notes)
$(piece)IV.pdf: $(piece)IV.ly $(notes)

# Abhängigkeiten der großen Partitur.
$(piece).pdf: $(piece).ly $(notes)

# Abhängigkeiten der Stimmen.
$(piece)-cello.pdf: $(piece)-cello.ly cello.ily
$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily

# `make score' eintippen, um die große Partitur mit allen vier
# Sätzen als eine Datei zu erstellen.
.PHONY: score
score: $(piece).pdf

# `make parts' tippen, um alle Stimmen zu erstellen.
# `make foo.pdf' tippen, um die Stimme für das Instrument `foo' zu erstellen.
# Beispiel: `make symphony-cello.pdf'.
.PHONY: parts
parts: $(piece)-cello.pdf \
       $(piece)-violinOne.pdf \
       $(piece)-violinTwo.pdf \
       $(piece)-viola.pdf \
       $(piece)-oboes.pdf \
       $(piece)-horn.pdf

# `make movements' tippen um Dateien für die vier Sätze einzeln zu erstellen.
.PHONY: movements
movements: $(piece)I.pdf \
           $(piece)II.pdf \
           $(piece)III.pdf \
           $(piece)IV.pdf

all: score parts movements

archive:
        tar -cvvf stamitz.tar \       # this line begins with a tab
        --exclude=*pdf --exclude=*~ \
        --exclude=*midi --exclude=*.tar \
        ../Stamitz/*
@end example

Unter Windows ergeben sich bestimmte Komplikationen.  Nachdem man
GNU Make für Windows heruntergeladen und installiert hat, muss
man den richtigen Pfad in den Umgebungsvariablen des Systems setzen,
damit die DOS-Kommandozeile das Make-Programm finden kann.  Um das
vorzunehmen, kann mit der rechten Maustaste auf "Arbeitsplatz"
klicken, dann @code{Eigenschaften} und @code{Erweitert} geklickt
werden.  Hier wählt man @code{Umgebungsvariablen}.  In der
Liste @code{Systemvariablen} wählt man @code{Path} und mit 
einem Klick auf @code{Bearbeiten} kann man den Pfad zu der
@code{.exe}-Datei von GNU Make hinzufügen, der etwa wie
folgt aussieht:

@example
C:\Program Files\GnuWin32\bin
@end example

Die Make-Datei selber muss auch angepasst werden, um unterschiedliche
Shell-Befehle zu verwenden und mit Leerzeichen umgehen zu können,
die sich in einigen Standardverzeichnissen unter Windows befinden.
Das @code{archive}-Ziel wird entfernt, da Windows den
@code{tar}-Befehl nicht kennt, und Windows benutzt auch eine
andere Dateiendung für midi-Dateien.


@example
## WINDOWS VERSION
##
piece = symphony
LILY_CMD = lilypond -ddelete-intermediate-files \
                    -dno-point-and-click \
                    -djob-count=$(NUMBER_OF_PROCESSORS)

# 8.3 Bezeichnung für CURDIR erhalten (Workaround wg. Leerzeichen in PATH)
workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
          do @@echo %%~sb)

.SUFFIXES: .ly .ily .pdf .mid

VPATH = \
  $(workdir)/Scores \
  $(workdir)/PDF \
  $(workdir)/Parts \
  $(workdir)/Notes

%.pdf %.mid: %.ly
        $(LILY_CMD) $<      # diese Zeile beginnt mit Tabulator
        if exist "$*.pdf"  move /Y "$*.pdf"  PDF/ # begin with tab
        if exist "$*.mid" move /Y "$*.mid" MIDI/  # begin with tab

notes = \
  cello.ily \
  figures.ily \
  horn.ily \
  oboe.ily \
  trioString.ily \
  viola.ily \
  violinOne.ily \
  violinTwo.ily

$(piece)I.pdf: $(piece)I.ly $(notes)
$(piece)II.pdf: $(piece)II.ly $(notes)
$(piece)III.pdf: $(piece)III.ly $(notes)
$(piece)IV.pdf: $(piece)IV.ly $(notes)

$(piece).pdf: $(piece).ly $(notes)

$(piece)-cello.pdf: $(piece)-cello.ly cello.ily
$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily

.PHONY: score
score: $(piece).pdf

.PHONY: parts
parts: $(piece)-cello.pdf \
       $(piece)-violinOne.pdf \
       $(piece)-violinTwo.pdf \
       $(piece)-viola.pdf \
       $(piece)-oboes.pdf \
       $(piece)-horn.pdf

.PHONY: movements
movements: $(piece)I.pdf \
           $(piece)II.pdf \
           $(piece)III.pdf \
           $(piece)IV.pdf

all: score parts movements
@end example

Die nächste Make-Datei ist für ein @command{lilypond-book}-Dokument,
das in LaTeX gesetzt wird.  Das Projekt hat einen Index, welcher
erfordert, dass der Befehl @command{latex} zweimal aufgerufen wird,
um die Verweise zu aktualisieren.  Ausgabedateien werden in einem
@code{out}-Verzeichnis für die .pdf-Dateien gespeichert und in
@code{htmlout} für die html-Dateien.

@example
SHELL=/bin/sh
FILE=myproject
OUTDIR=out
WEBDIR=htmlout
VIEWER=acroread
BROWSER=firefox
LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
PDF=cd $(OUTDIR) && pdflatex $(FILE)
HTML=cd $(WEBDIR) && latex2html $(FILE)
INDEX=cd $(OUTDIR) && makeindex $(FILE)
PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &

all: pdf web keep

pdf:
        $(LILYBOOK_PDF)  # begin with tab
        $(PDF)           # begin with tab
        $(INDEX)         # begin with tab
        $(PDF)           # begin with tab
        $(PREVIEW)       # begin with tab

web:
        $(LILYBOOK_HTML) # begin with tab
        $(HTML)          # begin with tab
        cp -R $(WEBDIR)/$(FILE)/ ./  # begin with tab
        $(BROWSER) $(FILE)/$(FILE).html &  # begin with tab

keep: pdf
        cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf  # begin with tab

clean:
        rm -rf $(OUTDIR) # begin with tab

web-clean:
        rm -rf $(WEBDIR) # begin with tab

archive:
        tar -cvvf myproject.tar \ # begin this line with tab
        --exclude=out/* \
        --exclude=htmlout/* \
        --exclude=myproject/* \
        --exclude=*midi \
        --exclude=*pdf \
        --exclude=*~ \
        ../MyProject/*
@end example

TODO: soll auch unter Windows funktionieren

Die vorige Make-Datei funktioniert nicht unter Windows.  Als Alternative
für Windows-Benutzer könnte man eine einfache batch-Datei erstellen,
welche die erforderlichen Befehl enthält.  Sie kümmert sich nicht
um Abhängigkeiten, wie es eine Make-Datei kann, aber wenigstens
wird die Kompilation auf einen einzigen Befehl beschränkt.  Das folgende
kann als Datei @command{build.bat} oder @command{build.cmd} gespeichert
werden.  Die Batch-Datei kann auf der Kommandozeile aufgerufen werden
oder einfach doppelt angeklickt werden.

@example
lilypond-book --output=out --pdf myproject.lytex
cd out
pdflatex myproject
makeindex myproject
pdflatex myproject
cd ..
copy out\myproject.pdf MyProject.pdf
@end example


@seealso
Programmbenutzung:
@rprogram{Einrichtung für MacOS X},
@rprogram{Benutzung auf der Kommandozeile},
@rprogram{LilyPond-book}