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. See TRANSLATION for details.
12 @node An LilyPond-Projekten arbeiten
13 @chapter An LilyPond-Projekten arbeiten
14 @translationof Working on LilyPond projects
16 Dieses Kapitel erklärt, wie bestimmte häufige Probleme zu
17 lösen oder ganz zu vermeiden sind. Wenn Sie schon
18 Programmiererfahrung mitbringen, erscheinen diese Hinweise
19 vielleicht überflüssig, aber es wird dennoch empfohlen, dieses Kapitel
24 * Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen::
25 * Wenn etwas nicht funktioniert::
26 * Partituren und Stimmen::
27 * Make und Makefiles::
31 @node Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen
32 @section Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen
33 @translationof Suggestions for writing LilyPond input files
35 Jetzt sind Sie so weit, größere Stücke mit LilyPond zu schreiben --
36 nicht nur die kleinen Beispiele aus der Übung, sondern ganze Stücke.
37 Aber wie geht man das am besten an?
39 Solange LilyPond Ihre Dateien versteht und die Noten so setzt,
40 wie Sie das wollen, spielt es eigentlich keine Rolle, wie Ihre
41 Dateien aussehen. Es gibt aber trotzdem ein paar Dinge, die man
42 beim Schreiben von LilyPond-Code berücksichtigen sollte.
45 @item Was ist, wenn Sie einen Fehler machen? Die Struktur einer
46 LilyPond-Datei kann es erleichtern (oder erschweren), bestimmte
49 @item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen
50 wollen? Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten
51 wollen? Manche LilyPond-Dateien versteht man auf den ersten Blick,
52 über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.
54 @item Was ist, wenn sie Ihre Dateien auf eine neuere LilyPond-Version
55 aktualisieren wollen? Die Syntax der Eingabesprache verändert sich
56 allmählich mit Verbesserungen im Programm. Die meisten Veränderungen
57 können automatisch durch @code{convert-ly} gelöst werden, aber
58 bestimmte Änderungen brauchen Handarbeit. LilyPond-Dateien können
59 strukturiert werden, damit sie einfacher aktualisierbar sind.
63 * Allgemeine Vorschläge::
64 * Das Kopieren von bereits vorhandener Musik::
66 * Tipparbeit sparen durch Bezeichner und Funktionen::
71 @node Allgemeine Vorschläge
72 @subsection Allgemeine Vorschläge
73 @translationof General suggestions
75 Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:
78 @item @strong{Schreiben Sie immer mit @code{\version} die
80 in jede Datei}. Beachten Sie, dass in allen Vorlagen die Versionsnummer
81 @code{\version "2.12.0"} eingetragen ist. Es empfiehlt sich, in alle
82 Dateien, unabhängig von ihrer Größe, den @code{\version}-Befehl
83 einzufügen. Persönliche Erfahrung hat gezeigt, dass es ziemlich
84 frustrierend sein kann zu erinnern, welche Programmversion man etwa
85 vor einem Jahr verwendet hat. Auch @code{convert-ly} benötigt die
88 @item @strong{Benutzen Sie Überprüfungen}: @ruser{Oktavenüberprüfung}, und
89 @ruser{Takt- und Taktzahlüberprüfung}. Wenn Sie hier und da diese
90 Überprüfungen einfügen, finden Sie einen möglichen Fehler weit
91 schneller. Wie oft aber ist @qq{hier und da}? Das hängt von der
92 Komplexität der Musik ab. ei einfachen Stücken reicht es vielleicht
93 ein- oder zweimal, in sehr komplexer Musik sollte man sie vielleicht
94 in jeden Takt einfügen.
96 @item @strong{Ein Takt pro Textzeile}. Wenn irgendetwas kompliziertes
97 vorkommt, entweder in der Musik selber oder in der Anpassung der
99 empfiehlt es sich oft, nur einen Takt pro Zeile zu schreiben.
100 Bildschirmplatz zu sparen, indem Sie acht Takte in eine Zeile zwängen,
101 hilft nicht weiter, wenn Sie ihre Datei @qq{debuggen} müssen.
103 @item @strong{Kommentieren Sie ihre Dateien}. Benutzen Sie entweder
104 Taktnummern (in regelmäßigen Abständen) oder Verweise auf musikalische
105 Themen (@qq{Zweites Thema in den Geigen}, @qq{vierte Variation} usw.).
106 Sie brauchen diese Kommentare vielleicht noch nicht, wenn Sie das Stück
107 notieren, aber spätestens wenn Sie nach ein paar Jahren etwas
109 wollen oder Sie den Quelltext an einen Freund weitergeben wollen,
110 ist es weitaus komplizierter, die Dateistruktur ohne Kommentare zu
111 verstehen, als wenn Sie sie rechtzeitig eingefügt hätten.
113 @item @strong{Schreiben Sie Klammern mit Einrückung}. Viele
114 Probleme entstehen durch ungerade Anzahl von @code{@{} and
117 @item @strong{Schreiben Sie Tondauerangaben} am Anfang von
118 Abschnitten und Bezeichnern. Wenn Sie beispielsweise
119 @code{c4 d e} am Anfang eines Abschnittes schreiben,
120 ersparen Sie sich viele Probleme, wenn Sie ihre Musik
121 eines Tages umarrangieren wollen.
123 @item @strong{Trennen Sie Einstellungen} von den eigentlichen
124 Noten. Siehe auch @ref{Tipparbeit sparen durch Bezeichner und Funktionen}
131 @node Das Kopieren von bereits vorhandener Musik
132 @subsection Das Kopieren von bereits vorhandener Musik
133 @translationof Typesetting existing music
135 Wenn Sie Musik aus einer fertigen Partitur kopieren (z. B. die
136 LilyPond-Eingabe einer gedruckten Partitur):
140 @item Schreiben Sie ein System ihrer Quelle nach dem anderen
141 (aber trotzdem nur einen Takt pro Textzeile) und überprüfen
142 Sie jedes System, nachdem Sie es fertig kopiert haben. Mit dem
143 @code{showLastLength}- oder @code{showFirstLenght}-Befehl können Sie den Übersetzungsprozess
144 beschleunigen. Siehe auch
145 @ruser{Korrigierte Musik überspringen}.
147 @item Definieren Sie @code{mBreak = @{ \break @}} und schreiben Sie
148 @code{\mBreak} in der Quelldatei immer dann, wenn im Manuskript
149 ein Zeilenumbruch vorkommt. Das macht es einfacher, die gesetzte
150 Zeile mit den ursprünglichen Noten zu vergleichen. Wenn Sie die
151 Partitur fertig gestellt haben, könne Sie @code{mBreak = @{ @}},
152 also leer definieren, um diese manuellen Zeilenumbrüche zu entfernen.
153 Damit kann dann LilyPond selber entscheiden, wohin es passende
154 Zeilenumbrüche platziert.
156 @item Wenn Sie eine Stimme für ein transponierendes Instrument als eine
157 Variable notieren, wird empfohlen, dass die Noten von
160 \transpose c klingende-Tonhöhe @{...@}
163 eingefasst werden (wobei @code{klingende-Tonhöhe} die klingende Tonhöhe
164 des Instruments ist), sodass die Noten innerhalb der Variable für klingendes C
165 geschrieben sind. Sie können die Variable zurücktransponieren, wenn es
166 nötig ist, aber Sie müssen es nicht tun. Fehler in Transpositionen sind
167 treten seltener auf, wenn alle Noten in den Variablen für die gleiche
168 Ausgangstonhöhe geschrieben werden.
170 Denken Sie auch daran, dass Sie nur von/nach C transponieren. Das heißt,
171 dass die einzigen anderen Tonhöhen, die Sie in Transpositionen benutzen,
172 die Tonhöhen der Instrumente sind, für die Sie schreiben: @code{bes} für
173 eine B-Trompete oder @code{aes} für eine As-Klarinette usw.
179 @subsection Große Projekte
180 @translationof Large projects
182 Besonders wenn Sie an größeren Projekten arbeiten, ist es
183 unumgänglich, dass Sie ihre LilyPond-Dateien klar strukturieren.
187 @item @strong{Verwenden Sie Variablen für jede Stimme}, innerhalb
188 der Definition sollte so wenig Struktur wie möglich sein. Die
189 Struktur des @code{\score}-Abschnittes verändert sich am ehesten,
190 während die @code{violine}-Definition sich wahrscheinlich mit einer
191 neuen Programmversion nicht verändern wird.
194 violine = \relative c'' @{
207 @item @strong{Trennen Sie Einstellungen von den Noten}. Diese
208 Empfehlung wurde schon im Abschnitt @ref{Allgemeine Vorschläge} gegeben,
209 aber für große Projekte ist es unumgänglich. Muss z. B. die
210 Definition für @code{fdannp} verändert werden, so braucht
211 man es nur einmal vorzunehmen und die Noten in der Geigenstimme,
212 @code{violin}, bleiben unberührt.
216 \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
217 violin = \relative c'' @{
225 @node Tipparbeit sparen durch Bezeichner und Funktionen
226 @subsection Tipparbeit sparen durch Bezeichner und Funktionen
227 @translationof Saving typing with variables and functions
232 Bis jetzt haben Sie immer etwa solche Noten gesehen:
234 @lilypond[quote,verbatim,ragged-right]
235 hornNotes = \relative c'' { c4 b dis c }
243 Das könnte auch nützlich in Minimal-Music sein:
245 @lilypond[quote,verbatim,ragged-right]
246 fragmentA = \relative c'' { a4 a8. b16 }
247 fragmentB = \relative c'' { a8. gis16 ees4 }
248 violin = \new Staff { \fragmentA \fragmentA \fragmentB \fragmentA }
256 Sie können diese Bezeichner oder Variablen aber auch für
257 (eigene) Einstellungen verwenden:
259 @lilypond[quote,verbatim,ragged-right]
260 dolce = \markup{ \italic \bold dolce }
261 padText = { \once \override TextScript #'padding = #5.0 }
262 fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p }
263 violin = \relative c'' {
265 c4._\dolce b8 a8 g a b |
267 c4.^"hi there!" d8 e' f g d |
268 c,4.\fthenp b8 c4 c-. |
275 \layout{ragged-right=##t}
279 Die Variablen haben in diesem Beispiel deutlich die
280 Tipparbeit erleichtert. Aber es lohnt sich, sie zu
281 einzusetzen, auch wenn man sie nur einmal anwendet,
282 denn sie vereinfachen die Struktur.
283 Hier ist das vorangegangene Beispiel ohne
284 Variablen. Es ist sehr viel komplizierter zu lesen,
285 besonders die letzte Zeile.
288 violin = \relative c'' @{
290 c4._\markup@{ \italic \bold dolce @} b8 a8 g a b |
291 \once \override TextScript #'padding = #5.0
292 c4.^"hi there!" d8 e' f g d |
293 c,4.\markup@{ \dynamic f \italic \small @{ 2nd @}
294 \hspace #0.1 \dynamic p @} b8 c4 c-. |
299 @c TODO Replace the following with a better example -td
300 @c Skylining handles this correctly without padText
302 Bis jetzt wurde nur statische Substitution vorgestellt
303 -- wenn LilyPond den Befehl @code{\padText} findet, wird
304 er ersetzt durch durch unsere vorherige Definition (alles,
305 was nach dem @code{padtext =} kommt).
307 LilyPond kennt aber auch nicht-statische Substitutionen (man
308 kann sie sich als Funktionen vorstellen).
310 @lilypond[quote,verbatim,ragged-right]
312 #(define-music-function (parser location padding) (number?)
314 \once \override TextScript #'padding = #$padding
322 c4^"piu mosso" fis a g
326 Die Benutzung von Variablen hilft auch, viele Schreibarbeit zu
327 vermeiden, wenn die Eingabesyntax von LilyPond sich verändert
328 (siehe auch @ref{Alte Dateien aktualisieren}). Wenn nur eine einzige
329 Definition (etwa @code{\dolce}) für alle Dateien verwendet wird
330 (vgl. @ref{Stil-Dateien}), muss nur diese einzige Definition
331 verändert werden, wenn sich die Syntax ändert. Alle Verwendungen
332 des Befehles beziehen sich dann auf die neue Definition.
335 @subsection Stil-Dateien
336 @translationof Style sheets
338 Die Ausgabe, die LilyPond erstellt, kann sehr stark modifiziert
339 werden, siehe @ref{Die Ausgabe verändern} für Einzelheiten. Aber wie
340 kann man diese Änderungen auf eine ganze Serie von Dateien
341 anwenden? Oder die Einstellungen von den Noten trennen? Das
342 Verfahren ist ziemlich einfach.
344 Hier ist ein Beispiel. Es ist nicht schlimm, wenn Sie nicht auf
345 Anhieb die Abschnitte mit den ganzen @code{#()} verstehen. Das
346 wird im Kapitel @ref{Fortgeschrittene Optimierungen mit Scheme} erklärt.
348 @lilypond[quote,verbatim,ragged-right]
349 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
350 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
352 inst = #(define-music-function (parser location string) (string?)
356 'text (markup #:bold (#:box string))))
360 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
362 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
366 Es treten einige Probleme mit überlappenden Symbolen auf. Sie
367 werden beseitigt mit den Tricks aus dem Kapitel @ref{Verschieben von Objekten}.
368 Aber auch die @code{mpdolce} und @code{inst}-Definitionen
369 können verbessert werden. Sie produzieren das Ergebnis, das
370 gewünscht ist, aber es wäre schön, sie auch in anderen Stücken
371 verwenden zu können. Man könnte sie natürlich einfach kopieren
372 und in die anderen Dateien einfügen, aber das ist lästig. Die
373 Definitionen verbleiben auch in der Notendatei und diese @code{#()}
374 sehen nicht wirklich schön aus. Sie sollen in einer anderen
375 Datei versteckt werden:
378 %%% speichern in einer Datei "definitions.ily"
379 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
380 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
382 inst = #(define-music-function (parser location string) (string?)
386 'text (markup #:bold (#:box string))))
389 Auf diese Datei kann dann später mit dem @code{\include}-Befehl
390 im oberen Teil der LilyPond-Datei zurückgegriffen werden. (Die
391 Erweiterung @code{.ily} wird benutzt, um diese eingefügte Datei,
392 die nicht alleine kompiliert werden kann, von der Hauptdatei zu
394 Jetzt muss natürlich noch die Notendatei angepasst werden (gespeichert
395 unter dem Namen @file{"music.ly"}).
397 @c We have to do this awkward example/lilypond-non-verbatim
398 @c because we can't do the \include stuff in the manual.
401 \include "definitions.ily"
405 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
407 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
411 @lilypond[quote,ragged-right]
412 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
413 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
415 inst = #(define-music-function (parser location string) (string?)
419 'text (markup #:bold (#:box string))))
423 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
425 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
429 Das sieht schon besser aus, aber es sind noch einige Verbesserungen
431 Das Glissando ist schwer zu sehen, also soll es etwas dicker erscheinen
432 und dichter an den Notenköpfen gesetzt werden. Das Metronom-Zeichen
433 soll über dem Schlüssel erscheinen, nicht über der ersten Note. Und
434 schließlich kann unser Kompositionsprofessor @qq{C}-Taktangaben
435 überhaupt nicht leiden, also
436 müssen sie in @qq{4/4} verändert werden.
438 Diese Veränderungen sollten Sie aber nicht in der @file{music.ly}-Datei
439 vornehmen. Ersetzen Sie die @file{definitions.ily}-Datei hiermit:
443 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
444 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
446 inst = #(define-music-function (parser location string) (string?)
450 'text (markup #:bold (#:box string))))
454 \override MetronomeMark #'extra-offset = #'(-9 . 0)
455 \override MetronomeMark #'padding = #'3
458 \override TimeSignature #'style = #'numbered
461 \override Glissando #'thickness = #3
462 \override Glissando #'gap = #0.1
467 @lilypond[quote,ragged-right]
468 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
469 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
471 inst = #(define-music-function (parser location string) (string?)
475 'text (markup #:bold (#:box string))))
479 \override MetronomeMark #'extra-offset = #'(-9 . 0)
480 \override MetronomeMark #'padding = #'3
483 \override TimeSignature #'style = #'numbered
486 \override Glissando #'thickness = #3
487 \override Glissando #'gap = #0.1
493 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
495 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
499 Das sieht schon besser aus! Aber angenommen Sie möchten dieses
500 Stück jetzt veröffentlichen. Ihr Kompositionsprofessor mag
501 die @qq{C}-Taktangaben nicht, aber Sie finden sie irgendwie
502 schöner. Also kopieren Sie die Datei @file{definitions.ily} nach
503 @file{web-publish.ily} und verändern diese. Weil die Noten
504 in einer PDF-Datei auf dem Bildschirm angezeigt werden sollen,
505 bietet es sich auch an, die gesamte Ausgabe zu vergrößern.
509 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
510 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
512 inst = #(define-music-function (parser location string) (string?)
516 'text (markup #:bold (#:box string))))
518 #(set-global-staff-size 23)
521 \override MetronomeMark #'extra-offset = #'(-9 . 0)
522 \override MetronomeMark #'padding = #'3
527 \override Glissando #'thickness = #3
528 \override Glissando #'gap = #0.1
533 @lilypond[quote,ragged-right]
534 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
535 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
537 inst = #(define-music-function (parser location string) (string?)
541 'text (markup #:bold (#:box string))))
543 #(set-global-staff-size 23)
546 \override MetronomeMark #'extra-offset = #'(-9 . 0)
547 \override MetronomeMark #'padding = #'3
550 \override Glissando #'thickness = #3
551 \override Glissando #'gap = #0.1
557 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
559 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
563 In der Notendatei muss jetzt nur noch @code{\include "definitions.ily"}
564 durch @code{\include "web-publish.ily"} ausgetauscht werden.
565 Das könnte man natürlich noch weiter vereinfachen. Also
566 eine Datei @file{definitions.ily}, die nur die Definitionen
567 von @code{mpdolce} und @code{inst} enthält, eine Datei
568 @file{web-publish.ily}, die alle die Änderungen für den
569 @code{\layout}-Abschnitt enthält und eine Datei @file{university.ily}
570 für eine Ausgabe, die den Wünschen des Professors entspricht.
571 Der Anfang der @file{music.ly}-Datei würde dann so aussehen:
574 \include "definitions.ily"
576 %%% Nur eine der beiden Zeilen auskommentieren!
577 \include "web-publish.ily"
578 %\include "university.ily"
581 Durch diese Herangehensweise kann auch bei der Erstellung
582 von nur einer Ausgabeversion Arbeit gespart werden. Ich
583 benutze ein halbes Dutzend verschiedener Stilvorlagen
584 für meine Projekte. Jede Notationsdatei fängt an mit
585 @code{\include "../global.ily"}, welches folgenden Inhalt hat:
591 #(ly:set-option 'point-and-click #f)
592 \include "../init/init-defs.ily"
593 \include "../init/init-layout.ily"
594 \include "../init/init-headers.ily"
595 \include "../init/init-paper.ily"
599 @node Wenn etwas nicht funktioniert
600 @section Wenn etwas nicht funktioniert
601 @translationof When things don't work
604 * Alte Dateien aktualisieren::
605 * Fehlersuche (alles auseinandernehmen)::
609 @node Alte Dateien aktualisieren
610 @subsection Alte Dateien aktualisieren
611 @translationof Updating old files
613 Die Syntax von LilyPond verändert sich ab und zu. Wenn LilyPond
614 besser wird, muss auch die Syntax (Eingabesprache) entsprechend
615 angepasst werden. Teilweise machen diese Veränderungen die
616 Eingabesprache einfacher lesbar, teilweise dienen sie dazu, neue
617 Eigenschaften des Programmes benutzbar zu machen.
619 LilyPond stellt ein Programm bereit, das Aktualisierungen
620 vereinfacht: @code{convert-ly}. Einzelheiten zur Programmbenutzung
621 finden sich in @rprogram{Dateien mit convert-ly aktualisieren}.
623 Leider kann @code{convert-ly} nicht alle Veränderungen der Syntax
624 berücksichtigen. Hier werden einfache @qq{Suchen und
625 Ersetzen}-Veränderungen vorgenommen (wie etwa @code{raggedright} zu
626 @code{ragged-right}), aber einige Veränderungen sind zu
627 kompliziert. Die Syntax-Veränderungen, die das Programm nicht
628 berücksichtigt, sind im Kapitel @rprogram{Dateien mit convert-ly aktualisieren} aufgelistet.
630 Zum Beispiel wurden in LilyPond 2.4 und früheren Versionen
631 Akzente und Umlaute mit LaTeX-Befehlen eingegeben, ein
632 @qq{No\"el} etwa ergäbe das französische Wort für Weihnachten.
633 In LilyPond 2.6 und höher müssen diese Sonderzeichen direkt
634 als utf-8-Zeichen eingegeben werden, in diesem Fall also @qq{ë}.
635 @code{convert-ly} kann nicht alle dieser LaTeX-Befehle
636 verändern, das muss manuell vorgenommen werden.
639 @node Fehlersuche (alles auseinandernehmen)
640 @subsection Fehlersuche (alles auseinandernehmen)
641 @translationof Troubleshooting (taking it all apart)
643 Früher oder später werden Sie in die Lage kommen,
644 dass LilyPond Ihre Datei nicht kompilieren will. Die
645 Information, die LilyPond während der Übersetzung
646 gibt, können Ihnen helfen, den Fehler zu finden, aber
647 in vielen Fällen müssen Sie nach der Fehlerquelle
650 Die besten Hilfsmittel sind in diesem Fall das Zeilen-
651 und Blockkommentar (angezeigt durch @code{%} bzw.
652 @code{%@{ ... %@}}). Wenn Sie nicht bestimmen können,
653 wo sich das Problem befindet, beginnen Sie damit, große
654 Teile des Quelltextes auszukommentieren. Nachdem Sie
655 einen Teil auskommentiert haben, versuchen Sie, die Datei
656 erneut zu übersetzen. Wenn es jetzt funktioniert, muss
657 sich das Problem innerhalb der Kommentare befinden.
658 Wenn es nicht funktioniert, müssen Sie weitere Teile
659 auskommentieren bis sie eine Version haben, die funktioniert.
661 In Extremfällen bleibt nur noch solch ein Beispiel übrig:
675 (also eine Datei ohne Noten).
677 Geben Sie nicht auf, wenn das vorkommen sollte. Nehmen
678 Sie das Kommentarzeichen von einem Teil wieder weg, sagen
679 wir der Bassstimme, und schauen Sie, ob es funktioniert.
680 Wenn nicht, dann kommentieren Sie die gesamte Bassstimme
681 aus, aber nicht den @code{\bass}-Befehl in dem
682 @code{\score}-Abschnitt:
685 bass = \relative c' @{
693 Jetzt beginnen Sie damit, langsam Stück für Stück der
694 Bassstimme wieder hineinzunehmen, bis Sie die problematische
697 Eine andere nützliche Technik zur Problemlösung ist es,
698 @ref{Minimalbeispiele} zu konstruieren.
701 @node Minimalbeispiele
702 @subsection Minimalbeispiele
703 @translationof Minimal examples
705 Ein Minimalbeispiel ist eine Beispieldatei, die so klein wie
706 möglich ist. Diese Beispiele sind sehr viel einfacher zu
707 verstehen als die langen Originaldateien. Minimalbeispiele
712 @item Fehlerberichte zu erstellen,
713 @item eine Hilfeanfrage an die E-Mail-Liste zu schicken,
714 @item Ein Beispiel zur @uref{http://lsr@/.dsi@/.unimi@/.it/,LilyPond
715 Schnipselsammlung} hinzuzufügen.
718 Um ein Beispiel zu konstruieren, das so klein wie möglich ist,
719 gibt es eine einfache Regel: Alles nicht Notwendige entfernen.
720 Wenn Sie unnötige Teile einer Datei entfernen, bietet es sich an,
721 sie auszukommentieren und nicht gleich zu löschen. Auf diese Weise
722 können Sie eine Zeile leicht wieder mit aufnehmen, sollten Sie sie
723 doch brauchen, anstatt sie von Anfang an neu zu schreiben.
725 Es gibt zwei Ausnahmen dieser @qq{So klein wie möglich}-Regel:
728 @item Fügen Sie immer einen @code{\version}Befehl ein.
729 @item Wenn es möglich ist, benutzen Sie @code{\paper@{ ragged-right = ##t @}}
730 am Beginn des Beispiels.
733 Der Sinn der Minimalbeispiele ist, dass sie einfach lesbar sind:
736 @item Vermeiden Sie es, komplizierte Noten, Schlüssel oder Taktangaben
737 zu verwenden, es sei denn, Sie wollen genau an diesen Elementen
739 @item Benutzen Sie keine @code{\override}-Befehle, wenn sie nicht der
740 Zweck des Beispieles sind.
744 @node Partituren und Stimmen
745 @section Partituren und Stimmen
746 @translationof Scores and parts
748 Orchesternoten werden alle zweimal gesetzt. Erstens als Stimmen für
749 die Musiker, und dann als große Partitur für den Dirigenten. Mit
751 kann hier doppelte Arbeit erspart werden. Die Musik muss nur einmal
752 eingegeben werden und wird in einer Variable abgelegt. Der Inhalt
754 Variable wird dann benutzt, um sowohl die Stimme als auch die Partitur
757 Es bietet sich an, die Noten in eigenen Dateien zu speichern. Sagen wir
758 beispielsweise, dass in der Datei @file{Horn-Noten.ly} die folgenden
759 Noten eines Duetts für Horn und Fagott gespeichert sind:
762 HornNoten = \relative c @{
769 Daraus wird dann eine eigene Stimme gemacht, indem folgende Datei
774 \include "Horn-Noten.ly"
776 instrument = "Horn in F"
780 \transpose f c' \HornNoten
787 \include "Horn-Noten.ly"
791 setzt den Inhalt der Datei @file{Horn-Noten.ly} an die Stelle des
792 Befehls in die aktuelle Datei. Damit besteht also eine Definition
793 für @code{HornNoten}, so dass die Variable verwendet werden kann.
794 Der Befehl @code{\transpose f@tie{}c'} zeigt an, dass das Argument,
795 also @code{\HornNoten}, um eine Quinte nach oben transponiert wird.
796 Klingendes @q{f} wird also als @code{c'} notiert. Das entspricht
797 der Notation eines Waldhorns in F. Die Transposition zeigt die folgende
800 @lilypond[quote,ragged-right]
801 \transpose f c' \relative c {
807 In der Musik für mehrere Instrumente kommt es oft vor, dass eine Stimme
808 für mehrere Takte nicht spielt. Das wird mit einer besonderen Pause
809 angezeigt, dem Pausenzeichen für mehrere Takte (engl. multi-measure
810 rest). Sie wird mit dem @emph{großen} Buchstaben @samp{R} eingegeben,
811 gefolgt von einer Dauer (@code{1}@tie{}für eine Ganze, @code{2}@tie{}
812 für eine Halbe usw.). Indem man die Dauer multipliziert, können längere
813 Pausen erstellt werden. Z. B. dauert diese Pause drei Takte eines
820 Wenn die Stimme gedruckt wird, müssen diese Pausen zusammengezogen
822 Das wird durch eine Variable erreicht:
825 \set Score.skipBars = ##t
829 Dieser Befehl setzt die Eigenschaft des @code{skipBars} (@qq{überspringe
830 Takte}) auf wahr (@code{##t}). Wenn diese Option und die Pause
831 zu der Musik des Beispiels gesetzt wird, erhält man folgendes Ergebnis:
833 @lilypond[quote,ragged-right]
834 \transpose f c' \relative c {
836 \set Score.skipBars = ##t
842 Die Partitur wird erstellt, indem alle Noten zusammengesetzt werden.
843 Angenommen, die andere Stimme trägt den Namen @code{FagottNoten}
844 und ist in der Datei @file{Fagott-Noten.ly} gespeichert. Die
845 Partitur sieht dann folgendermaßen aus:
848 \include "Fagott-Noten.ly"
849 \include "Horn-Noten.ly"
852 \new Staff \HornNoten
853 \new Staff \FagottNoten
858 Und mit LilyPond übersetzt:
860 @lilypond[quote,ragged-right]
868 r4 d,8 f | gis4 c | b bes |
869 a8 e f4 | g d | gis f
875 @node Make und Makefiles
876 @section Make und Makefiles
877 @translationof Make and Makefiles
883 Fast alle Betriebssysteme, auf denen LilyPond benutzt werden kann,
884 unterstützen ein Programm mit dem Namen @code{make}. Dieses Programm
885 liest eine besondere Datei mit der Bezeichnung @code{Makefile},
886 die definiert, welche Dateien von welchen anderen Dateien abhängen und
887 welche Befehle für das Betriebssystem nötig sind, um eine Datei aus
888 einer anderen zu erstellen. Ein Makefile könnte etwa erklären, wie
889 @code{ballad.pdf} und @code{ballad.midi} aus @code{ballad.ly}
890 erstellt werden können, indem LilyPond aufgerufen wird.
892 Es gibt Fällen, wenn es sich sehr stark empfiehlt, ein @code{Makefile}
893 für das aktuelle Projekt zu erstellen, entweder zur eigenen Bequemlichkeit,
894 oder aber auch als Hilfe für andere, die vielleicht einmal die
895 Quelldateien lesen und verstehen wollen. Insbesondere bei großen Projekten
896 mit vielen eingefügten Dateien und unterschiedlichen Ausgabeoptionen
897 (etwa Partitur, einzelne Stimmen, Dirigierpartitur, Klavierauszug usw.),
898 aber auch bei Projekten, die komplizierte Programmaufrufe zur Verarbeitung
899 erfordern (wenn man etwa mit @code{lilypond-book} arbeitet), lohnt
900 sich die Erstellung einer Make-Datei. Diese Dateien können sehr
901 unterschiedliche ausfallen, und ihre Komplexität und Flexibilität kann
902 den Bedürfnissen aber auch Kenntnissen des Schreibers angepasst werden.
903 Das Programm GNU Make ist auf GNU/Linux Distributionen und MacOS X
904 installiert, aber es ist auch für Windows erhältlich.
906 Das @strong{GNU Make Manual} gibt eine vollständige Anleitung, wie
907 @code{make} benutzt werden kann. Hier sollen nur einige kleine
908 Blicke auf die vielfältigen Möglichkeiten geworfen werden.
910 Die Befehle, um Regeln in einer Make-Datei zu erstellen, unterscheidet
911 sich zwischen den Betriebssystemen. Die verschiedenen Linuxe und
912 MacOS X benutzen @code{bash}, während unter Windows @code{cmd} eingesetzt
913 wird. Unter MacOS X muss man das System so konfigurieren, dass
914 die Kommandozeile benutzt wird. Hier einige Beispiele für Make-Dateien,
915 mit Versionen für Linux/MacOS und Windows.
917 Das erste Beispiel ist für ein Orchesterstück in vier Stätzen unt mit
918 der folgenden Dateistruktur:
935 | |-- symphony-cello.ly
936 | |-- symphony-horn.ly
937 | |-- symphony-oboes.ly
938 | |-- symphony-viola.ly
939 | |-- symphony-violinOne.ly
940 | `-- symphony-violinTwo.ly
950 Die @code{.ly}-Dateien un den Verzeichnissen @code{Scores} und
951 @code{Parts} erhalten ihrere Noten aus @code{.ily}-Dateien, die
952 sich im @code{Notes}-Verzeichnis befinden:
955 %%% Kopfzeile der Datei "symphony-cello.ly"
956 \include ../definitions.ily
957 \include ../Notes/cello.ily
960 Die Make-Datei hat die Ziele @code{score} (das gesamte Stück als
961 große Partitur), @code{movements} (die einzelnen Sätze als große
962 Partitur) und @code{parts} (die einzelnen Stimmen für die Spieler).
963 Es gibt auch das Ziel @code{archive}, welches ein Tar-Archiv
964 der Quelldateien erstellt, etwa um die Quellen über das Internet
965 oder per E-Mail zu verteilen. Hier die Make-Datei für GNU/Linux
966 oder MacOS X. Sie sollte unter dem Namen @code{Makefile} im obersten
967 Verzeichnis des Projektes gespeichert werden:
969 @warning{Wenn ein Ziel oder eine Musterregel definiert ist, müssen
970 die folgenden Zeilen mit Tabulatoren, nicht mit Leerzeichen beginnen.}
973 # Namensstamm der Ausgabedateien
975 # finde heraus, wieviele Prozessoren vorhanden sind
976 CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
977 # Der Befehl, um lilypond aufzurufen
978 LILY_CMD = lilypond -ddelete-intermediate-files \
979 -dno-point-and-click -djob-count=$(CPU_CORES)
981 # Die Endungen, die im Makefile benutzt werden
982 .SUFFIXES: .ly .ily .pdf .midi
984 # Eingabe- und Ausgabedateien werden in den Verzeichnissen durchsucht,
985 # die sich in der VPATH-Variable befinden. Alle sind Unterverzeichnisse
986 # des aktuellen Verzeichnisses (angegeben durch die GNU make-Variable
994 # Die Musterregel, um PDF und MIDI-Dateien aus der LY-Eingabedatei
995 # zu erstellen. Die .pdf-Ausgabedateien werden in das
996 # `PDF'-Unterverzeichnis abgelegt, die .midi-Dateien in das
997 # `MIDI'-Unterverzeichnis.
999 $(LILY_CMD) $<; \ # this line begins with a tab
1000 if test -f "$*.pdf"; then \
1003 if test -f "$*.midi"; then \
1004 mv "$*.midi" MIDI/; \
1015 # Abhängigkeiten der einzelnen Sätze.
1016 $(piece)I.pdf: $(piece)I.ly $(notes)
1017 $(piece)II.pdf: $(piece)II.ly $(notes)
1018 $(piece)III.pdf: $(piece)III.ly $(notes)
1019 $(piece)IV.pdf: $(piece)IV.ly $(notes)
1021 # Abhängigkeiten der großen Partitur.
1022 $(piece).pdf: $(piece).ly $(notes)
1024 # Abhängigkeiten der Stimmen.
1025 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
1026 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
1027 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
1028 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
1029 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
1030 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
1032 # `make score' eintippen, um die große Partitur mit allen vier
1033 # Sätzen als eine Datei zu erstellen.
1037 # `make parts' tippen, um alle Stimmen zu erstellen.
1038 # `make foo.pdf' tippen, um die Stimme für das Instrument `foo' zu erstellen.
1039 # Beispiel: `make symphony-cello.pdf'.
1041 parts: $(piece)-cello.pdf \
1042 $(piece)-violinOne.pdf \
1043 $(piece)-violinTwo.pdf \
1044 $(piece)-viola.pdf \
1045 $(piece)-oboes.pdf \
1048 # `make movements' tippen um Dateien für die vier Sätze einzeln zu erstellen.
1050 movements: $(piece)I.pdf \
1055 all: score parts movements
1058 tar -cvvf stamitz.tar \ # this line begins with a tab
1059 --exclude=*pdf --exclude=*~ \
1060 --exclude=*midi --exclude=*.tar \
1064 Unter Windows ergeben sich bestimmte Komplikationen. Nachdem man
1065 GNU Make für Windows heruntergeladen und installiert hat, muss
1066 man den richtigen Pfad in den Umgebungsvariablen des Systems setzen,
1067 damit die DOS-Kommandozeile das Make-Programm finden kann. Um das
1068 vorzunehmen, kann mit der rechten Maustaste auf "Arbeitsplatz"
1069 klicken, dann @code{Eigenschaften} und @code{Erweitert} geklickt
1070 werden. Hier wählt man @code{Umgebungsvariablen}. In der
1071 Liste @code{Systemvariablen} wählt man @code{Path} und mit
1072 einem Klick auf @code{Bearbeiten} kann man den Pfad zu der
1073 @code{.exe}-Datei von GNU Make hinzufügen, der etwa wie
1077 C:\Program Files\GnuWin32\bin
1080 Die Make-Datei selber muss auch angepasst werden, um unterschiedliche
1081 Shell-Befehle zu verwenden und mit Leerzeichen umgehen zu können,
1082 die sich in einigen Standardverzeichnissen unter Windows befinden.
1083 Das @code{archive}-Ziel wird entfernt, da Windows den
1084 @code{tar}-Befehl nicht kennt, und Windows benutzt auch eine
1085 andere Dateiendung für midi-Dateien.
1092 LILY_CMD = lilypond -ddelete-intermediate-files \
1093 -dno-point-and-click \
1094 -djob-count=$(NUMBER_OF_PROCESSORS)
1096 # 8.3 Bezeichnung für CURDIR erhalten (Workaround wg. Leerzeichen in PATH)
1097 workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
1100 .SUFFIXES: .ly .ily .pdf .mid
1109 $(LILY_CMD) $< # diese Zeile beginnt mit Tabulator
1110 if exist "$*.pdf" move /Y "$*.pdf" PDF/ # begin with tab
1111 if exist "$*.mid" move /Y "$*.mid" MIDI/ # begin with tab
1123 $(piece)I.pdf: $(piece)I.ly $(notes)
1124 $(piece)II.pdf: $(piece)II.ly $(notes)
1125 $(piece)III.pdf: $(piece)III.ly $(notes)
1126 $(piece)IV.pdf: $(piece)IV.ly $(notes)
1128 $(piece).pdf: $(piece).ly $(notes)
1130 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
1131 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
1132 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
1133 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
1134 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
1135 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
1141 parts: $(piece)-cello.pdf \
1142 $(piece)-violinOne.pdf \
1143 $(piece)-violinTwo.pdf \
1144 $(piece)-viola.pdf \
1145 $(piece)-oboes.pdf \
1149 movements: $(piece)I.pdf \
1154 all: score parts movements
1157 Die nächste Make-Datei ist für ein @command{lilypond-book}-Dokument,
1158 das in LaTeX gesetzt wird. Das Projekt hat einen Index, welcher
1159 erfordert, dass der Befehl @command{latex} zweimal aufgerufen wird,
1160 um die Verweise zu aktualisieren. Ausgabedateien werden in einem
1161 @code{out}-Verzeichnis für die .pdf-Dateien gespeichert und in
1162 @code{htmlout} für die html-Dateien.
1171 LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
1172 LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
1173 PDF=cd $(OUTDIR) && pdflatex $(FILE)
1174 HTML=cd $(WEBDIR) && latex2html $(FILE)
1175 INDEX=cd $(OUTDIR) && makeindex $(FILE)
1176 PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &
1181 $(LILYBOOK_PDF) # begin with tab
1182 $(PDF) # begin with tab
1183 $(INDEX) # begin with tab
1184 $(PDF) # begin with tab
1185 $(PREVIEW) # begin with tab
1188 $(LILYBOOK_HTML) # begin with tab
1189 $(HTML) # begin with tab
1190 cp -R $(WEBDIR)/$(FILE)/ ./ # begin with tab
1191 $(BROWSER) $(FILE)/$(FILE).html & # begin with tab
1194 cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf # begin with tab
1197 rm -rf $(OUTDIR) # begin with tab
1200 rm -rf $(WEBDIR) # begin with tab
1203 tar -cvvf myproject.tar \ # begin this line with tab
1205 --exclude=htmlout/* \
1206 --exclude=myproject/* \
1213 TODO: soll auch unter Windows funktionieren
1215 Die vorige Make-Datei funktioniert nicht unter Windows. Als Alternative
1216 für Windows-Benutzer könnte man eine einfache batch-Datei erstellen,
1217 welche die erforderlichen Befehl enthält. Sie kümmert sich nicht
1218 um Abhängigkeiten, wie es eine Make-Datei kann, aber wenigstens
1219 wird die Kompilation auf einen einzigen Befehl beschränkt. Das folgende
1220 kann als Datei @command{build.bat} oder @command{build.cmd} gespeichert
1221 werden. Die Batch-Datei kann auf der Kommandozeile aufgerufen werden
1222 oder einfach doppelt angeklickt werden.
1225 lilypond-book --output=out --pdf myproject.lytex
1231 copy out\myproject.pdf MyProject.pdf
1237 @rprogram{Einrichtung für MacOS X},
1238 @rprogram{Benutzung auf der Kommandozeile},
1239 @rprogram{LilyPond-book}