1 @c -*- coding: utf-8; mode: texinfo; documentlanguage: de -*-
2 @c This file is part of lilypond.tely
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 Working on LilyPond projects
13 @chapter Working on LilyPond projects
15 Dieses Kapitel erklärt, wie bestimmte häufige Probleme zu
16 lösen oder ganz zu vermeiden sind. Wenn Sie schon
17 Programmiererfahrung mitbringen, erscheinen diese Hinweise
18 vielleicht überflüssig, aber es wird dennoch empfohlen, dieses Kapitel
23 * Suggestions for writing LilyPond input files::
24 * When things don't work::
26 * Make and Makefiles::
30 @node Suggestions for writing LilyPond input files
31 @section Suggestions for writing LilyPond input files
33 Jetzt sind Sie so weit, größere Stücke mit LilyPond zu schreiben --
34 nicht nur die kleinen Beispiele aus der Übung, sondern ganze Stücke.
35 Aber wie geht man das am besten an?
37 Solange LilyPond Ihre Dateien versteht und die Noten so setzt,
38 wie Sie das wollen, spielt es eigentlich keine Rolle, wie Ihre
39 Dateien aussehen. Es gibt aber trotzdem ein paar Dinge, die man
40 beim Schreiben von LilyPond-Code berücksichtigen sollte.
43 @item Was ist, wenn Sie einen Fehler machen? Die Struktur einer
44 LilyPond-Datei kann es erleichtern (oder erschweren), bestimmte
47 @item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen
48 wollen? Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten
49 wollen? Manche LilyPond-Dateien versteht man auf den ersten Blick,
50 über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.
52 @item Was ist, wenn sie Ihre Dateien auf eine neuere LilyPond-Version
53 aktualisieren wollen? Die Syntax der Eingabesprache verändert sich
54 allmählich mit Verbesserungen im Programm. Die meisten Veränderungen
55 können automatisch durch @code{convert-ly} gelöst werden, aber
56 bestimmte Änderungen brauchen Handarbeit. LilyPond-Dateien können
57 strukturiert werden, damit sie einfacher aktualisierbar sind.
61 * General suggestions::
62 * Typesetting existing music::
64 * Saving typing with variables and functions::
69 @node General suggestions
70 @subsection General suggestions
72 Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:
75 @item @strong{Schreiben Sie immer mit @code{\version} die
77 in jede Datei}. Beachten Sie, dass in allen Vorlagen die Versionsnummer
78 @code{\version "2.12.0"} eingetragen ist. Es empfiehlt sich, in alle
79 Dateien, unabhängig von ihrer Größe, den @code{\version}-Befehl
80 einzufügen. Persönliche Erfahrung hat gezeigt, dass es ziemlich
81 frustrierend sein kann zu erinnern, welche Programmversion man etwa
82 vor einem Jahr verwendet hat. Auch @code{convert-ly} benötigt die
85 @item @strong{Benutzen Sie Überprüfungen}: @ruser{Octave checks}, und
86 @ruser{Bar and bar number checks}. Wenn Sie hier und da diese
87 Überprüfungen einfügen, finden Sie einen möglichen Fehler weit
88 schneller. Wie oft aber ist @qq{hier und da}? Das hängt von der
89 Komplexität der Musik ab. ei einfachen Stücken reicht es vielleicht
90 ein- oder zweimal, in sehr komplexer Musik sollte man sie vielleicht
91 in jeden Takt einfügen.
93 @item @strong{Ein Takt pro Textzeile}. Wenn irgendetwas kompliziertes
94 vorkommt, entweder in der Musik selber oder in der Anpassung der
96 empfiehlt es sich oft, nur einen Takt pro Zeile zu schreiben.
97 Bildschirmplatz zu sparen, indem Sie acht Takte in eine Zeile zwängen,
98 hilft nicht weiter, wenn Sie ihre Datei @qq{debuggen} müssen.
100 @item @strong{Kommentieren Sie ihre Dateien}. Benutzen Sie entweder
101 Taktnummern (in regelmäßigen Abständen) oder Verweise auf musikalische
102 Themen (@qq{Zweites Thema in den Geigen}, @qq{vierte Variation} usw.).
103 Sie brauchen diese Kommentare vielleicht noch nicht, wenn Sie das Stück
104 notieren, aber spätestens wenn Sie nach ein paar Jahren etwas
106 wollen oder Sie den Quelltext an einen Freund weitergeben wollen,
107 ist es weitaus komplizierter, die Dateistruktur ohne Kommentare zu
108 verstehen, als wenn Sie sie rechtzeitig eingefügt hätten.
110 @item @strong{Schreiben Sie Klammern mit Einrückung}. Viele
111 Probleme entstehen durch ungerade Anzahl von @code{@{} and
114 @item @strong{Schreiben Sie Tondauerangaben} am Anfang von
115 Abschnitten und Bezeichnern. Wenn Sie beispielsweise
116 @code{c4 d e} am Anfang eines Abschnittes schreiben,
117 ersparen Sie sich viele Probleme, wenn Sie ihre Musik
118 eines Tages umarrangieren wollen.
120 @item @strong{Trennen Sie Einstellungen} von den eigentlichen
121 Noten. Siehe auch @ref{Saving typing with variables and functions}
128 @node Typesetting existing music
129 @subsection Typesetting existing music
131 Wenn Sie Musik aus einer fertigen Partitur kopieren (z. B. die
132 LilyPond-Eingabe einer gedruckten Partitur):
136 @item Schreiben Sie ein System ihrer Quelle nach dem anderen
137 (aber trotzdem nur einen Takt pro Textzeile) und überprüfen
138 Sie jedes System, nachdem Sie es fertig kopiert haben. Mit dem
139 @code{showLastLength}- oder @code{showFirstLenght}-Befehl können Sie den Übersetzungsprozess
140 beschleunigen. Siehe auch
141 @ruser{Skipping corrected music}.
143 @item Definieren Sie @code{mBreak = @{ \break @}} und schreiben Sie
144 @code{\mBreak} in der Quelldatei immer dann, wenn im Manuskript
145 ein Zeilenumbruch vorkommt. Das macht es einfacher, die gesetzte
146 Zeile mit den ursprünglichen Noten zu vergleichen. Wenn Sie die
147 Partitur fertig gestellt haben, könne Sie @code{mBreak = @{ @}},
148 also leer definieren, um diese manuellen Zeilenumbrüche zu entfernen.
149 Damit kann dann LilyPond selber entscheiden, wohin es passende
150 Zeilenumbrüche platziert.
152 @item Wenn Sie eine Stimme für ein transponierendes Instrument als eine
153 Variable notieren, wird empfohlen, dass die Noten von
156 \transpose c klingende-Tonhöhe @{...@}
159 eingefasst werden (wobei @code{klingende-Tonhöhe} die klingende Tonhöhe
160 des Instruments ist), sodass die Noten innerhalb der Variable für klingendes C
161 geschrieben sind. Sie können die Variable zurücktransponieren, wenn es
162 nötig ist, aber Sie müssen es nicht tun. Fehler in Transpositionen sind
163 treten seltener auf, wenn alle Noten in den Variablen für die gleiche
164 Ausgangstonhöhe geschrieben werden.
166 Denken Sie auch daran, dass Sie nur von/nach C transponieren. Das heißt,
167 dass die einzigen anderen Tonhöhen, die Sie in Transpositionen benutzen,
168 die Tonhöhen der Instrumente sind, für die Sie schreiben: @code{bes} für
169 eine B-Trompete oder @code{aes} für eine As-Klarinette usw.
175 @subsection Large projects
177 Besonders wenn Sie an größeren Projekten arbeiten, ist es
178 unumgänglich, dass Sie ihre LilyPond-Dateien klar strukturieren.
182 @item @strong{Verwenden Sie Variablen für jede Stimme}, innerhalb
183 der Definition sollte so wenig Struktur wie möglich sein. Die
184 Struktur des @code{\score}-Abschnittes verändert sich am ehesten,
185 während die @code{violine}-Definition sich wahrscheinlich mit einer
186 neuen Programmversion nicht verändern wird.
189 violine = \relative c'' @{
202 @item @strong{Trennen Sie Einstellungen von den Noten}. Diese
203 Empfehlung wurde schon im Abschnitt @ref{General suggestions} gegeben,
204 aber für große Projekte ist es unumgänglich. Muss z. B. die
205 Definition für @code{fdannp} verändert werden, so braucht
206 man es nur einmal vorzunehmen und die Noten in der Geigenstimme,
207 @code{violin}, bleiben unberührt.
211 \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
212 violin = \relative c'' @{
220 @node Saving typing with variables and functions
221 @subsection Saving typing with variables and functions
226 Bis jetzt haben Sie immer etwa solche Noten gesehen:
228 @lilypond[quote,verbatim,ragged-right]
229 hornNotes = \relative c'' { c4 b dis c }
237 Das könnte auch nützlich in Minimal-Music sein:
239 @lilypond[quote,verbatim,ragged-right]
240 fragmentA = \relative c'' { a4 a8. b16 }
241 fragmentB = \relative c'' { a8. gis16 ees4 }
242 violin = \new Staff { \fragmentA \fragmentA \fragmentB \fragmentA }
250 Sie können diese Bezeichner oder Variablen aber auch für
251 (eigene) Einstellungen verwenden:
253 @lilypond[quote,verbatim,ragged-right]
254 dolce = \markup{ \italic \bold dolce }
255 padText = { \once \override TextScript #'padding = #5.0 }
256 fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p }
257 violin = \relative c'' {
259 c4._\dolce b8 a8 g a b |
261 c4.^"hi there!" d8 e' f g d |
262 c,4.\fthenp b8 c4 c-. |
269 \layout{ragged-right=##t}
273 Die Variablen haben in diesem Beispiel deutlich die
274 Tipparbeit erleichtert. Aber es lohnt sich, sie zu
275 einzusetzen, auch wenn man sie nur einmal anwendet,
276 denn sie vereinfachen die Struktur.
277 Hier ist das vorangegangene Beispiel ohne
278 Variablen. Es ist sehr viel komplizierter zu lesen,
279 besonders die letzte Zeile.
282 violin = \relative c'' @{
284 c4._\markup@{ \italic \bold dolce @} b8 a8 g a b |
285 \once \override TextScript #'padding = #5.0
286 c4.^"hi there!" d8 e' f g d |
287 c,4.\markup@{ \dynamic f \italic \small @{ 2nd @}
288 \hspace #0.1 \dynamic p @} b8 c4 c-. |
293 @c TODO Replace the following with a better example -td
294 @c Skylining handles this correctly without padText
296 Bis jetzt wurde nur statische Substitution vorgestellt
297 -- wenn LilyPond den Befehl @code{\padText} findet, wird
298 er ersetzt durch durch unsere vorherige Definition (alles,
299 was nach dem @code{padtext =} kommt).
301 LilyPond kennt aber auch nicht-statische Substitutionen (man
302 kann sie sich als Funktionen vorstellen).
304 @lilypond[quote,verbatim,ragged-right]
306 #(define-music-function (parser location padding) (number?)
308 \once \override TextScript #'padding = #$padding
316 c4^"piu mosso" fis a g
320 Die Benutzung von Variablen hilft auch, viele Schreibarbeit zu
321 vermeiden, wenn die Eingabesyntax von LilyPond sich verändert
322 (siehe auch @ref{Updating old files}). Wenn nur eine einzige
323 Definition (etwa @code{\dolce}) für alle Dateien verwendet wird
324 (vgl. @ref{Style sheets}), muss nur diese einzige Definition
325 verändert werden, wenn sich die Syntax ändert. Alle Verwendungen
326 des Befehles beziehen sich dann auf die neue Definition.
329 @subsection Style sheets
331 Die Ausgabe, die LilyPond erstellt, kann sehr stark modifiziert
332 werden, siehe @ref{Tweaking output} für Einzelheiten. Aber wie
333 kann man diese Änderungen auf eine ganze Serie von Dateien
334 anwenden? Oder die Einstellungen von den Noten trennen? Das
335 Verfahren ist ziemlich einfach.
337 Hier ist ein Beispiel. Es ist nicht schlimm, wenn Sie nicht auf
338 Anhieb die Abschnitte mit den ganzen @code{#()} verstehen. Das
339 wird im Kapitel @ref{Advanced tweaks with Scheme} erklärt.
341 @lilypond[quote,verbatim,ragged-right]
342 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
343 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
345 inst = #(define-music-function (parser location string) (string?)
349 'text (markup #:bold (#:box string))))
353 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
355 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
359 Es treten einige Probleme mit überlappenden Symbolen auf. Sie
360 werden beseitigt mit den Tricks aus dem Kapitel @ref{Moving objects}.
361 Aber auch die @code{mpdolce} und @code{inst}-Definitionen
362 können verbessert werden. Sie produzieren das Ergebnis, das
363 gewünscht ist, aber es wäre schön, sie auch in anderen Stücken
364 verwenden zu können. Man könnte sie natürlich einfach kopieren
365 und in die anderen Dateien einfügen, aber das ist lästig. Die
366 Definitionen verbleiben auch in der Notendatei und diese @code{#()}
367 sehen nicht wirklich schön aus. Sie sollen in einer anderen
368 Datei versteckt werden:
371 %%% speichern in einer Datei "definitions.ily"
372 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
373 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
375 inst = #(define-music-function (parser location string) (string?)
379 'text (markup #:bold (#:box string))))
382 Auf diese Datei kann dann später mit dem @code{\include}-Befehl
383 im oberen Teil der LilyPond-Datei zurückgegriffen werden. (Die
384 Erweiterung @code{.ily} wird benutzt, um diese eingefügte Datei,
385 die nicht alleine kompiliert werden kann, von der Hauptdatei zu
387 Jetzt muss natürlich noch die Notendatei angepasst werden (gespeichert
388 unter dem Namen @file{"music.ly"}).
390 @c We have to do this awkward example/lilypond-non-verbatim
391 @c because we can't do the \include stuff in the manual.
394 \include "definitions.ily"
398 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
400 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
404 @lilypond[quote,ragged-right]
405 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
406 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
408 inst = #(define-music-function (parser location string) (string?)
412 'text (markup #:bold (#:box string))))
416 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
418 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
422 Das sieht schon besser aus, aber es sind noch einige Verbesserungen
424 Das Glissando ist schwer zu sehen, also soll es etwas dicker erscheinen
425 und dichter an den Notenköpfen gesetzt werden. Das Metronom-Zeichen
426 soll über dem Schlüssel erscheinen, nicht über der ersten Note. Und
427 schließlich kann unser Kompositionsprofessor @qq{C}-Taktangaben
428 überhaupt nicht leiden, also
429 müssen sie in @qq{4/4} verändert werden.
431 Diese Veränderungen sollten Sie aber nicht in der @file{music.ly}-Datei
432 vornehmen. Ersetzen Sie die @file{definitions.ily}-Datei hiermit:
436 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
437 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
439 inst = #(define-music-function (parser location string) (string?)
443 'text (markup #:bold (#:box string))))
447 \override MetronomeMark #'extra-offset = #'(-9 . 0)
448 \override MetronomeMark #'padding = #'3
451 \override TimeSignature #'style = #'numbered
454 \override Glissando #'thickness = #3
455 \override Glissando #'gap = #0.1
460 @lilypond[quote,ragged-right]
461 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
462 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
464 inst = #(define-music-function (parser location string) (string?)
468 'text (markup #:bold (#:box string))))
472 \override MetronomeMark #'extra-offset = #'(-9 . 0)
473 \override MetronomeMark #'padding = #'3
476 \override TimeSignature #'style = #'numbered
479 \override Glissando #'thickness = #3
480 \override Glissando #'gap = #0.1
486 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
488 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
492 Das sieht schon besser aus! Aber angenommen Sie möchten dieses
493 Stück jetzt veröffentlichen. Ihr Kompositionsprofessor mag
494 die @qq{C}-Taktangaben nicht, aber Sie finden sie irgendwie
495 schöner. Also kopieren Sie die Datei @file{definitions.ily} nach
496 @file{web-publish.ily} und verändern diese. Weil die Noten
497 in einer PDF-Datei auf dem Bildschirm angezeigt werden sollen,
498 bietet es sich auch an, die gesamte Ausgabe zu vergrößern.
502 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
503 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
505 inst = #(define-music-function (parser location string) (string?)
509 'text (markup #:bold (#:box string))))
511 #(set-global-staff-size 23)
514 \override MetronomeMark #'extra-offset = #'(-9 . 0)
515 \override MetronomeMark #'padding = #'3
520 \override Glissando #'thickness = #3
521 \override Glissando #'gap = #0.1
526 @lilypond[quote,ragged-right]
527 mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
528 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
530 inst = #(define-music-function (parser location string) (string?)
534 'text (markup #:bold (#:box string))))
536 #(set-global-staff-size 23)
539 \override MetronomeMark #'extra-offset = #'(-9 . 0)
540 \override MetronomeMark #'padding = #'3
543 \override Glissando #'thickness = #3
544 \override Glissando #'gap = #0.1
550 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
552 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
556 In der Notendatei muss jetzt nur noch @code{\include "definitions.ily"}
557 durch @code{\include "web-publish.ily"} ausgetauscht werden.
558 Das könnte man natürlich noch weiter vereinfachen. Also
559 eine Datei @file{definitions.ily}, die nur die Definitionen
560 von @code{mpdolce} und @code{inst} enthält, eine Datei
561 @file{web-publish.ily}, die alle die Änderungen für den
562 @code{\layout}-Abschnitt enthält und eine Datei @file{university.ily}
563 für eine Ausgabe, die den Wünschen des Professors entspricht.
564 Der Anfang der @file{music.ly}-Datei würde dann so aussehen:
567 \include "definitions.ily"
569 %%% Nur eine der beiden Zeilen auskommentieren!
570 \include "web-publish.ily"
571 %\include "university.ily"
574 Durch diese Herangehensweise kann auch bei der Erstellung
575 von nur einer Ausgabeversion Arbeit gespart werden. Ich
576 benutze ein halbes Dutzend verschiedener Stilvorlagen
577 für meine Projekte. Jede Notationsdatei fängt an mit
578 @code{\include "../global.ily"}, welches folgenden Inhalt hat:
584 #(ly:set-option 'point-and-click #f)
585 \include "../init/init-defs.ily"
586 \include "../init/init-layout.ily"
587 \include "../init/init-headers.ily"
588 \include "../init/init-paper.ily"
592 @node When things don't work
593 @section When things don't work
596 * Updating old files::
597 * Troubleshooting (taking it all apart)::
601 @node Updating old files
602 @subsection Updating old files
604 Die Syntax von LilyPond verändert sich ab und zu. Wenn LilyPond
605 besser wird, muss auch die Syntax (Eingabesprache) entsprechend
606 angepasst werden. Teilweise machen diese Veränderungen die
607 Eingabesprache einfacher lesbar, teilweise dienen sie dazu, neue
608 Eigenschaften des Programmes benutzbar zu machen.
610 LilyPond stellt ein Programm bereit, das Aktualisierungen
611 vereinfacht: @code{convert-ly}. Einzelheiten zur Programmbenutzung
612 finden sich in @rprogram{Updating files with convert-ly}.
614 Leider kann @code{convert-ly} nicht alle Veränderungen der Syntax
615 berücksichtigen. Hier werden einfache @qq{Suchen und
616 Ersetzen}-Veränderungen vorgenommen (wie etwa @code{raggedright} zu
617 @code{ragged-right}), aber einige Veränderungen sind zu
618 kompliziert. Die Syntax-Veränderungen, die das Programm nicht
619 berücksichtigt, sind im Kapitel @rprogram{Updating files with
620 convert-ly} aufgelistet.
622 Zum Beispiel wurden in LilyPond 2.4 und früheren Versionen
623 Akzente und Umlaute mit LaTeX-Befehlen eingegeben, ein
624 @qq{No\"el} etwa ergäbe das französische Wort für Weihnachten.
625 In LilyPond 2.6 und höher müssen diese Sonderzeichen direkt
626 als utf-8-Zeichen eingegeben werden, in diesem Fall also @qq{ë}.
627 @code{convert-ly} kann nicht alle dieser LaTeX-Befehle
628 verändern, das muss manuell vorgenommen werden.
631 @node Troubleshooting (taking it all apart)
632 @subsection Troubleshooting (taking it all apart)
634 Früher oder später werden Sie in die Lage kommen,
635 dass LilyPond Ihre Datei nicht kompilieren will. Die
636 Information, die LilyPond während der Übersetzung
637 gibt, können Ihnen helfen, den Fehler zu finden, aber
638 in vielen Fällen müssen Sie nach der Fehlerquelle
641 Die besten Hilfsmittel sind in diesem Fall das Zeilen-
642 und Blockkommentar (angezeigt durch @code{%} bzw.
643 @code{%@{ ... %@}}). Wenn Sie nicht bestimmen können,
644 wo sich das Problem befindet, beginnen Sie damit, große
645 Teile des Quelltextes auszukommentieren. Nachdem Sie
646 einen Teil auskommentiert haben, versuchen Sie, die Datei
647 erneut zu übersetzen. Wenn es jetzt funktioniert, muss
648 sich das Problem innerhalb der Kommentare befinden.
649 Wenn es nicht funktioniert, müssen Sie weitere Teile
650 auskommentieren bis sie eine Version haben, die funktioniert.
652 In Extremfällen bleibt nur noch solch ein Beispiel übrig:
666 (also eine Datei ohne Noten).
668 Geben Sie nicht auf, wenn das vorkommen sollte. Nehmen
669 Sie das Kommentarzeichen von einem Teil wieder weg, sagen
670 wir der Bassstimme, und schauen Sie, ob es funktioniert.
671 Wenn nicht, dann kommentieren Sie die gesamte Bassstimme
672 aus, aber nicht den @code{\bass}-Befehl in dem
673 @code{\score}-Abschnitt:
676 bass = \relative c' @{
684 Jetzt beginnen Sie damit, langsam Stück für Stück der
685 Bassstimme wieder hineinzunehmen, bis Sie die problematische
688 Eine andere nützliche Technik zur Problemlösung ist es,
689 @ref{Minimal examples} zu konstruieren.
692 @node Minimal examples
693 @subsection Minimal examples
695 Ein Minimalbeispiel ist eine Beispieldatei, die so klein wie
696 möglich ist. Diese Beispiele sind sehr viel einfacher zu
697 verstehen als die langen Originaldateien. Minimalbeispiele
702 @item Fehlerberichte zu erstellen,
703 @item eine Hilfeanfrage an die E-Mail-Liste zu schicken,
704 @item Ein Beispiel zur @uref{http://lsr@/.dsi@/.unimi@/.it/,LilyPond
705 Schnipselsammlung} hinzuzufügen.
708 Um ein Beispiel zu konstruieren, das so klein wie möglich ist,
709 gibt es eine einfache Regel: Alles nicht Notwendige entfernen.
710 Wenn Sie unnötige Teile einer Datei entfernen, bietet es sich an,
711 sie auszukommentieren und nicht gleich zu löschen. Auf diese Weise
712 können Sie eine Zeile leicht wieder mit aufnehmen, sollten Sie sie
713 doch brauchen, anstatt sie von Anfang an neu zu schreiben.
715 Es gibt zwei Ausnahmen dieser @qq{So klein wie möglich}-Regel:
718 @item Fügen Sie immer einen @code{\version}Befehl ein.
719 @item Wenn es möglich ist, benutzen Sie @code{\paper@{ ragged-right = ##t @}}
720 am Beginn des Beispiels.
723 Der Sinn der Minimalbeispiele ist, dass sie einfach lesbar sind:
726 @item Vermeiden Sie es, komplizierte Noten, Schlüssel oder Taktangaben
727 zu verwenden, es sei denn, Sie wollen genau an diesen Elementen
729 @item Benutzen Sie keine @code{\override}-Befehle, wenn sie nicht der
730 Zweck des Beispieles sind.
734 @node Scores and parts
735 @section Scores and parts
737 Orchesternoten werden alle zweimal gesetzt. Erstens als Stimmen für
738 die Musiker, und dann als große Partitur für den Dirigenten. Mit
740 kann hier doppelte Arbeit erspart werden. Die Musik muss nur einmal
741 eingegeben werden und wird in einer Variable abgelegt. Der Inhalt
743 Variable wird dann benutzt, um sowohl die Stimme als auch die Partitur
746 Es bietet sich an, die Noten in eigenen Dateien zu speichern. Sagen wir
747 beispielsweise, dass in der Datei @file{Horn-Noten.ly} die folgenden
748 Noten eines Duetts für Horn und Fagott gespeichert sind:
751 HornNoten = \relative c @{
758 Daraus wird dann eine eigene Stimme gemacht, indem folgende Datei
763 \include "Horn-Noten.ly"
765 instrument = "Horn in F"
769 \transpose f c' \HornNoten
776 \include "Horn-Noten.ly"
780 setzt den Inhalt der Datei @file{Horn-Noten.ly} an die Stelle des
781 Befehls in die aktuelle Datei. Damit besteht also eine Definition
782 für @code{HornNoten}, so dass die Variable verwendet werden kann.
783 Der Befehl @code{\transpose f@tie{}c'} zeigt an, dass das Argument,
784 also @code{\HornNoten}, um eine Quinte nach oben transponiert wird.
785 Klingendes @q{f} wird also als @code{c'} notiert. Das entspricht
786 der Notation eines Waldhorns in F. Die Transposition zeigt die folgende
789 @lilypond[quote,ragged-right]
790 \transpose f c' \relative c {
796 In der Musik für mehrere Instrumente kommt es oft vor, dass eine Stimme
797 für mehrere Takte nicht spielt. Das wird mit einer besonderen Pause
798 angezeigt, dem Pausenzeichen für mehrere Takte (engl. multi-measure
799 rest). Sie wird mit dem @emph{großen} Buchstaben @samp{R} eingegeben,
800 gefolgt von einer Dauer (@code{1}@tie{}für eine Ganze, @code{2}@tie{}
801 für eine Halbe usw.). Indem man die Dauer multipliziert, können längere
802 Pausen erstellt werden. Z. B. dauert diese Pause drei Takte eines
809 Wenn die Stimme gedruckt wird, müssen diese Pausen zusammengezogen
811 Das wird durch eine Variable erreicht:
814 \set Score.skipBars = ##t
818 Dieser Befehl setzt die Eigenschaft des @code{skipBars} (@qq{überspringe
819 Takte}) auf wahr (@code{##t}). Wenn diese Option und die Pause
820 zu der Musik des Beispiels gesetzt wird, erhält man folgendes Ergebnis:
822 @lilypond[quote,ragged-right]
823 \transpose f c' \relative c {
825 \set Score.skipBars = ##t
831 Die Partitur wird erstellt, indem alle Noten zusammengesetzt werden.
832 Angenommen, die andere Stimme trägt den Namen @code{FagottNoten}
833 und ist in der Datei @file{Fagott-Noten.ly} gespeichert. Die
834 Partitur sieht dann folgendermaßen aus:
837 \include "Fagott-Noten.ly"
838 \include "Horn-Noten.ly"
841 \new Staff \HornNoten
842 \new Staff \FagottNoten
847 Und mit LilyPond übersetzt:
849 @lilypond[quote,ragged-right]
857 r4 d,8 f | gis4 c | b bes |
858 a8 e f4 | g d | gis f
864 @node Make and Makefiles
865 @section Make and Makefiles
871 Fast alle Betriebssysteme, auf denen LilyPond benutzt werden kann,
872 unterstützen ein Programm mit dem Namen @code{make}. Dieses Programm
873 liest eine besondere Datei mit der Bezeichnung @code{Makefile},
874 die definiert, welche Dateien von welchen anderen Dateien abhängen und
875 welche Befehle für das Betriebssystem nötig sind, um eine Datei aus
876 einer anderen zu erstellen. Ein Makefile könnte etwa erklären, wie
877 @code{ballad.pdf} und @code{ballad.midi} aus @code{ballad.ly}
878 erstellt werden können, indem LilyPond aufgerufen wird.
880 Es gibt Fällen, wenn es sich sehr stark empfiehlt, ein @code{Makefile}
881 für das aktuelle Projekt zu erstellen, entweder zur eigenen Bequemlichkeit,
882 oder aber auch als Hilfe für andere, die vielleicht einmal die
883 Quelldateien lesen und verstehen wollen. Insbesondere bei großen Projekten
884 mit vielen eingefügten Dateien und unterschiedlichen Ausgabeoptionen
885 (etwa Partitur, einzelne Stimmen, Dirigierpartitur, Klavierauszug usw.),
886 aber auch bei Projekten, die komplizierte Programmaufrufe zur Verarbeitung
887 erfordern (wenn man etwa mit @code{lilypond-book} arbeitet), lohnt
888 sich die Erstellung einer Make-Datei. Diese Dateien können sehr
889 unterschiedliche ausfallen, und ihre Komplexität und Flexibilität kann
890 den Bedürfnissen aber auch Kenntnissen des Schreibers angepasst werden.
891 Das Programm GNU Make ist auf GNU/Linux Distributionen und MacOS X
892 installiert, aber es ist auch für Windows erhältlich.
894 Das @strong{GNU Make Manual} gibt eine vollständige Anleitung, wie
895 @code{make} benutzt werden kann. Hier sollen nur einige kleine
896 Blicke auf die vielfältigen Möglichkeiten geworfen werden.
898 Die Befehle, um Regeln in einer Make-Datei zu erstellen, unterscheidet
899 sich zwischen den Betriebssystemen. Die verschiedenen Linuxe und
900 MacOS X benutzen @code{bash}, während unter Windows @code{cmd} eingesetzt
901 wird. Unter MacOS X muss man das System so konfigurieren, dass
902 die Kommandozeile benutzt wird. Hier einige Beispiele für Make-Dateien,
903 mit Versionen für Linux/MacOS und Windows.
905 Das erste Beispiel ist für ein Orchesterstück in vier Stätzen unt mit
906 der folgenden Dateistruktur:
923 | |-- symphony-cello.ly
924 | |-- symphony-horn.ly
925 | |-- symphony-oboes.ly
926 | |-- symphony-viola.ly
927 | |-- symphony-violinOne.ly
928 | `-- symphony-violinTwo.ly
938 Die @code{.ly}-Dateien un den Verzeichnissen @code{Scores} und
939 @code{Parts} erhalten ihrere Noten aus @code{.ily}-Dateien, die
940 sich im @code{Notes}-Verzeichnis befinden:
943 %%% Kopfzeile der Datei "symphony-cello.ly"
944 \include ../definitions.ily
945 \include ../Notes/cello.ily
948 Die Make-Datei hat die Ziele @code{score} (das gesamte Stück als
949 große Partitur), @code{movements} (die einzelnen Sätze als große
950 Partitur) und @code{parts} (die einzelnen Stimmen für die Spieler).
951 Es gibt auch das Ziel @code{archive}, welches ein Tar-Archiv
952 der Quelldateien erstellt, etwa um die Quellen über das Internet
953 oder per E-Mail zu verteilen. Hier die Make-Datei für GNU/Linux
954 oder MacOS X. Sie sollte unter dem Namen @code{Makefile} im obersten
955 Verzeichnis des Projektes gespeichert werden:
957 @warning{Wenn ein Ziel oder eine Musterregel definiert ist, müssen
958 die folgenden Zeilen mit Tabulatoren, nicht mit Leerzeichen beginnen.}
961 # Namensstamm der Ausgabedateien
963 # finde heraus, wieviele Prozessoren vorhanden sind
964 CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
965 # Der Befehl, um lilypond aufzurufen
966 LILY_CMD = lilypond -ddelete-intermediate-files \
967 -dno-point-and-click -djob-count=$(CPU_CORES)
969 # Die Endungen, die im Makefile benutzt werden
970 .SUFFIXES: .ly .ily .pdf .midi
972 # Eingabe- und Ausgabedateien werden in den Verzeichnissen durchsucht,
973 # die sich in der VPATH-Variable befinden. Alle sind Unterverzeichnisse
974 # des aktuellen Verzeichnisses (angegeben durch die GNU make-Variable
982 # Die Musterregel, um PDF und MIDI-Dateien aus der LY-Eingabedatei
983 # zu erstellen. Die .pdf-Ausgabedateien werden in das
984 # `PDF'-Unterverzeichnis abgelegt, die .midi-Dateien in das
985 # `MIDI'-Unterverzeichnis.
987 $(LILY_CMD) $<; \ # this line begins with a tab
988 if test -f "$*.pdf"; then \
991 if test -f "$*.midi"; then \
992 mv "$*.midi" MIDI/; \
1003 # Abhängigkeiten der einzelnen Sätze.
1004 $(piece)I.pdf: $(piece)I.ly $(notes)
1005 $(piece)II.pdf: $(piece)II.ly $(notes)
1006 $(piece)III.pdf: $(piece)III.ly $(notes)
1007 $(piece)IV.pdf: $(piece)IV.ly $(notes)
1009 # Abhängigkeiten der großen Partitur.
1010 $(piece).pdf: $(piece).ly $(notes)
1012 # Abhängigkeiten der Stimmen.
1013 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
1014 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
1015 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
1016 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
1017 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
1018 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
1020 # `make score' eintippen, um die große Partitur mit allen vier
1021 # Sätzen als eine Datei zu erstellen.
1025 # `make parts' tippen, um alle Stimmen zu erstellen.
1026 # `make foo.pdf' tippen, um die Stimme für das Instrument `foo' zu erstellen.
1027 # Beispiel: `make symphony-cello.pdf'.
1029 parts: $(piece)-cello.pdf \
1030 $(piece)-violinOne.pdf \
1031 $(piece)-violinTwo.pdf \
1032 $(piece)-viola.pdf \
1033 $(piece)-oboes.pdf \
1036 # `make movements' tippen um Dateien für die vier Sätze einzeln zu erstellen.
1038 movements: $(piece)I.pdf \
1043 all: score parts movements
1046 tar -cvvf stamitz.tar \ # this line begins with a tab
1047 --exclude=*pdf --exclude=*~ \
1048 --exclude=*midi --exclude=*.tar \
1052 Unter Windows ergeben sich bestimmte Komplikationen. Nachdem man
1053 GNU Make für Windows heruntergeladen und installiert hat, muss
1054 man den richtigen Pfad in den Umgebungsvariablen des Systems setzen,
1055 damit die DOS-Kommandozeile das Make-Programm finden kann. Um das
1056 vorzunehmen, kann mit der rechten Maustaste auf "Arbeitsplatz"
1057 klicken, dann @code{Eigenschaften} und @code{Erweitert} geklickt
1058 werden. Hier wählt man @code{Umgebungsvariablen}. In der
1059 Liste @code{Systemvariablen} wählt man @code{Path} und mit
1060 einem Klick auf @code{Bearbeiten} kann man den Pfad zu der
1061 @code{.exe}-Datei von GNU Make hinzufügen, der etwa wie
1065 C:\Program Files\GnuWin32\bin
1068 Die Make-Datei selber muss auch angepasst werden, um unterschiedliche
1069 Shell-Befehle zu verwenden und mit Leerzeichen umgehen zu können,
1070 die sich in einigen Standardverzeichnissen unter Windows befinden.
1071 Das @code{archive}-Ziel wird entfernt, da Windows den
1072 @code{tar}-Befehl nicht kennt, und Windows benutzt auch eine
1073 andere Dateiendung für midi-Dateien.
1080 LILY_CMD = lilypond -ddelete-intermediate-files \
1081 -dno-point-and-click \
1082 -djob-count=$(NUMBER_OF_PROCESSORS)
1084 # 8.3 Bezeichnung für CURDIR erhalten (Workaround wg. Leerzeichen in PATH)
1085 workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
1088 .SUFFIXES: .ly .ily .pdf .mid
1097 $(LILY_CMD) $< # diese Zeile beginnt mit Tabulator
1098 if exist "$*.pdf" move /Y "$*.pdf" PDF/ # begin with tab
1099 if exist "$*.mid" move /Y "$*.mid" MIDI/ # begin with tab
1111 $(piece)I.pdf: $(piece)I.ly $(notes)
1112 $(piece)II.pdf: $(piece)II.ly $(notes)
1113 $(piece)III.pdf: $(piece)III.ly $(notes)
1114 $(piece)IV.pdf: $(piece)IV.ly $(notes)
1116 $(piece).pdf: $(piece).ly $(notes)
1118 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
1119 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
1120 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
1121 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
1122 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
1123 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
1129 parts: $(piece)-cello.pdf \
1130 $(piece)-violinOne.pdf \
1131 $(piece)-violinTwo.pdf \
1132 $(piece)-viola.pdf \
1133 $(piece)-oboes.pdf \
1137 movements: $(piece)I.pdf \
1142 all: score parts movements
1145 Die nächste Make-Datei ist für ein @command{lilypond-book}-Dokument,
1146 das in LaTeX gesetzt wird. Das Projekt hat einen Index, welcher
1147 erfordert, dass der Befehl @command{latex} zweimal aufgerufen wird,
1148 um die Verweise zu aktualisieren. Ausgabedateien werden in einem
1149 @code{out}-Verzeichnis für die .pdf-Dateien gespeichert und in
1150 @code{htmlout} für die html-Dateien.
1159 LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
1160 LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
1161 PDF=cd $(OUTDIR) && pdflatex $(FILE)
1162 HTML=cd $(WEBDIR) && latex2html $(FILE)
1163 INDEX=cd $(OUTDIR) && makeindex $(FILE)
1164 PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &
1169 $(LILYBOOK_PDF) # begin with tab
1170 $(PDF) # begin with tab
1171 $(INDEX) # begin with tab
1172 $(PDF) # begin with tab
1173 $(PREVIEW) # begin with tab
1176 $(LILYBOOK_HTML) # begin with tab
1177 $(HTML) # begin with tab
1178 cp -R $(WEBDIR)/$(FILE)/ ./ # begin with tab
1179 $(BROWSER) $(FILE)/$(FILE).html & # begin with tab
1182 cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf # begin with tab
1185 rm -rf $(OUTDIR) # begin with tab
1188 rm -rf $(WEBDIR) # begin with tab
1191 tar -cvvf myproject.tar \ # begin this line with tab
1193 --exclude=htmlout/* \
1194 --exclude=myproject/* \
1201 TODO: soll auch unter Windows funktionieren
1203 Die vorige Make-Datei funktioniert nicht unter Windows. Als Alternative
1204 für Windows-Benutzer könnte man eine einfache batch-Datei erstellen,
1205 welche die erforderlichen Befehl enthält. Sie kümmert sich nicht
1206 um Abhängigkeiten, wie es eine Make-Datei kann, aber wenigstens
1207 wird die Kompilation auf einen einzigen Befehl beschränkt. Das folgende
1208 kann als Datei @command{build.bat} oder @command{build.cmd} gespeichert
1209 werden. Die Batch-Datei kann auf der Kommandozeile aufgerufen werden
1210 oder einfach doppelt angeklickt werden.
1213 lilypond-book --output=out --pdf myproject.lytex
1219 copy out\myproject.pdf MyProject.pdf
1225 @rprogram{Setup for MacOS X},
1226 @rprogram{Command-line usage},
1227 @rprogram{LilyPond-book}