1 @c -*- coding: utf-8; mode: texinfo; -*-
4 Translation of GIT committish: 0764a50d470cab82ca29da30298dacd333d3da12
6 When revising a translation, copy the HEAD committish of the
7 version that you are working on. For details, see the Contributors'
8 Guide, node Updating translation committishes..
13 @node Vorschläge zum Schreiben von LilyPond-Eingabe-Dateien
14 @chapter Vorschläge zum Schreiben von LilyPond-Eingabe-Dateien
15 @translationof Suggestions for writing LilyPond input files
17 Jetzt sind Sie so weit, größere Stücke mit LilyPond zu schreiben --
18 nicht nur die kleinen Beispiele aus der Übung, sondern ganze Stücke.
19 Aber wie geht man das am besten an?
21 Solange LilyPond Ihre Dateien versteht und die Noten so setzt,
22 wie Sie das wollen, spielt es eigentlich keine Rolle, wie Ihre
23 Dateien aussehen. Es gibt aber trotzdem ein paar Dinge, die man
24 beim Schreiben von LilyPond-Code berücksichtigen sollte.
27 @item Was ist, wenn Sie einen Fehler machen? Die Struktur einer
28 LilyPond-Datei kann es erleichtern (oder erschweren), bestimmte
31 @item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen
32 wollen? Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten
33 wollen? Manche LilyPond-Dateien versteht man auf den ersten Blick,
34 über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.
36 @item Was ist, wenn sie Ihre Dateien auf eine neuere LilyPond-Version
37 aktualisieren wollen? Die Syntax der Eingabesprache verändert sich
38 allmählich mit Verbesserungen im Programm. Die meisten Veränderungen
39 können automatisch durch @code{convert-ly} gelöst werden, aber
40 bestimmte Änderungen brauchen Handarbeit. LilyPond-Dateien können
41 strukturiert werden, damit sie einfacher aktualisierbar sind.
45 * Allgemeine Vorschläge::
46 * Das Kopieren von bereits vorhandener Musik::
49 * Make und Makefiles::
53 @node Allgemeine Vorschläge
54 @section Allgemeine Vorschläge
55 @translationof General suggestions
57 Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:
60 @item @strong{Schreiben Sie immer mit @code{\version} die
62 in jede Datei}. Beachten Sie, dass in allen Vorlagen die Versionsnummer
63 @code{\version "2.14.0"} eingetragen ist. Es empfiehlt sich, in alle
64 Dateien, unabhängig von ihrer Größe, den @code{\version}-Befehl
65 einzufügen. Persönliche Erfahrung hat gezeigt, dass es ziemlich
66 frustrierend sein kann zu erinnern, welche Programmversion man etwa
67 vor einem Jahr verwendet hat. Auch @code{convert-ly} benötigt die
70 @item @strong{Benutzen Sie Überprüfungen}: @ruser{Oktavenüberprüfung}, und
71 @ruser{Takt- und Taktzahlüberprüfung}. Wenn Sie hier und da diese
72 Überprüfungen einfügen, finden Sie einen möglichen Fehler weit
73 schneller. Wie oft aber ist @qq{hier und da}? Das hängt von der
74 Komplexität der Musik ab. ei einfachen Stücken reicht es vielleicht
75 ein- oder zweimal, in sehr komplexer Musik sollte man sie vielleicht
76 in jeden Takt einfügen.
78 @item @strong{Ein Takt pro Textzeile}. Wenn irgendetwas kompliziertes
79 vorkommt, entweder in der Musik selber oder in der Anpassung der
81 empfiehlt es sich oft, nur einen Takt pro Zeile zu schreiben.
82 Bildschirmplatz zu sparen, indem Sie acht Takte in eine Zeile zwängen,
83 hilft nicht weiter, wenn Sie ihre Datei @qq{debuggen} müssen.
85 @item @strong{Kommentieren Sie ihre Dateien}. Benutzen Sie entweder
86 Taktnummern (in regelmäßigen Abständen) oder Verweise auf musikalische
87 Themen (@qq{Zweites Thema in den Geigen}, @qq{vierte Variation} usw.).
88 Sie brauchen diese Kommentare vielleicht noch nicht, wenn Sie das Stück
89 notieren, aber spätestens wenn Sie nach ein paar Jahren etwas
91 wollen oder Sie den Quelltext an einen Freund weitergeben wollen,
92 ist es weitaus komplizierter, die Dateistruktur ohne Kommentare zu
93 verstehen, als wenn Sie sie rechtzeitig eingefügt hätten.
95 @item @strong{Schreiben Sie Klammern mit Einrückung}. Viele
96 Probleme entstehen durch ungerade Anzahl von @code{@{} und
99 @item @strong{Schreiben Sie Tondauerangaben} am Anfang von
100 Abschnitten und Bezeichnern. Wenn Sie beispielsweise
101 @code{c4 d e} am Anfang eines Abschnittes schreiben,
102 ersparen Sie sich viele Probleme, wenn Sie ihre Musik
103 eines Tages umarrangieren wollen.
105 @item @strong{Trennen Sie Einstellungen} von den eigentlichen
106 Noten. Siehe auch @rlearning{Tipparbeit durch Variablen und Funktionen ersparen}
108 @rlearning{Globale Formatierung}.
113 @node Das Kopieren von bereits vorhandener Musik
114 @section Das Kopieren von bereits vorhandener Musik
115 @translationof Typesetting existing music
117 Wenn Sie Musik aus einer fertigen Partitur kopieren (z. B. die
118 LilyPond-Eingabe einer gedruckten Partitur):
123 Schreiben Sie ein System ihrer Quelle nach dem anderen
124 (aber trotzdem nur einen Takt pro Textzeile) und überprüfen
125 Sie jedes System, nachdem Sie es fertig kopiert haben. Mit dem
126 @code{showLastLength}- oder @code{showFirstLenght}-Befehl können Sie den Übersetzungsprozess
127 beschleunigen. Siehe auch
128 @ruser{Korrigierte Musik überspringen}.
131 Definieren Sie @code{mBreak = @{ \break @}} und schreiben Sie
132 @code{\mBreak} in der Quelldatei immer dann, wenn im Manuskript
133 ein Zeilenumbruch vorkommt. Das macht es einfacher, die gesetzte
134 Zeile mit den ursprünglichen Noten zu vergleichen. Wenn Sie die
135 Partitur fertig gestellt haben, könne Sie @code{mBreak = @{ @}},
136 also leer definieren, um diese manuellen Zeilenumbrüche zu entfernen.
137 Damit kann dann LilyPond selber entscheiden, wohin es passende
138 Zeilenumbrüche platziert.
141 Wenn Sie eine Stimme für ein transponierendes Instrument als eine
142 Variable notieren, wird empfohlen, dass die Noten von
145 \transpose c klingende-Tonhöhe @{...@}
148 eingefasst werden (wobei @code{klingende-Tonhöhe} die klingende Tonhöhe
149 des Instruments ist), sodass die Noten innerhalb der Variable für klingendes C
150 geschrieben sind. Sie können die Variable zurücktransponieren, wenn es
151 nötig ist, aber Sie müssen es nicht tun. Fehler in Transpositionen sind
152 treten seltener auf, wenn alle Noten in den Variablen für die gleiche
153 Ausgangstonhöhe geschrieben werden.
155 Denken Sie auch daran, dass Sie nur von/nach C transponieren. Das heißt,
156 dass die einzigen anderen Tonhöhen, die Sie in Transpositionen benutzen,
157 die Tonhöhen der Instrumente sind, für die Sie schreiben: @code{bes} für
158 eine B-Trompete oder @code{aes} für eine As-Klarinette usw.
164 @section Große Projekte
165 @translationof Large projects
167 Besonders wenn Sie an größeren Projekten arbeiten, ist es
168 unumgänglich, dass Sie ihre LilyPond-Dateien klar strukturieren.
172 @item @strong{Verwenden Sie Variablen für jede Stimme}, innerhalb
173 der Definition sollte so wenig Struktur wie möglich sein. Die
174 Struktur des @code{\score}-Abschnittes verändert sich am ehesten,
175 während die @code{violine}-Definition sich wahrscheinlich mit einer
176 neuen Programmversion nicht verändern wird.
179 violine = \relative c'' @{
192 @item @strong{Trennen Sie Einstellungen von den Noten}. Diese
193 Empfehlung wurde schon früher gegeben,
194 aber für große Projekte ist es unumgänglich. Muss z. B. die
195 Definition für @code{fdannp} verändert werden, so braucht
196 man es nur einmal vorzunehmen und die Noten in der Geigenstimme,
197 @code{violin}, bleiben unberührt.
201 \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
202 violin = \relative c'' @{
213 @translationof Troubleshooting
215 Früher oder später werden Sie in die Lage kommen,
216 dass LilyPond Ihre Datei nicht kompilieren will. Die
217 Information, die LilyPond während der Übersetzung
218 gibt, können Ihnen helfen, den Fehler zu finden, aber
219 in vielen Fällen müssen Sie nach der Fehlerquelle
222 Die besten Hilfsmittel sind in diesem Fall das Zeilen-
223 und Blockkommentar (angezeigt durch @code{%} bzw.
224 @code{%@{ ... %@}}). Wenn Sie nicht bestimmen können,
225 wo sich das Problem befindet, beginnen Sie damit, große
226 Teile des Quelltextes auszukommentieren. Nachdem Sie
227 einen Teil auskommentiert haben, versuchen Sie, die Datei
228 erneut zu übersetzen. Wenn es jetzt funktioniert, muss
229 sich das Problem innerhalb der Kommentare befinden.
230 Wenn es nicht funktioniert, müssen Sie weitere Teile
231 auskommentieren bis sie eine Version haben, die funktioniert.
233 In Extremfällen bleibt nur noch solch ein Beispiel übrig:
247 (also eine Datei ohne Noten).
249 Geben Sie nicht auf, wenn das vorkommen sollte. Nehmen
250 Sie das Kommentarzeichen von einem Teil wieder weg, sagen
251 wir der Bassstimme, und schauen Sie, ob es funktioniert.
252 Wenn nicht, dann kommentieren Sie die gesamte Bassstimme
253 aus, aber nicht den @code{\bass}-Befehl in dem
254 @code{\score}-Abschnitt:
257 bass = \relative c' @{
265 Jetzt beginnen Sie damit, langsam Stück für Stück der
266 Bassstimme wieder hineinzunehmen, bis Sie die problematische
269 Eine andere nützliche Technik zur Problemlösung ist es,
270 @rweb{Minimalbeispiele} zu konstruieren.
274 @node Make und Makefiles
275 @section Make und Makefiles
276 @translationof Make and Makefiles
282 Fast alle Betriebssysteme, auf denen LilyPond benutzt werden kann,
283 unterstützen ein Programm mit dem Namen @code{make}. Dieses Programm
284 liest eine besondere Datei mit der Bezeichnung @code{Makefile},
285 die definiert, welche Dateien von welchen anderen Dateien abhängen und
286 welche Befehle für das Betriebssystem nötig sind, um eine Datei aus
287 einer anderen zu erstellen. Ein Makefile könnte etwa erklären, wie
288 @file{ballad.pdf} und @file{ballad.midi} aus @file{ballad.ly}
289 erstellt werden können, indem LilyPond aufgerufen wird.
291 Es gibt Fällen, wenn es sich sehr stark empfiehlt, ein @code{Makefile}
292 für das aktuelle Projekt zu erstellen, entweder zur eigenen Bequemlichkeit,
293 oder aber auch als Hilfe für andere, die vielleicht einmal die
294 Quelldateien lesen und verstehen wollen. Insbesondere bei großen Projekten
295 mit vielen eingefügten Dateien und unterschiedlichen Ausgabeoptionen
296 (etwa Partitur, einzelne Stimmen, Dirigierpartitur, Klavierauszug usw.),
297 aber auch bei Projekten, die komplizierte Programmaufrufe zur Verarbeitung
298 erfordern (wenn man etwa mit @code{lilypond-book} arbeitet), lohnt
299 sich die Erstellung einer Make-Datei. Diese Dateien können sehr
300 unterschiedliche ausfallen, und ihre Komplexität und Flexibilität kann
301 den Bedürfnissen aber auch Kenntnissen des Schreibers angepasst werden.
302 Das Programm GNU Make ist auf GNU/Linux Distributionen und MacOS X
303 installiert, aber es ist auch für Windows erhältlich.
305 Das @strong{GNU Make Manual} gibt eine vollständige Anleitung, wie
306 @code{make} benutzt werden kann. Hier sollen nur einige kleine
307 Blicke auf die vielfältigen Möglichkeiten geworfen werden.
309 Die Befehle, um Regeln in einer Make-Datei zu erstellen, unterscheidet
310 sich zwischen den Betriebssystemen. Die verschiedenen Linuxe und
311 MacOS X benutzen @code{bash}, während unter Windows @code{cmd} eingesetzt
312 wird. Unter MacOS X muss man das System so konfigurieren, dass
313 die Kommandozeile benutzt wird. Hier einige Beispiele für Make-Dateien,
314 mit Versionen für Linux/MacOS und Windows.
316 Das erste Beispiel ist für ein Orchesterstück in vier Stätzen unt mit
317 der folgenden Dateistruktur:
334 | |-- symphony-cello.ly
335 | |-- symphony-horn.ly
336 | |-- symphony-oboes.ly
337 | |-- symphony-viola.ly
338 | |-- symphony-violinOne.ly
339 | `-- symphony-violinTwo.ly
349 Die @file{.ly}-Dateien un den Verzeichnissen @file{Scores} und
350 @file{Parts} erhalten ihrere Noten aus @file{.ily}-Dateien, die
351 sich im @file{Notes}-Verzeichnis befinden:
354 %%% Kopfzeile der Datei "symphony-cello.ly"
355 \include ../definitions.ily
356 \include ../Notes/cello.ily
359 Die Make-Datei hat die Ziele @code{score} (das gesamte Stück als
360 große Partitur), @code{movements} (die einzelnen Sätze als große
361 Partitur) und @code{parts} (die einzelnen Stimmen für die Spieler).
362 Es gibt auch das Ziel @code{archive}, welches ein Tar-Archiv
363 der Quelldateien erstellt, etwa um die Quellen über das Internet
364 oder per E-Mail zu verteilen. Hier die Make-Datei für GNU/Linux
365 oder MacOS X. Sie sollte unter dem Namen @code{Makefile} im obersten
366 Verzeichnis des Projektes gespeichert werden:
368 @warning{Wenn ein Ziel oder eine Musterregel definiert ist, müssen
369 die folgenden Zeilen mit Tabulatoren, nicht mit Leerzeichen beginnen.}
372 # Namensstamm der Ausgabedateien
374 # finde heraus, wieviele Prozessoren vorhanden sind
375 CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
376 # Der Befehl, um lilypond aufzurufen
377 LILY_CMD = lilypond -ddelete-intermediate-files \
378 -dno-point-and-click -djob-count=$(CPU_CORES)
380 # Die Endungen, die im Makefile benutzt werden
381 .SUFFIXES: .ly .ily .pdf .midi
383 # Eingabe- und Ausgabedateien werden in den Verzeichnissen durchsucht,
384 # die sich in der VPATH-Variable befinden. Alle sind Unterverzeichnisse
385 # des aktuellen Verzeichnisses (angegeben durch die GNU make-Variable
393 # Die Musterregel, um PDF und MIDI-Dateien aus der LY-Eingabedatei
394 # zu erstellen. Die .pdf-Ausgabedateien werden in das
395 # `PDF'-Unterverzeichnis abgelegt, die .midi-Dateien in das
396 # `MIDI'-Unterverzeichnis.
398 $(LILY_CMD) $<; \ # this line begins with a tab
399 if test -f "$*.pdf"; then \
402 if test -f "$*.midi"; then \
403 mv "$*.midi" MIDI/; \
414 # Abhängigkeiten der einzelnen Sätze.
415 $(piece)I.pdf: $(piece)I.ly $(notes)
416 $(piece)II.pdf: $(piece)II.ly $(notes)
417 $(piece)III.pdf: $(piece)III.ly $(notes)
418 $(piece)IV.pdf: $(piece)IV.ly $(notes)
420 # Abhängigkeiten der großen Partitur.
421 $(piece).pdf: $(piece).ly $(notes)
423 # Abhängigkeiten der Stimmen.
424 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
425 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
426 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
427 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
428 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
429 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
431 # `make score' eintippen, um die große Partitur mit allen vier
432 # Sätzen als eine Datei zu erstellen.
436 # `make parts' tippen, um alle Stimmen zu erstellen.
437 # `make foo.pdf' tippen, um die Stimme für das Instrument `foo' zu erstellen.
438 # Beispiel: `make symphony-cello.pdf'.
440 parts: $(piece)-cello.pdf \
441 $(piece)-violinOne.pdf \
442 $(piece)-violinTwo.pdf \
447 # `make movements' tippen um Dateien für die vier Sätze einzeln zu erstellen.
449 movements: $(piece)I.pdf \
454 all: score parts movements
457 tar -cvvf stamitz.tar \ # this line begins with a tab
458 --exclude=*pdf --exclude=*~ \
459 --exclude=*midi --exclude=*.tar \
463 Unter Windows ergeben sich bestimmte Komplikationen. Nachdem man
464 GNU Make für Windows heruntergeladen und installiert hat, muss
465 man den richtigen Pfad in den Umgebungsvariablen des Systems setzen,
466 damit die DOS-Kommandozeile das Make-Programm finden kann. Um das
467 vorzunehmen, kann mit der rechten Maustaste auf "Arbeitsplatz"
468 klicken, dann @code{Eigenschaften} und @code{Erweitert} geklickt
469 werden. Hier wählt man @code{Umgebungsvariablen}. In der
470 Liste @code{Systemvariablen} wählt man @code{Path} und mit
471 einem Klick auf @code{Bearbeiten} kann man den Pfad zu der
472 @code{.exe}-Datei von GNU Make hinzufügen, der etwa wie
476 C:\Program Files\GnuWin32\bin
479 Die Make-Datei selber muss auch angepasst werden, um unterschiedliche
480 Shell-Befehle zu verwenden und mit Leerzeichen umgehen zu können,
481 die sich in einigen Standardverzeichnissen unter Windows befinden.
482 Das @code{archive}-Ziel wird entfernt, da Windows den
483 @code{tar}-Befehl nicht kennt, und Windows benutzt auch eine
484 andere Dateiendung für midi-Dateien.
491 LILY_CMD = lilypond -ddelete-intermediate-files \
492 -dno-point-and-click \
493 -djob-count=$(NUMBER_OF_PROCESSORS)
495 # 8.3 Bezeichnung für CURDIR erhalten (Workaround wg. Leerzeichen in PATH)
496 workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
499 .SUFFIXES: .ly .ily .pdf .mid
508 $(LILY_CMD) $< # diese Zeile beginnt mit Tabulator
509 if exist "$*.pdf" move /Y "$*.pdf" PDF/ # begin with tab
510 if exist "$*.mid" move /Y "$*.mid" MIDI/ # begin with tab
522 $(piece)I.pdf: $(piece)I.ly $(notes)
523 $(piece)II.pdf: $(piece)II.ly $(notes)
524 $(piece)III.pdf: $(piece)III.ly $(notes)
525 $(piece)IV.pdf: $(piece)IV.ly $(notes)
527 $(piece).pdf: $(piece).ly $(notes)
529 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
530 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
531 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
532 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
533 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
534 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
540 parts: $(piece)-cello.pdf \
541 $(piece)-violinOne.pdf \
542 $(piece)-violinTwo.pdf \
548 movements: $(piece)I.pdf \
553 all: score parts movements
556 Die nächste Make-Datei ist für ein @command{lilypond-book}-Dokument,
557 das in LaTeX gesetzt wird. Das Projekt hat einen Index, welcher
558 erfordert, dass der Befehl @command{latex} zweimal aufgerufen wird,
559 um die Verweise zu aktualisieren. Ausgabedateien werden in einem
560 @code{out}-Verzeichnis für die .pdf-Dateien gespeichert und in
561 @code{htmlout} für die html-Dateien.
570 LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
571 LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
572 PDF=cd $(OUTDIR) && pdflatex $(FILE)
573 HTML=cd $(WEBDIR) && latex2html $(FILE)
574 INDEX=cd $(OUTDIR) && makeindex $(FILE)
575 PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &
580 $(LILYBOOK_PDF) # begin with tab
581 $(PDF) # begin with tab
582 $(INDEX) # begin with tab
583 $(PDF) # begin with tab
584 $(PREVIEW) # begin with tab
587 $(LILYBOOK_HTML) # begin with tab
588 $(HTML) # begin with tab
589 cp -R $(WEBDIR)/$(FILE)/ ./ # begin with tab
590 $(BROWSER) $(FILE)/$(FILE).html & # begin with tab
593 cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf # begin with tab
596 rm -rf $(OUTDIR) # begin with tab
599 rm -rf $(WEBDIR) # begin with tab
602 tar -cvvf myproject.tar \ # begin this line with tab
604 --exclude=htmlout/* \
605 --exclude=myproject/* \
612 TODO: soll auch unter Windows funktionieren
614 Die vorige Make-Datei funktioniert nicht unter Windows. Als Alternative
615 für Windows-Benutzer könnte man eine einfache batch-Datei erstellen,
616 welche die erforderlichen Befehl enthält. Sie kümmert sich nicht
617 um Abhängigkeiten, wie es eine Make-Datei kann, aber wenigstens
618 wird die Kompilation auf einen einzigen Befehl beschränkt. Das folgende
619 kann als Datei @command{build.bat} oder @command{build.cmd} gespeichert
620 werden. Die Batch-Datei kann auf der Kommandozeile aufgerufen werden
621 oder einfach doppelt angeklickt werden.
624 lilypond-book --output=out --pdf myproject.lytex
630 copy out\myproject.pdf MyProject.pdf
636 @rprogram{Benutzung auf der Kommandozeile},
637 @rprogram{lilypond-book}.