1 @c -*- coding: utf-8; mode: texinfo; documentlanguage: de -*-
4 Translation of GIT committish: d96023d8792c8af202c7cb8508010c0d3648899d
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 An LilyPond-Projekten arbeiten
14 @chapter An LilyPond-Projekten arbeiten
15 @translationof Working on LilyPond projects
17 Dieses Kapitel erklärt, wie bestimmte häufige Probleme zu
18 lösen oder ganz zu vermeiden sind. Wenn Sie schon
19 Programmiererfahrung mitbringen, erscheinen diese Hinweise
20 vielleicht überflüssig, aber es wird dennoch empfohlen, dieses Kapitel
25 * Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen::
26 * Wenn etwas nicht funktioniert::
27 * Partituren und Stimmen::
28 * Make und Makefiles::
32 @node Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen
33 @section Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen
34 @translationof Suggestions for writing LilyPond input files
36 Jetzt sind Sie so weit, größere Stücke mit LilyPond zu schreiben --
37 nicht nur die kleinen Beispiele aus der Übung, sondern ganze Stücke.
38 Aber wie geht man das am besten an?
40 Solange LilyPond Ihre Dateien versteht und die Noten so setzt,
41 wie Sie das wollen, spielt es eigentlich keine Rolle, wie Ihre
42 Dateien aussehen. Es gibt aber trotzdem ein paar Dinge, die man
43 beim Schreiben von LilyPond-Code berücksichtigen sollte.
46 @item Was ist, wenn Sie einen Fehler machen? Die Struktur einer
47 LilyPond-Datei kann es erleichtern (oder erschweren), bestimmte
50 @item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen
51 wollen? Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten
52 wollen? Manche LilyPond-Dateien versteht man auf den ersten Blick,
53 über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.
55 @item Was ist, wenn sie Ihre Dateien auf eine neuere LilyPond-Version
56 aktualisieren wollen? Die Syntax der Eingabesprache verändert sich
57 allmählich mit Verbesserungen im Programm. Die meisten Veränderungen
58 können automatisch durch @code{convert-ly} gelöst werden, aber
59 bestimmte Änderungen brauchen Handarbeit. LilyPond-Dateien können
60 strukturiert werden, damit sie einfacher aktualisierbar sind.
64 * Allgemeine Vorschläge::
65 * Das Kopieren von bereits vorhandener Musik::
67 * Tipparbeit sparen durch Bezeichner und Funktionen::
72 @node Allgemeine Vorschläge
73 @subsection Allgemeine Vorschläge
74 @translationof General suggestions
76 Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:
79 @item @strong{Schreiben Sie immer mit @code{\version} die
81 in jede Datei}. Beachten Sie, dass in allen Vorlagen die Versionsnummer
82 @code{\version "2.12.0"} eingetragen ist. Es empfiehlt sich, in alle
83 Dateien, unabhängig von ihrer Größe, den @code{\version}-Befehl
84 einzufügen. Persönliche Erfahrung hat gezeigt, dass es ziemlich
85 frustrierend sein kann zu erinnern, welche Programmversion man etwa
86 vor einem Jahr verwendet hat. Auch @code{convert-ly} benötigt die
89 @item @strong{Benutzen Sie Überprüfungen}: @ruser{Oktavenüberprüfung}, und
90 @ruser{Takt- und Taktzahlüberprüfung}. Wenn Sie hier und da diese
91 Überprüfungen einfügen, finden Sie einen möglichen Fehler weit
92 schneller. Wie oft aber ist @qq{hier und da}? Das hängt von der
93 Komplexität der Musik ab. ei einfachen Stücken reicht es vielleicht
94 ein- oder zweimal, in sehr komplexer Musik sollte man sie vielleicht
95 in jeden Takt einfügen.
97 @item @strong{Ein Takt pro Textzeile}. Wenn irgendetwas kompliziertes
98 vorkommt, entweder in der Musik selber oder in der Anpassung der
100 empfiehlt es sich oft, nur einen Takt pro Zeile zu schreiben.
101 Bildschirmplatz zu sparen, indem Sie acht Takte in eine Zeile zwängen,
102 hilft nicht weiter, wenn Sie ihre Datei @qq{debuggen} müssen.
104 @item @strong{Kommentieren Sie ihre Dateien}. Benutzen Sie entweder
105 Taktnummern (in regelmäßigen Abständen) oder Verweise auf musikalische
106 Themen (@qq{Zweites Thema in den Geigen}, @qq{vierte Variation} usw.).
107 Sie brauchen diese Kommentare vielleicht noch nicht, wenn Sie das Stück
108 notieren, aber spätestens wenn Sie nach ein paar Jahren etwas
110 wollen oder Sie den Quelltext an einen Freund weitergeben wollen,
111 ist es weitaus komplizierter, die Dateistruktur ohne Kommentare zu
112 verstehen, als wenn Sie sie rechtzeitig eingefügt hätten.
114 @item @strong{Schreiben Sie Klammern mit Einrückung}. Viele
115 Probleme entstehen durch ungerade Anzahl von @code{@{} and
118 @item @strong{Schreiben Sie Tondauerangaben} am Anfang von
119 Abschnitten und Bezeichnern. Wenn Sie beispielsweise
120 @code{c4 d e} am Anfang eines Abschnittes schreiben,
121 ersparen Sie sich viele Probleme, wenn Sie ihre Musik
122 eines Tages umarrangieren wollen.
124 @item @strong{Trennen Sie Einstellungen} von den eigentlichen
125 Noten. Siehe auch @ref{Tipparbeit sparen durch Bezeichner und Funktionen}
132 @node Das Kopieren von bereits vorhandener Musik
133 @subsection Das Kopieren von bereits vorhandener Musik
134 @translationof Typesetting existing music
136 Wenn Sie Musik aus einer fertigen Partitur kopieren (z. B. die
137 LilyPond-Eingabe einer gedruckten Partitur):
141 @item Schreiben Sie ein System ihrer Quelle nach dem anderen
142 (aber trotzdem nur einen Takt pro Textzeile) und überprüfen
143 Sie jedes System, nachdem Sie es fertig kopiert haben. Mit dem
144 @code{showLastLength}- oder @code{showFirstLenght}-Befehl können Sie den Übersetzungsprozess
145 beschleunigen. Siehe auch
146 @ruser{Korrigierte Musik überspringen}.
148 @item Definieren Sie @code{mBreak = @{ \break @}} und schreiben Sie
149 @code{\mBreak} in der Quelldatei immer dann, wenn im Manuskript
150 ein Zeilenumbruch vorkommt. Das macht es einfacher, die gesetzte
151 Zeile mit den ursprünglichen Noten zu vergleichen. Wenn Sie die
152 Partitur fertig gestellt haben, könne Sie @code{mBreak = @{ @}},
153 also leer definieren, um diese manuellen Zeilenumbrüche zu entfernen.
154 Damit kann dann LilyPond selber entscheiden, wohin es passende
155 Zeilenumbrüche platziert.
157 @item Wenn Sie eine Stimme für ein transponierendes Instrument als eine
158 Variable notieren, wird empfohlen, dass die Noten von
161 \transpose c klingende-Tonhöhe @{...@}
164 eingefasst werden (wobei @code{klingende-Tonhöhe} die klingende Tonhöhe
165 des Instruments ist), sodass die Noten innerhalb der Variable für klingendes C
166 geschrieben sind. Sie können die Variable zurücktransponieren, wenn es
167 nötig ist, aber Sie müssen es nicht tun. Fehler in Transpositionen sind
168 treten seltener auf, wenn alle Noten in den Variablen für die gleiche
169 Ausgangstonhöhe geschrieben werden.
171 Denken Sie auch daran, dass Sie nur von/nach C transponieren. Das heißt,
172 dass die einzigen anderen Tonhöhen, die Sie in Transpositionen benutzen,
173 die Tonhöhen der Instrumente sind, für die Sie schreiben: @code{bes} für
174 eine B-Trompete oder @code{aes} für eine As-Klarinette usw.
180 @subsection Große Projekte
181 @translationof Large projects
183 Besonders wenn Sie an größeren Projekten arbeiten, ist es
184 unumgänglich, dass Sie ihre LilyPond-Dateien klar strukturieren.
188 @item @strong{Verwenden Sie Variablen für jede Stimme}, innerhalb
189 der Definition sollte so wenig Struktur wie möglich sein. Die
190 Struktur des @code{\score}-Abschnittes verändert sich am ehesten,
191 während die @code{violine}-Definition sich wahrscheinlich mit einer
192 neuen Programmversion nicht verändern wird.
195 violine = \relative c'' @{
208 @item @strong{Trennen Sie Einstellungen von den Noten}. Diese
209 Empfehlung wurde schon im Abschnitt @ref{Allgemeine Vorschläge} gegeben,
210 aber für große Projekte ist es unumgänglich. Muss z. B. die
211 Definition für @code{fdannp} verändert werden, so braucht
212 man es nur einmal vorzunehmen und die Noten in der Geigenstimme,
213 @code{violin}, bleiben unberührt.
217 \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
218 violin = \relative c'' @{
226 @node Tipparbeit sparen durch Bezeichner und Funktionen
227 @subsection Tipparbeit sparen durch Bezeichner und Funktionen
228 @translationof Saving typing with variables and functions
233 Bis jetzt haben Sie immer etwa solche Noten gesehen:
235 @lilypond[quote,verbatim,ragged-right]
236 hornNotes = \relative c'' { c4 b dis c }
244 Das könnte auch nützlich in Minimal-Music sein:
246 @lilypond[quote,verbatim,ragged-right]
247 fragmentA = \relative c'' { a4 a8. b16 }
248 fragmentB = \relative c'' { a8. gis16 ees4 }
249 violin = \new Staff { \fragmentA \fragmentA \fragmentB \fragmentA }
257 Sie können diese Bezeichner oder Variablen aber auch für
258 (eigene) Einstellungen verwenden:
260 @lilypond[quote,verbatim,ragged-right]
261 dolce = \markup{ \italic \bold dolce }
262 padText = { \once \override TextScript #'padding = #5.0 }
263 fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p }
264 violin = \relative c'' {
266 c4._\dolce b8 a8 g a b |
268 c4.^"hi there!" d8 e' f g d |
269 c,4.\fthenp b8 c4 c-. |
276 \layout{ragged-right=##t}
280 Die Variablen haben in diesem Beispiel deutlich die
281 Tipparbeit erleichtert. Aber es lohnt sich, sie zu
282 einzusetzen, auch wenn man sie nur einmal anwendet,
283 denn sie vereinfachen die Struktur.
284 Hier ist das vorangegangene Beispiel ohne
285 Variablen. Es ist sehr viel komplizierter zu lesen,
286 besonders die letzte Zeile.
289 violin = \relative c'' @{
291 c4._\markup@{ \italic \bold dolce @} b8 a8 g a b |
292 \once \override TextScript #'padding = #5.0
293 c4.^"hi there!" d8 e' f g d |
294 c,4.\markup@{ \dynamic f \italic \small @{ 2nd @}
295 \hspace #0.1 \dynamic p @} b8 c4 c-. |
300 @c TODO Replace the following with a better example -td
301 @c Skylining handles this correctly without padText
303 Bis jetzt wurde nur statische Substitution vorgestellt
304 -- wenn LilyPond den Befehl @code{\padText} findet, wird
305 er ersetzt durch durch unsere vorherige Definition (alles,
306 was nach dem @code{padtext =} kommt).
308 LilyPond kennt aber auch nicht-statische Substitutionen (man
309 kann sie sich als Funktionen vorstellen).
311 @lilypond[quote,verbatim,ragged-right]
313 #(define-music-function (parser location padding) (number?)
315 \once \override TextScript #'padding = #$padding
323 c4^"piu mosso" fis a g
327 Die Benutzung von Variablen hilft auch, viele Schreibarbeit zu
328 vermeiden, wenn die Eingabesyntax von LilyPond sich verändert
329 (siehe auch @ref{Alte Dateien aktualisieren}). Wenn nur eine einzige
330 Definition (etwa @code{\dolce}) für alle Dateien verwendet wird
331 (vgl. @ref{Stil-Dateien}), muss nur diese einzige Definition
332 verändert werden, wenn sich die Syntax ändert. Alle Verwendungen
333 des Befehles beziehen sich dann auf die neue Definition.
336 @subsection Stil-Dateien
337 @translationof Style sheets
339 Die Ausgabe, die LilyPond erstellt, kann sehr stark modifiziert
340 werden, siehe @ref{Die Ausgabe verändern} für Einzelheiten. Aber wie
341 kann man diese Änderungen auf eine ganze Serie von Dateien
342 anwenden? Oder die Einstellungen von den Noten trennen? Das
343 Verfahren ist ziemlich einfach.
345 Hier ist ein Beispiel. Es ist nicht schlimm, wenn Sie nicht auf
346 Anhieb die Abschnitte mit den ganzen @code{#()} verstehen. Das
347 wird im Kapitel @ref{Fortgeschrittene Optimierungen mit Scheme} erklärt.
349 @lilypond[quote,verbatim,ragged-right]
350 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
351 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
353 inst = #(define-music-function (parser location string) (string?)
357 'text (markup #:bold (#:box string))))
361 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
363 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
367 Es treten einige Probleme mit überlappenden Symbolen auf. Sie
368 werden beseitigt mit den Tricks aus dem Kapitel @ref{Verschieben von Objekten}.
369 Aber auch die @code{mpdolce} und @code{inst}-Definitionen
370 können verbessert werden. Sie produzieren das Ergebnis, das
371 gewünscht ist, aber es wäre schön, sie auch in anderen Stücken
372 verwenden zu können. Man könnte sie natürlich einfach kopieren
373 und in die anderen Dateien einfügen, aber das ist lästig. Die
374 Definitionen verbleiben auch in der Notendatei und diese @code{#()}
375 sehen nicht wirklich schön aus. Sie sollen in einer anderen
376 Datei versteckt werden:
379 %%% speichern in einer Datei "definitions.ily"
380 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
381 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
383 inst = #(define-music-function (parser location string) (string?)
387 'text (markup #:bold (#:box string))))
390 Auf diese Datei kann dann später mit dem @code{\include}-Befehl
391 im oberen Teil der LilyPond-Datei zurückgegriffen werden. (Die
392 Erweiterung @code{.ily} wird benutzt, um diese eingefügte Datei,
393 die nicht alleine kompiliert werden kann, von der Hauptdatei zu
395 Jetzt muss natürlich noch die Notendatei angepasst werden (gespeichert
396 unter dem Namen @file{"music.ly"}).
398 @c We have to do this awkward example/lilypond-non-verbatim
399 @c because we can't do the \include stuff in the manual.
402 \include "definitions.ily"
406 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
408 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
412 @lilypond[quote,ragged-right]
413 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
414 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
416 inst = #(define-music-function (parser location string) (string?)
420 'text (markup #:bold (#:box string))))
424 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
426 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
430 Das sieht schon besser aus, aber es sind noch einige Verbesserungen
432 Das Glissando ist schwer zu sehen, also soll es etwas dicker erscheinen
433 und dichter an den Notenköpfen gesetzt werden. Das Metronom-Zeichen
434 soll über dem Schlüssel erscheinen, nicht über der ersten Note. Und
435 schließlich kann unser Kompositionsprofessor @qq{C}-Taktangaben
436 überhaupt nicht leiden, also
437 müssen sie in @qq{4/4} verändert werden.
439 Diese Veränderungen sollten Sie aber nicht in der @file{music.ly}-Datei
440 vornehmen. Ersetzen Sie die @file{definitions.ily}-Datei hiermit:
444 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
445 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
447 inst = #(define-music-function (parser location string) (string?)
451 'text (markup #:bold (#:box string))))
455 \override MetronomeMark #'extra-offset = #'(-9 . 0)
456 \override MetronomeMark #'padding = #'3
459 \override TimeSignature #'style = #'numbered
462 \override Glissando #'thickness = #3
463 \override Glissando #'gap = #0.1
468 @lilypond[quote,ragged-right]
469 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
470 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
472 inst = #(define-music-function (parser location string) (string?)
476 'text (markup #:bold (#:box string))))
480 \override MetronomeMark #'extra-offset = #'(-9 . 0)
481 \override MetronomeMark #'padding = #'3
484 \override TimeSignature #'style = #'numbered
487 \override Glissando #'thickness = #3
488 \override Glissando #'gap = #0.1
494 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
496 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
500 Das sieht schon besser aus! Aber angenommen Sie möchten dieses
501 Stück jetzt veröffentlichen. Ihr Kompositionsprofessor mag
502 die @qq{C}-Taktangaben nicht, aber Sie finden sie irgendwie
503 schöner. Also kopieren Sie die Datei @file{definitions.ily} nach
504 @file{web-publish.ily} und verändern diese. Weil die Noten
505 in einer PDF-Datei auf dem Bildschirm angezeigt werden sollen,
506 bietet es sich auch an, die gesamte Ausgabe zu vergrößern.
510 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
511 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
513 inst = #(define-music-function (parser location string) (string?)
517 'text (markup #:bold (#:box string))))
519 #(set-global-staff-size 23)
522 \override MetronomeMark #'extra-offset = #'(-9 . 0)
523 \override MetronomeMark #'padding = #'3
528 \override Glissando #'thickness = #3
529 \override Glissando #'gap = #0.1
534 @lilypond[quote,ragged-right]
535 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
536 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
538 inst = #(define-music-function (parser location string) (string?)
542 'text (markup #:bold (#:box string))))
544 #(set-global-staff-size 23)
547 \override MetronomeMark #'extra-offset = #'(-9 . 0)
548 \override MetronomeMark #'padding = #'3
551 \override Glissando #'thickness = #3
552 \override Glissando #'gap = #0.1
558 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
560 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
564 In der Notendatei muss jetzt nur noch @code{\include "definitions.ily"}
565 durch @code{\include "web-publish.ily"} ausgetauscht werden.
566 Das könnte man natürlich noch weiter vereinfachen. Also
567 eine Datei @file{definitions.ily}, die nur die Definitionen
568 von @code{mpdolce} und @code{inst} enthält, eine Datei
569 @file{web-publish.ily}, die alle die Änderungen für den
570 @code{\layout}-Abschnitt enthält und eine Datei @file{university.ily}
571 für eine Ausgabe, die den Wünschen des Professors entspricht.
572 Der Anfang der @file{music.ly}-Datei würde dann so aussehen:
575 \include "definitions.ily"
577 %%% Nur eine der beiden Zeilen auskommentieren!
578 \include "web-publish.ily"
579 %\include "university.ily"
582 Durch diese Herangehensweise kann auch bei der Erstellung
583 von nur einer Ausgabeversion Arbeit gespart werden. Ich
584 benutze ein halbes Dutzend verschiedener Stilvorlagen
585 für meine Projekte. Jede Notationsdatei fängt an mit
586 @code{\include "../global.ily"}, welches folgenden Inhalt hat:
592 #(ly:set-option 'point-and-click #f)
593 \include "../init/init-defs.ily"
594 \include "../init/init-layout.ily"
595 \include "../init/init-headers.ily"
596 \include "../init/init-paper.ily"
600 @node Wenn etwas nicht funktioniert
601 @section Wenn etwas nicht funktioniert
602 @translationof When things don't work
605 * Alte Dateien aktualisieren::
606 * Fehlersuche (alles auseinandernehmen)::
610 @node Alte Dateien aktualisieren
611 @subsection Alte Dateien aktualisieren
612 @translationof Updating old files
614 Die Syntax von LilyPond verändert sich ab und zu. Wenn LilyPond
615 besser wird, muss auch die Syntax (Eingabesprache) entsprechend
616 angepasst werden. Teilweise machen diese Veränderungen die
617 Eingabesprache einfacher lesbar, teilweise dienen sie dazu, neue
618 Eigenschaften des Programmes benutzbar zu machen.
620 LilyPond stellt ein Programm bereit, das Aktualisierungen
621 vereinfacht: @code{convert-ly}. Einzelheiten zur Programmbenutzung
622 finden sich in @rprogram{Dateien mit convert-ly aktualisieren}.
624 Leider kann @code{convert-ly} nicht alle Veränderungen der Syntax
625 berücksichtigen. Hier werden einfache @qq{Suchen und
626 Ersetzen}-Veränderungen vorgenommen (wie etwa @code{raggedright} zu
627 @code{ragged-right}), aber einige Veränderungen sind zu
628 kompliziert. Die Syntax-Veränderungen, die das Programm nicht
629 berücksichtigt, sind im Kapitel @rprogram{Dateien mit convert-ly aktualisieren} aufgelistet.
631 Zum Beispiel wurden in LilyPond 2.4 und früheren Versionen
632 Akzente und Umlaute mit LaTeX-Befehlen eingegeben, ein
633 @qq{No\"el} etwa ergäbe das französische Wort für Weihnachten.
634 In LilyPond 2.6 und höher müssen diese Sonderzeichen direkt
635 als utf-8-Zeichen eingegeben werden, in diesem Fall also @qq{ë}.
636 @code{convert-ly} kann nicht alle dieser LaTeX-Befehle
637 verändern, das muss manuell vorgenommen werden.
640 @node Fehlersuche (alles auseinandernehmen)
641 @subsection Fehlersuche (alles auseinandernehmen)
642 @translationof Troubleshooting (taking it all apart)
644 Früher oder später werden Sie in die Lage kommen,
645 dass LilyPond Ihre Datei nicht kompilieren will. Die
646 Information, die LilyPond während der Übersetzung
647 gibt, können Ihnen helfen, den Fehler zu finden, aber
648 in vielen Fällen müssen Sie nach der Fehlerquelle
651 Die besten Hilfsmittel sind in diesem Fall das Zeilen-
652 und Blockkommentar (angezeigt durch @code{%} bzw.
653 @code{%@{ ... %@}}). Wenn Sie nicht bestimmen können,
654 wo sich das Problem befindet, beginnen Sie damit, große
655 Teile des Quelltextes auszukommentieren. Nachdem Sie
656 einen Teil auskommentiert haben, versuchen Sie, die Datei
657 erneut zu übersetzen. Wenn es jetzt funktioniert, muss
658 sich das Problem innerhalb der Kommentare befinden.
659 Wenn es nicht funktioniert, müssen Sie weitere Teile
660 auskommentieren bis sie eine Version haben, die funktioniert.
662 In Extremfällen bleibt nur noch solch ein Beispiel übrig:
676 (also eine Datei ohne Noten).
678 Geben Sie nicht auf, wenn das vorkommen sollte. Nehmen
679 Sie das Kommentarzeichen von einem Teil wieder weg, sagen
680 wir der Bassstimme, und schauen Sie, ob es funktioniert.
681 Wenn nicht, dann kommentieren Sie die gesamte Bassstimme
682 aus, aber nicht den @code{\bass}-Befehl in dem
683 @code{\score}-Abschnitt:
686 bass = \relative c' @{
694 Jetzt beginnen Sie damit, langsam Stück für Stück der
695 Bassstimme wieder hineinzunehmen, bis Sie die problematische
698 Eine andere nützliche Technik zur Problemlösung ist es,
699 @ref{Minimalbeispiele} zu konstruieren.
702 @node Minimalbeispiele
703 @subsection Minimalbeispiele
704 @translationof Minimal examples
706 Ein Minimalbeispiel ist eine Beispieldatei, die so klein wie
707 möglich ist. Diese Beispiele sind sehr viel einfacher zu
708 verstehen als die langen Originaldateien. Minimalbeispiele
713 @item Fehlerberichte zu erstellen,
714 @item eine Hilfeanfrage an die E-Mail-Liste zu schicken,
715 @item Ein Beispiel zur @uref{http://lsr@/.dsi@/.unimi@/.it/,LilyPond
716 Schnipselsammlung} hinzuzufügen.
719 Um ein Beispiel zu konstruieren, das so klein wie möglich ist,
720 gibt es eine einfache Regel: Alles nicht Notwendige entfernen.
721 Wenn Sie unnötige Teile einer Datei entfernen, bietet es sich an,
722 sie auszukommentieren und nicht gleich zu löschen. Auf diese Weise
723 können Sie eine Zeile leicht wieder mit aufnehmen, sollten Sie sie
724 doch brauchen, anstatt sie von Anfang an neu zu schreiben.
726 Es gibt zwei Ausnahmen dieser @qq{So klein wie möglich}-Regel:
729 @item Fügen Sie immer einen @code{\version}Befehl ein.
730 @item Wenn es möglich ist, benutzen Sie @code{\paper@{ ragged-right = ##t @}}
731 am Beginn des Beispiels.
734 Der Sinn der Minimalbeispiele ist, dass sie einfach lesbar sind:
737 @item Vermeiden Sie es, komplizierte Noten, Schlüssel oder Taktangaben
738 zu verwenden, es sei denn, Sie wollen genau an diesen Elementen
740 @item Benutzen Sie keine @code{\override}-Befehle, wenn sie nicht der
741 Zweck des Beispieles sind.
745 @node Partituren und Stimmen
746 @section Partituren und Stimmen
747 @translationof Scores and parts
749 Orchesternoten werden alle zweimal gesetzt. Erstens als Stimmen für
750 die Musiker, und dann als große Partitur für den Dirigenten. Mit
752 kann hier doppelte Arbeit erspart werden. Die Musik muss nur einmal
753 eingegeben werden und wird in einer Variable abgelegt. Der Inhalt
755 Variable wird dann benutzt, um sowohl die Stimme als auch die Partitur
758 Es bietet sich an, die Noten in eigenen Dateien zu speichern. Sagen wir
759 beispielsweise, dass in der Datei @file{Horn-Noten.ly} die folgenden
760 Noten eines Duetts für Horn und Fagott gespeichert sind:
763 HornNoten = \relative c @{
770 Daraus wird dann eine eigene Stimme gemacht, indem folgende Datei
775 \include "Horn-Noten.ly"
777 instrument = "Horn in F"
781 \transpose f c' \HornNoten
788 \include "Horn-Noten.ly"
792 setzt den Inhalt der Datei @file{Horn-Noten.ly} an die Stelle des
793 Befehls in die aktuelle Datei. Damit besteht also eine Definition
794 für @code{HornNoten}, so dass die Variable verwendet werden kann.
795 Der Befehl @code{\transpose f@tie{}c'} zeigt an, dass das Argument,
796 also @code{\HornNoten}, um eine Quinte nach oben transponiert wird.
797 Klingendes @q{f} wird also als @code{c'} notiert. Das entspricht
798 der Notation eines Waldhorns in F. Die Transposition zeigt die folgende
801 @lilypond[quote,ragged-right]
802 \transpose f c' \relative c {
808 In der Musik für mehrere Instrumente kommt es oft vor, dass eine Stimme
809 für mehrere Takte nicht spielt. Das wird mit einer besonderen Pause
810 angezeigt, dem Pausenzeichen für mehrere Takte (engl. multi-measure
811 rest). Sie wird mit dem @emph{großen} Buchstaben @samp{R} eingegeben,
812 gefolgt von einer Dauer (@code{1}@tie{}für eine Ganze, @code{2}@tie{}
813 für eine Halbe usw.). Indem man die Dauer multipliziert, können längere
814 Pausen erstellt werden. Z. B. dauert diese Pause drei Takte eines
821 Wenn die Stimme gedruckt wird, müssen diese Pausen zusammengezogen
823 Das wird durch eine Variable erreicht:
826 \set Score.skipBars = ##t
830 Dieser Befehl setzt die Eigenschaft des @code{skipBars} (@qq{überspringe
831 Takte}) auf wahr (@code{##t}). Wenn diese Option und die Pause
832 zu der Musik des Beispiels gesetzt wird, erhält man folgendes Ergebnis:
834 @lilypond[quote,ragged-right]
835 \transpose f c' \relative c {
837 \set Score.skipBars = ##t
843 Die Partitur wird erstellt, indem alle Noten zusammengesetzt werden.
844 Angenommen, die andere Stimme trägt den Namen @code{FagottNoten}
845 und ist in der Datei @file{Fagott-Noten.ly} gespeichert. Die
846 Partitur sieht dann folgendermaßen aus:
849 \include "Fagott-Noten.ly"
850 \include "Horn-Noten.ly"
853 \new Staff \HornNoten
854 \new Staff \FagottNoten
859 Und mit LilyPond übersetzt:
861 @lilypond[quote,ragged-right]
869 r4 d,8 f | gis4 c | b bes |
870 a8 e f4 | g d | gis f
876 @node Make und Makefiles
877 @section Make und Makefiles
878 @translationof Make and Makefiles
884 Fast alle Betriebssysteme, auf denen LilyPond benutzt werden kann,
885 unterstützen ein Programm mit dem Namen @code{make}. Dieses Programm
886 liest eine besondere Datei mit der Bezeichnung @code{Makefile},
887 die definiert, welche Dateien von welchen anderen Dateien abhängen und
888 welche Befehle für das Betriebssystem nötig sind, um eine Datei aus
889 einer anderen zu erstellen. Ein Makefile könnte etwa erklären, wie
890 @code{ballad.pdf} und @code{ballad.midi} aus @code{ballad.ly}
891 erstellt werden können, indem LilyPond aufgerufen wird.
893 Es gibt Fällen, wenn es sich sehr stark empfiehlt, ein @code{Makefile}
894 für das aktuelle Projekt zu erstellen, entweder zur eigenen Bequemlichkeit,
895 oder aber auch als Hilfe für andere, die vielleicht einmal die
896 Quelldateien lesen und verstehen wollen. Insbesondere bei großen Projekten
897 mit vielen eingefügten Dateien und unterschiedlichen Ausgabeoptionen
898 (etwa Partitur, einzelne Stimmen, Dirigierpartitur, Klavierauszug usw.),
899 aber auch bei Projekten, die komplizierte Programmaufrufe zur Verarbeitung
900 erfordern (wenn man etwa mit @code{lilypond-book} arbeitet), lohnt
901 sich die Erstellung einer Make-Datei. Diese Dateien können sehr
902 unterschiedliche ausfallen, und ihre Komplexität und Flexibilität kann
903 den Bedürfnissen aber auch Kenntnissen des Schreibers angepasst werden.
904 Das Programm GNU Make ist auf GNU/Linux Distributionen und MacOS X
905 installiert, aber es ist auch für Windows erhältlich.
907 Das @strong{GNU Make Manual} gibt eine vollständige Anleitung, wie
908 @code{make} benutzt werden kann. Hier sollen nur einige kleine
909 Blicke auf die vielfältigen Möglichkeiten geworfen werden.
911 Die Befehle, um Regeln in einer Make-Datei zu erstellen, unterscheidet
912 sich zwischen den Betriebssystemen. Die verschiedenen Linuxe und
913 MacOS X benutzen @code{bash}, während unter Windows @code{cmd} eingesetzt
914 wird. Unter MacOS X muss man das System so konfigurieren, dass
915 die Kommandozeile benutzt wird. Hier einige Beispiele für Make-Dateien,
916 mit Versionen für Linux/MacOS und Windows.
918 Das erste Beispiel ist für ein Orchesterstück in vier Stätzen unt mit
919 der folgenden Dateistruktur:
936 | |-- symphony-cello.ly
937 | |-- symphony-horn.ly
938 | |-- symphony-oboes.ly
939 | |-- symphony-viola.ly
940 | |-- symphony-violinOne.ly
941 | `-- symphony-violinTwo.ly
951 Die @code{.ly}-Dateien un den Verzeichnissen @code{Scores} und
952 @code{Parts} erhalten ihrere Noten aus @code{.ily}-Dateien, die
953 sich im @code{Notes}-Verzeichnis befinden:
956 %%% Kopfzeile der Datei "symphony-cello.ly"
957 \include ../definitions.ily
958 \include ../Notes/cello.ily
961 Die Make-Datei hat die Ziele @code{score} (das gesamte Stück als
962 große Partitur), @code{movements} (die einzelnen Sätze als große
963 Partitur) und @code{parts} (die einzelnen Stimmen für die Spieler).
964 Es gibt auch das Ziel @code{archive}, welches ein Tar-Archiv
965 der Quelldateien erstellt, etwa um die Quellen über das Internet
966 oder per E-Mail zu verteilen. Hier die Make-Datei für GNU/Linux
967 oder MacOS X. Sie sollte unter dem Namen @code{Makefile} im obersten
968 Verzeichnis des Projektes gespeichert werden:
970 @warning{Wenn ein Ziel oder eine Musterregel definiert ist, müssen
971 die folgenden Zeilen mit Tabulatoren, nicht mit Leerzeichen beginnen.}
974 # Namensstamm der Ausgabedateien
976 # finde heraus, wieviele Prozessoren vorhanden sind
977 CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
978 # Der Befehl, um lilypond aufzurufen
979 LILY_CMD = lilypond -ddelete-intermediate-files \
980 -dno-point-and-click -djob-count=$(CPU_CORES)
982 # Die Endungen, die im Makefile benutzt werden
983 .SUFFIXES: .ly .ily .pdf .midi
985 # Eingabe- und Ausgabedateien werden in den Verzeichnissen durchsucht,
986 # die sich in der VPATH-Variable befinden. Alle sind Unterverzeichnisse
987 # des aktuellen Verzeichnisses (angegeben durch die GNU make-Variable
995 # Die Musterregel, um PDF und MIDI-Dateien aus der LY-Eingabedatei
996 # zu erstellen. Die .pdf-Ausgabedateien werden in das
997 # `PDF'-Unterverzeichnis abgelegt, die .midi-Dateien in das
998 # `MIDI'-Unterverzeichnis.
1000 $(LILY_CMD) $<; \ # this line begins with a tab
1001 if test -f "$*.pdf"; then \
1004 if test -f "$*.midi"; then \
1005 mv "$*.midi" MIDI/; \
1016 # Abhängigkeiten der einzelnen Sätze.
1017 $(piece)I.pdf: $(piece)I.ly $(notes)
1018 $(piece)II.pdf: $(piece)II.ly $(notes)
1019 $(piece)III.pdf: $(piece)III.ly $(notes)
1020 $(piece)IV.pdf: $(piece)IV.ly $(notes)
1022 # Abhängigkeiten der großen Partitur.
1023 $(piece).pdf: $(piece).ly $(notes)
1025 # Abhängigkeiten der Stimmen.
1026 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
1027 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
1028 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
1029 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
1030 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
1031 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
1033 # `make score' eintippen, um die große Partitur mit allen vier
1034 # Sätzen als eine Datei zu erstellen.
1038 # `make parts' tippen, um alle Stimmen zu erstellen.
1039 # `make foo.pdf' tippen, um die Stimme für das Instrument `foo' zu erstellen.
1040 # Beispiel: `make symphony-cello.pdf'.
1042 parts: $(piece)-cello.pdf \
1043 $(piece)-violinOne.pdf \
1044 $(piece)-violinTwo.pdf \
1045 $(piece)-viola.pdf \
1046 $(piece)-oboes.pdf \
1049 # `make movements' tippen um Dateien für die vier Sätze einzeln zu erstellen.
1051 movements: $(piece)I.pdf \
1056 all: score parts movements
1059 tar -cvvf stamitz.tar \ # this line begins with a tab
1060 --exclude=*pdf --exclude=*~ \
1061 --exclude=*midi --exclude=*.tar \
1065 Unter Windows ergeben sich bestimmte Komplikationen. Nachdem man
1066 GNU Make für Windows heruntergeladen und installiert hat, muss
1067 man den richtigen Pfad in den Umgebungsvariablen des Systems setzen,
1068 damit die DOS-Kommandozeile das Make-Programm finden kann. Um das
1069 vorzunehmen, kann mit der rechten Maustaste auf "Arbeitsplatz"
1070 klicken, dann @code{Eigenschaften} und @code{Erweitert} geklickt
1071 werden. Hier wählt man @code{Umgebungsvariablen}. In der
1072 Liste @code{Systemvariablen} wählt man @code{Path} und mit
1073 einem Klick auf @code{Bearbeiten} kann man den Pfad zu der
1074 @code{.exe}-Datei von GNU Make hinzufügen, der etwa wie
1078 C:\Program Files\GnuWin32\bin
1081 Die Make-Datei selber muss auch angepasst werden, um unterschiedliche
1082 Shell-Befehle zu verwenden und mit Leerzeichen umgehen zu können,
1083 die sich in einigen Standardverzeichnissen unter Windows befinden.
1084 Das @code{archive}-Ziel wird entfernt, da Windows den
1085 @code{tar}-Befehl nicht kennt, und Windows benutzt auch eine
1086 andere Dateiendung für midi-Dateien.
1093 LILY_CMD = lilypond -ddelete-intermediate-files \
1094 -dno-point-and-click \
1095 -djob-count=$(NUMBER_OF_PROCESSORS)
1097 # 8.3 Bezeichnung für CURDIR erhalten (Workaround wg. Leerzeichen in PATH)
1098 workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
1101 .SUFFIXES: .ly .ily .pdf .mid
1110 $(LILY_CMD) $< # diese Zeile beginnt mit Tabulator
1111 if exist "$*.pdf" move /Y "$*.pdf" PDF/ # begin with tab
1112 if exist "$*.mid" move /Y "$*.mid" MIDI/ # begin with tab
1124 $(piece)I.pdf: $(piece)I.ly $(notes)
1125 $(piece)II.pdf: $(piece)II.ly $(notes)
1126 $(piece)III.pdf: $(piece)III.ly $(notes)
1127 $(piece)IV.pdf: $(piece)IV.ly $(notes)
1129 $(piece).pdf: $(piece).ly $(notes)
1131 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
1132 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
1133 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
1134 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
1135 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
1136 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
1142 parts: $(piece)-cello.pdf \
1143 $(piece)-violinOne.pdf \
1144 $(piece)-violinTwo.pdf \
1145 $(piece)-viola.pdf \
1146 $(piece)-oboes.pdf \
1150 movements: $(piece)I.pdf \
1155 all: score parts movements
1158 Die nächste Make-Datei ist für ein @command{lilypond-book}-Dokument,
1159 das in LaTeX gesetzt wird. Das Projekt hat einen Index, welcher
1160 erfordert, dass der Befehl @command{latex} zweimal aufgerufen wird,
1161 um die Verweise zu aktualisieren. Ausgabedateien werden in einem
1162 @code{out}-Verzeichnis für die .pdf-Dateien gespeichert und in
1163 @code{htmlout} für die html-Dateien.
1172 LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
1173 LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
1174 PDF=cd $(OUTDIR) && pdflatex $(FILE)
1175 HTML=cd $(WEBDIR) && latex2html $(FILE)
1176 INDEX=cd $(OUTDIR) && makeindex $(FILE)
1177 PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &
1182 $(LILYBOOK_PDF) # begin with tab
1183 $(PDF) # begin with tab
1184 $(INDEX) # begin with tab
1185 $(PDF) # begin with tab
1186 $(PREVIEW) # begin with tab
1189 $(LILYBOOK_HTML) # begin with tab
1190 $(HTML) # begin with tab
1191 cp -R $(WEBDIR)/$(FILE)/ ./ # begin with tab
1192 $(BROWSER) $(FILE)/$(FILE).html & # begin with tab
1195 cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf # begin with tab
1198 rm -rf $(OUTDIR) # begin with tab
1201 rm -rf $(WEBDIR) # begin with tab
1204 tar -cvvf myproject.tar \ # begin this line with tab
1206 --exclude=htmlout/* \
1207 --exclude=myproject/* \
1214 TODO: soll auch unter Windows funktionieren
1216 Die vorige Make-Datei funktioniert nicht unter Windows. Als Alternative
1217 für Windows-Benutzer könnte man eine einfache batch-Datei erstellen,
1218 welche die erforderlichen Befehl enthält. Sie kümmert sich nicht
1219 um Abhängigkeiten, wie es eine Make-Datei kann, aber wenigstens
1220 wird die Kompilation auf einen einzigen Befehl beschränkt. Das folgende
1221 kann als Datei @command{build.bat} oder @command{build.cmd} gespeichert
1222 werden. Die Batch-Datei kann auf der Kommandozeile aufgerufen werden
1223 oder einfach doppelt angeklickt werden.
1226 lilypond-book --output=out --pdf myproject.lytex
1232 copy out\myproject.pdf MyProject.pdf
1238 @rprogram{Einrichtung für MacOS X},
1239 @rprogram{Benutzung auf der Kommandozeile},
1240 @rprogram{LilyPond-book}