X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=Documentation%2Fde%2Fusage%2Fsuggestions.itely;h=44b985f87c13ac7e8049b7f1421634ef1b826b44;hb=7ba0a22641cb0c7f5949d66a06d1e2e1fd0b3033;hp=263a80b0016b8dded32121a059dcc974435f89a4;hpb=f5387a5c986393052bc9443ebd9b6cd9f14c6887;p=lilypond.git

diff --git a/Documentation/de/usage/suggestions.itely b/Documentation/de/usage/suggestions.itely
index 263a80b001..44b985f87c 100644
--- a/Documentation/de/usage/suggestions.itely
+++ b/Documentation/de/usage/suggestions.itely
@@ -1,55 +1,638 @@
 @c -*- coding: utf-8; mode: texinfo; -*-
 
 @ignore
-    Translation of GIT committish: 2aa0be0f17d01f731649bf864ee41117ad20dd7c
+    Translation of GIT committish: ab9e3136d78bfaf15cc6d77ed1975d252c3fe506
 
     When revising a translation, copy the HEAD committish of the
     version that you are working on.  For details, see the Contributors'
     Guide, node Updating translation committishes..
 @end ignore
 
-@c \version "2.12.0"
+@c \version "2.13.36"
 
-@node Vorschläge, wie man Dateien schreibt
-@chapter Vorschläge, wie man Dateien schreibt
-@translationof Suggestions for writing files
+@node Vorschläge zum Schreiben von LilyPond-Eingabe-Dateien
+@chapter Vorschläge zum Schreiben von LilyPond-Eingabe-Dateien
+@translationof Suggestions for writing LilyPond input files
 
-@untranslated
+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
-* General suggestions::
-* Typesetting existing music::
-* Large projects::
-* Troubleshooting::
-* Make and Makefiles::
+* Allgemeine Vorschläge::
+* Das Kopieren von bereits vorhandener Musik::
+* Große Projekte::
+* Problemlösung::
+* Make und Makefiles::
 @end menu
 
 
-@node General suggestions
-@section General suggestions
+@node Allgemeine Vorschläge
+@section Allgemeine Vorschläge
+@translationof General suggestions
+
+Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:
+
+@itemize
+@item @strong{Schreiben Sie immer mit @code{\version} die
+Versionsnummer
+in jede Datei}.  Beachten Sie, dass in allen Vorlagen die Versionsnummer
+@code{\version "2.13.36"} 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{@{} und
+@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 @rlearning{Tipparbeit durch Variablen und Funktionen ersparen}
+und
+@rlearning{Globale Formatierung}.
+
+@end itemize
+
+
+@node Das Kopieren von bereits vorhandener Musik
+@section 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
+
+@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
+@section 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
+
+@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 früher 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 Fehlersuche
+@section Fehlersuche
+@translationof Troubleshooting
+
+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,
+@rweb{Minimalbeispiele} zu konstruieren.
+
+
+
+@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
+@file{ballad.pdf} und @file{ballad.midi} aus @file{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 @file{.ly}-Dateien un den Verzeichnissen @code{Scores} und
+@code{Parts} erhalten ihrere Noten aus @file{.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 &
 
-@untranslated
+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
 
-@node Typesetting existing music
-@section Typesetting existing music
+web:
+        $(LILYBOOK_HTML) # begin with tab
+        $(HTML)          # begin with tab
+        cp -R $(WEBDIR)/$(FILE)/ ./  # begin with tab
+        $(BROWSER) $(FILE)/$(FILE).html &  # begin with tab
 
-@untranslated
+keep: pdf
+        cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf  # begin with tab
 
+clean:
+        rm -rf $(OUTDIR) # begin with tab
 
-@node Large projects
-@section Large projects
+web-clean:
+        rm -rf $(WEBDIR) # begin with tab
 
-@untranslated
+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
 
-@node Troubleshooting
-@section Troubleshooting
+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.
 
-@untranslated
+@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
 
 
-@node Make and Makefiles
-@section Make and Makefiles
+@seealso
+Programmbenutzung:
+@rprogram{Benutzung auf der Kommandozeile},
+@rprogram{lilypond-book}.
 
-@untranslated