1 @c -*- coding: utf-8; mode: texinfo; -*-
2 @c This file is part of lilypond.tely
4 Translation of GIT committish: 5395f0433b4f09b18360118a23227a4a3cef8e72
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::
29 @node Suggestions for writing LilyPond input files
30 @section Suggestions for writing LilyPond input files
32 Jetzt sind Sie so weit, größere Stücke mit LilyPond zu schreiben --
33 nicht nur die kleinen Beispiele aus der Übung, sondern ganze Stücke.
34 Aber wie geht man das am besten an?
36 Solange LilyPond Ihre Dateien versteht und die Noten so setzt,
37 wie Sie das wollen, spielt es eigentlich keine Rolle, wie Ihre
38 Dateien aussehen. Es gibt aber trotzdem ein paar Dinge, die man
39 beim Schreiben von LilyPond-Code berücksichtigen sollte.
42 @item Was ist, wenn Sie einen Fehler machen? Die Struktur einer
43 LilyPond-Datei kann es erleichtern (oder erschweren), bestimmte
46 @item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen
47 wollen? Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten
48 wollen? Manche LilyPond-Dateien versteht man auf den ersten Blick,
49 über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.
51 @item Was ist, wenn sie Ihre Dateien auf eine neuere LilyPond-Version
52 aktualisieren wollen? Die Syntax der Eingabesprache verändert sich
53 allmählich mit Verbesserungen im Programm. Die meisten Veränderungen
54 können automatisch durch @code{convert-ly} gelöst werden, aber
55 bestimmte Änderungen brauchen Handarbeit. LilyPond-Dateien können
56 strukturiert werden, damit sie einfacher aktualisierbar sind.
60 * General suggestions::
61 * Typesetting existing music::
63 * Saving typing with variables and functions::
68 @node General suggestions
69 @subsection General suggestions
71 Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:
74 @item @strong{Schreiben Sie immer mit @code{\version} die
76 in jede Datei}. Beachten Sie, dass in allen Vorlagen die Versionsnummer
77 @code{\version "2.12.0"} eingetragen ist. Es empfiehlt sich, in alle
78 Dateien, unabhängig von ihrer Größe, den @code{\version}-Befehl
79 einzufügen. Persönliche Erfahrung hat gezeigt, dass es ziemlich
80 frustrierend sein kann zu erinnern, welche Programmversion man etwa
81 vor einem Jahr verwendet hat. Auch @code{convert-ly} benötigt die
84 @item @strong{Benutzen Sie Überprüfungen}: @ruser{Octave checks}, und
85 @ruser{Bar and bar number checks}. Wenn Sie hier und da diese
86 Überprüfungen einfügen, finden Sie einen möglichen Fehler weit
87 schneller. Wie oft aber ist @qq{hier und da}? Das hängt von der
88 Komplexität der Musik ab. ei einfachen Stücken reicht es vielleicht
89 ein- oder zweimal, in sehr komplexer Musik sollte man sie vielleicht
90 in jeden Takt einfügen.
92 @item @strong{Ein Takt pro Textzeile}. Wenn irgendetwas kompliziertes
93 vorkommt, entweder in der Musik selber oder in der Anpassung der
95 empfiehlt es sich oft, nur einen Takt pro Zeile zu schreiben.
96 Bildschirmplatz zu sparen, indem Sie acht Takte in eine Zeile zwängen,
97 hilft nicht weiter, wenn Sie ihre Datei @qq{debuggen} müssen.
99 @item @strong{Kommentieren Sie ihre Dateien}. Benutzen Sie entweder
100 Taktnummern (in regelmäßigen Abständen) oder Verweise auf musikalische
101 Themen (@qq{Zweites Thema in den Geigen}, @qq{vierte Variation} usw.).
102 Sie brauchen diese Kommentare vielleicht noch nicht, wenn Sie das Stück
103 notieren, aber spätestens wenn Sie nach ein paar Jahren etwas
105 wollen oder Sie den Quelltext an einen Freund weitergeben wollen,
106 ist es weitaus komplizierter, die Dateistruktur ohne Kommentare zu
107 verstehen, als wenn Sie sie rechtzeitig eingefügt hätten.
109 @item @strong{Schreiben Sie Klammern mit Einrückung}. Viele
110 Probleme entstehen durch ungerade Anzahl von @code{@{} and
113 @item @strong{Schreiben Sie Tondauerangaben} am Anfang von
114 Abschnitten und Bezeichnern. Wenn Sie beispielsweise
115 @code{c4 d e} am Anfang eines Abschnittes schreiben,
116 ersparen Sie sich viele Probleme, wenn Sie ihre Musik
117 eines Tages umarrangieren wollen.
119 @item @strong{Trennen Sie Einstellungen} von den eigentlichen
120 Noten. Siehe auch @ref{Saving typing with variables and functions}
127 @node Typesetting existing music
128 @subsection Typesetting existing music
130 Wenn Sie Musik aus einer fertigen Partitur kopieren (z. B. die
131 LilyPond-Eingabe einer gedruckten Partitur):
135 @item Schreiben Sie ein System ihrer Quelle nach dem anderen
136 (aber trotzdem nur einen Takt pro Textzeile) und überprüfen
137 Sie jedes System, nachdem Sie es fertig kopiert haben. Mit dem
138 @code{showLastLength}- oder @code{showFirstLenght}-Befehl können Sie den Übersetzungsprozess
139 beschleunigen. Siehe auch
140 @ruser{Skipping corrected music}.
142 @item Definieren Sie @code{mBreak = @{ \break @}} und schreiben Sie
143 @code{\mBreak} in der Quelldatei immer dann, wenn im Manuskript
144 ein Zeilenumbruch vorkommt. Das macht es einfacher, die gesetzte
145 Zeile mit den ursprünglichen Noten zu vergleichen. Wenn Sie die
146 Partitur fertig gestellt haben, könne Sie @code{mBreak = @{ @}},
147 also leer definieren, um diese manuellen Zeilenumbrüche zu entfernen.
148 Damit kann dann LilyPond selber entscheiden, wohin es passende
149 Zeilenumbrüche platziert.
151 @item Wenn Sie eine Stimme für ein transponierendes Instrument als eine
152 Variable notieren, wird empfohlen, dass die Noten von
155 \transpose c klingende-Tonhöhe @{...@}
158 eingefasst werden (wobei @code{klingende-Tonhöhe} die klingende Tonhöhe
159 des Instruments ist), sodass die Noten innerhalb der Variable für klingendes C
160 geschrieben sind. Sie können die Variable zurücktransponieren, wenn es
161 nötig ist, aber Sie müssen es nicht tun. Fehler in Transpositionen sind
162 treten seltener auf, wenn alle Noten in den Variablen für die gleiche
163 Ausgangstonhöhe geschrieben werden.
165 Denken Sie auch daran, dass Sie nur von/nach C transponieren. Das heißt,
166 dass die einzigen anderen Tonhöhen, die Sie in Transpositionen benutzen,
167 die Tonhöhen der Instrumente sind, für die Sie schreiben: @code{bes} für
168 eine B-Trompete oder @code{aes} für eine As-Klarinette usw.
174 @subsection Large projects
176 Besonders wenn Sie an größeren Projekten arbeiten, ist es
177 unumgänglich, dass Sie ihre LilyPond-Dateien klar strukturieren.
181 @item @strong{Verwenden Sie Variablen für jede Stimme}, innerhalb
182 der Definition sollte so wenig Struktur wie möglich sein. Die
183 Struktur des @code{\score}-Abschnittes verändert sich am ehesten,
184 während die @code{violine}-Definition sich wahrscheinlich mit einer
185 neuen Programmversion nicht verändern wird.
188 violine = \relative c'' @{
201 @item @strong{Trennen Sie Einstellungen von den Noten}. Diese
202 Empfehlung wurde schon im Abschnitt @ref{General suggestions} gegeben,
203 aber für große Projekte ist es unumgänglich. Muss z. B. die
204 Definition für @code{fdannp} verändert werden, so braucht
205 man es nur einmal vorzunehmen und die Noten in der Geigenstimme,
206 @code{violin}, bleiben unberührt.
210 \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
211 violin = \relative c'' @{
219 @node Saving typing with variables and functions
220 @subsection Saving typing with variables and functions
225 Bis jetzt haben Sie immer etwa solche Noten gesehen:
227 @lilypond[quote,verbatim,ragged-right]
228 hornNotes = \relative c'' { c4 b dis c }
236 Das könnte auch nützlich in Minimal-Music sein:
238 @lilypond[quote,verbatim,ragged-right]
239 fragmentA = \relative c'' { a4 a8. b16 }
240 fragmentB = \relative c'' { a8. gis16 ees4 }
241 violin = \new Staff { \fragmentA \fragmentA \fragmentB \fragmentA }
249 Sie können diese Bezeichner oder Variablen aber auch für
250 (eigene) Einstellungen verwenden:
252 @lilypond[quote,verbatim,ragged-right]
253 dolce = \markup{ \italic \bold dolce }
254 padText = { \once \override TextScript #'padding = #5.0 }
255 fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p }
256 violin = \relative c'' {
258 c4._\dolce b8 a8 g a b |
260 c4.^"hi there!" d8 e' f g d |
261 c,4.\fthenp b8 c4 c-. |
268 \layout{ragged-right=##t}
272 Die Variablen haben in diesem Beispiel deutlich die
273 Tipparbeit erleichtert. Aber es lohnt sich, sie zu
274 einzusetzen, auch wenn man sie nur einmal anwendet,
275 denn sie vereinfachen die Struktur.
276 Hier ist das vorangegangene Beispiel ohne
277 Variablen. Es ist sehr viel komplizierter zu lesen,
278 besonders die letzte Zeile.
281 violin = \relative c'' @{
283 c4._\markup@{ \italic \bold dolce @} b8 a8 g a b |
284 \once \override TextScript #'padding = #5.0
285 c4.^"hi there!" d8 e' f g d |
286 c,4.\markup@{ \dynamic f \italic \small @{ 2nd @}
287 \hspace #0.1 \dynamic p @} b8 c4 c-. |
292 @c TODO Replace the following with a better example -td
293 @c Skylining handles this correctly without padText
295 Bis jetzt wurde nur statische Substitution vorgestellt
296 -- wenn LilyPond den Befehl @code{\padText} findet, wird
297 er ersetzt durch durch unsere vorherige Definition (alles,
298 was nach dem @code{padtext =} kommt).
300 LilyPond kennt aber auch nicht-statische Substitutionen (man
301 kann sie sich als Funktionen vorstellen).
303 @lilypond[quote,verbatim,ragged-right]
305 #(define-music-function (parser location padding) (number?)
307 \once \override TextScript #'padding = #$padding
315 c4^"piu mosso" fis a g
319 Die Benutzung von Variablen hilft auch, viele Schreibarbeit zu
320 vermeiden, wenn die Eingabesyntax von LilyPond sich verändert
321 (siehe auch @ref{Updating old files}). Wenn nur eine einzige
322 Definition (etwa @code{\dolce}) für alle Dateien verwendet wird
323 (vgl. @ref{Style sheets}), muss nur diese einzige Definition
324 verändert werden, wenn sich die Syntax ändert. Alle Verwendungen
325 des Befehles beziehen sich dann auf die neue Definition.
328 @subsection Style sheets
330 Die Ausgabe, die LilyPond erstellt, kann sehr stark modifiziert
331 werden, siehe @ref{Tweaking output} für Einzelheiten. Aber wie
332 kann man diese Änderungen auf eine ganze Serie von Dateien
333 anwenden? Oder die Einstellungen von den Noten trennen? Das
334 Verfahren ist ziemlich einfach.
336 Hier ist ein Beispiel. Es ist nicht schlimm, wenn Sie nicht auf
337 Anhieb die Abschnitte mit den ganzen @code{#()} verstehen. Das
338 wird im Kapitel @ref{Advanced tweaks with Scheme} erklärt.
340 @lilypond[quote,verbatim,ragged-right]
341 mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
342 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
343 tempoMark = #(define-music-function (parser location markp) (string?)
345 \once \override Score . RehearsalMark #'self-alignment-X = #left
346 \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
347 \mark \markup { \bold $markp }
352 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
353 \tempoMark "Poco piu mosso"
354 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
358 Es treten einige Probleme mit überlappenden Symbolen auf. Sie
359 werden beseitigt mit den Tricks aus dem Kapitel @ref{Moving objects}.
360 Aber auch die @code{mpdolce} und @code{tempoMark}-Definitionen
361 können verbessert werden. Sie produzieren das Ergebnis, das
362 gewünscht ist, aber es wäre schön, sie auch in anderen Stücken
363 verwenden zu können. Man könnte sie natürlich einfach kopieren
364 und in die anderen Dateien einfügen, aber das ist lästig. Die
365 Definitionen verbleiben auch in der Notendatei und diese @code{#()}
366 sehen nicht wirklich schön aus. Sie sollen in einer anderen
367 Datei versteckt werden:
370 %%% speichern in einer Datei "definitions.ly"
371 mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
372 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
373 tempoMark = #(define-music-function (parser location markp) (string?)
375 \once \override Score . RehearsalMark #'self-alignment-X = #left
376 \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
377 \mark \markup @{ \bold $markp @}
381 Jetzt muss natürlich noch die Notendatei angepasst werden (gespeichert
382 unter dem Namen @file{"music.ly"}).
384 @c We have to do this awkward example/lilypond-non-verbatim
385 @c because we can't do the \include stuff in the manual.
388 \include "definitions.ly"
392 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
393 \once \override Score.RehearsalMark #'padding = #2.0
394 \tempoMark "Poco piu mosso"
395 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
399 @lilypond[quote,ragged-right]
400 mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
401 #:line(#:dynamic "mp" #:text #:italic "dolce" )))
402 tempoMark = #(define-music-function (parser location markp) (string?)
404 \once \override Score . RehearsalMark #'self-alignment-X = #left
405 \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
406 \mark \markup { \bold $markp }
411 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
412 \once \override Score.RehearsalMark #'padding = #2.0
413 \tempoMark "Poco piu mosso"
414 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
418 Das sieht schon besser aus, aber es sind noch einige Verbesserungen
420 Das Glissando ist schwer zu sehen, also soll es etwas dicker erscheinen
421 und dichter an den Notenköpfen gesetzt werden. Das Metronom-Zeichen
422 soll über dem Schlüssel erscheinen, nicht über der ersten Note. Und
423 schließlich kann unser Kompositionsprofessor @qq{C}-Taktangaben
424 überhaupt nicht leiden, also
425 müssen sie in @qq{4/4} verändert werden.
427 Diese Veränderungen sollten Sie aber nicht in der @file{music.ly}-Datei
428 vornehmen. Ersetzen Sie die @file{definitions.ly}-Datei hiermit:
432 mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
433 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
434 tempoMark = #(define-music-function (parser location markp) (string?)
436 \once \override Score . RehearsalMark #'self-alignment-X = #left
437 \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
438 \mark \markup @{ \bold $markp @}
443 \override MetronomeMark #'extra-offset = #'(-9 . 0)
444 \override MetronomeMark #'padding = #'3
447 \override TimeSignature #'style = #'numbered
450 \override Glissando #'thickness = #3
451 \override Glissando #'gap = #0.1
456 @lilypond[quote,ragged-right]
457 mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
458 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
459 tempoMark = #(define-music-function (parser location markp) (string?)
461 \once \override Score . RehearsalMark #'self-alignment-X = #left
462 \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
463 \mark \markup { \bold $markp }
468 \override MetronomeMark #'extra-offset = #'(-9 . 0)
469 \override MetronomeMark #'padding = #'3
472 \override TimeSignature #'style = #'numbered
475 \override Glissando #'thickness = #3
476 \override Glissando #'gap = #0.1
482 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
483 \once \override Score.RehearsalMark #'padding = #2.0
484 \tempoMark "Poco piu mosso"
485 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
489 Das sieht schon besser aus! Aber angenommen Sie möchten dieses
490 Stück jetzt veröffentlichen. Ihr Kompositionsprofessor mag
491 die @qq{C}-Taktangaben nicht, aber Sie finden sie irgendwie
492 schöner. Also kopieren Sie die Datei @file{definitions.ly} nach
493 @file{web-publish.ly} und verändern diese. Weil die Noten
494 in einer PDF-Datei auf dem Bildschirm angezeigt werden sollen,
495 bietet es sich auch an, die gesamte Ausgabe zu vergrößern.
499 mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
500 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
501 tempoMark = #(define-music-function (parser location markp) (string?)
503 \once \override Score . RehearsalMark #'self-alignment-X = #left
504 \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
505 \mark \markup @{ \bold $markp @}
508 #(set-global-staff-size 23)
511 \override MetronomeMark #'extra-offset = #'(-9 . 0)
512 \override MetronomeMark #'padding = #'3
517 \override Glissando #'thickness = #3
518 \override Glissando #'gap = #0.1
523 @lilypond[quote,ragged-right]
524 mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
525 #:line( #:dynamic "mp" #:text #:italic "dolce" )))
526 tempoMark = #(define-music-function (parser location markp) (string?)
528 \once \override Score . RehearsalMark #'self-alignment-X = #left
529 \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . -inf.0)
530 \mark \markup { \bold $markp }
533 #(set-global-staff-size 23)
536 \override MetronomeMark #'extra-offset = #'(-9 . 0)
537 \override MetronomeMark #'padding = #'3
540 \override Glissando #'thickness = #3
541 \override Glissando #'gap = #0.1
547 a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
548 \once \override Score.RehearsalMark #'padding = #2.0
549 \tempoMark "Poco piu mosso"
550 cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
554 In der Notendatei muss jetzt nur noch @code{\include "definitions.ly"}
555 durch @code{\include "web-publish.ly"} ausgetauscht werden.
556 Das könnte man natürlich noch weiter vereinfachen. Also
557 eine Datei @file{definitions.ly}, die nur die Definitionen
558 von @code{mpdolce} und @code{tempoMark} enthält, eine Datei
559 @file{web-publish.ly}, die alle die Änderungen für den
560 @code{\layout}-Abschnitt enthält und eine Datei @file{university.ly}
561 für eine Ausgabe, die den Wünschen des Professors entspricht.
562 Der Anfang der @file{music.ly}-Datei würde dann so aussehen:
565 \include "definitions.ly"
567 %%% Nur eine der beiden Zeilen auskommentieren!
568 \include "web-publish.ly"
569 %\include "university.ly"
572 Durch diese Herangehensweise kann auch bei der Erstellung
573 von nur einer Ausgabeversion Arbeit gespart werden. Ich
574 benutze ein halbes Dutzend verschiedener Stilvorlagen
575 für meine Projekte. Jede Notationsdatei fängt an mit
576 @code{\include "../global.ly"}, welches folgenden Inhalt hat:
582 #(ly:set-option 'point-and-click #f)
583 \include "../init/init-defs.ly"
584 \include "../init/init-layout.ly"
585 \include "../init/init-headers.ly"
586 \include "../init/init-paper.ly"
590 @node When things don't work
591 @section When things don't work
594 * Updating old files::
595 * Troubleshooting (taking it all apart)::
599 @node Updating old files
600 @subsection Updating old files
602 Die Syntax von LilyPond verändert sich ab und zu. Wenn LilyPond
603 besser wird, muss auch die Syntax (Eingabesprache) entsprechend
604 angepasst werden. Teilweise machen diese Veränderungen die
605 Eingabesprache einfacher lesbar, teilweise dienen sie dazu, neue
606 Eigenschaften des Programmes benutzbar zu machen.
608 LilyPond stellt ein Programm bereit, das Aktualisierungen
609 vereinfacht: @code{convert-ly}. Einzelheiten zur Programmbenutzung
610 finden sich in @rprogram{Updating files with convert-ly}.
612 Leider kann @code{convert-ly} nicht alle Veränderungen der Syntax
613 berücksichtigen. Hier werden einfache @qq{Suchen und
614 Ersetzen}-Veränderungen vorgenommen (wie etwa @code{raggedright} zu
615 @code{ragged-right}), aber einige Veränderungen sind zu
616 kompliziert. Die Syntax-Veränderungen, die das Programm nicht
617 berücksichtigt, sind im Kapitel @rprogram{Updating files with
618 convert-ly} aufgelistet.
620 Zum Beispiel wurden in LilyPond 2.4 und früheren Versionen
621 Akzente und Umlaute mit LaTeX-Befehlen eingegeben, ein
622 @qq{No\"el} etwa ergäbe das französische Wort für Weihnachten.
623 In LilyPond 2.6 und höher müssen diese Sonderzeichen direkt
624 als utf-8-Zeichen eingegeben werden, in diesem Fall also @qq{ë}.
625 @code{convert-ly} kann nicht alle dieser LaTeX-Befehle
626 verändern, das muss manuell vorgenommen werden.
629 @node Troubleshooting (taking it all apart)
630 @subsection Troubleshooting (taking it all apart)
632 Früher oder später werden Sie in die Lage kommen,
633 dass LilyPond Ihre Datei nicht kompilieren will. Die
634 Information, die LilyPond während der Übersetzung
635 gibt, können Ihnen helfen, den Fehler zu finden, aber
636 in vielen Fällen müssen Sie nach der Fehlerquelle
639 Die besten Hilfsmittel sind in diesem Fall das Zeilen-
640 und Blockkommentar (angezeigt durch @code{%} bzw.
641 @code{%@{ ... %@}}). Wenn Sie nicht bestimmen können,
642 wo sich das Problem befindet, beginnen Sie damit, große
643 Teile des Quelltextes auszukommentieren. Nachdem Sie
644 einen Teil auskommentiert haben, versuchen Sie, die Datei
645 erneut zu übersetzen. Wenn es jetzt funktioniert, muss
646 sich das Problem innerhalb der Kommentare befinden.
647 Wenn es nicht funktioniert, müssen Sie weitere Teile
648 auskommentieren bis sie eine Version haben, die funktioniert.
650 In Extremfällen bleibt nur noch solch ein Beispiel übrig:
664 (also eine Datei ohne Noten).
666 Geben Sie nicht auf, wenn das vorkommen sollte. Nehmen
667 Sie das Kommentarzeichen von einem Teil wieder weg, sagen
668 wir der Bassstimme, und schauen Sie, ob es funktioniert.
669 Wenn nicht, dann kommentieren Sie die gesamte Bassstimme
670 aus, aber nicht den @code{\bass}-Befehl in dem
671 @code{\score}-Abschnitt:
674 bass = \relative c' @{
682 Jetzt beginnen Sie damit, langsam Stück für Stück der
683 Bassstimme wieder hineinzunehmen, bis Sie die problematische
686 Eine andere nützliche Technik zur Problemlösung ist es,
687 @ref{Minimal examples} zu konstruieren.
690 @node Minimal examples
691 @subsection Minimal examples
693 Ein Minimalbeispiel ist eine Beispieldatei, die so klein wie
694 möglich ist. Diese Beispiele sind sehr viel einfacher zu
695 verstehen als die langen Originaldateien. Minimalbeispiele
700 @item Fehlerberichte zu erstellen,
701 @item eine Hilfeanfrage an die E-Mail-Liste zu schicken,
702 @item Ein Beispiel zur @uref{http://lsr@/.dsi@/.unimi@/.it/,LilyPond
703 Schnipselsammlung} hinzuzufügen.
706 Um ein Beispiel zu konstruieren, das so klein wie möglich ist,
707 gibt es eine einfache Regel: Alles nicht Notwendige entfernen.
708 Wenn Sie unnötige Teile einer Datei entfernen, bietet es sich an,
709 sie auszukommentieren und nicht gleich zu löschen. Auf diese Weise
710 können Sie eine Zeile leicht wieder mit aufnehmen, sollten Sie sie
711 doch brauchen, anstatt sie von Anfang an neu zu schreiben.
713 Es gibt zwei Ausnahmen dieser @qq{So klein wie möglich}-Regel:
716 @item Fügen Sie immer einen @code{\version}Befehl ein.
717 @item Wenn es möglich ist, benutzen Sie @code{\paper@{ ragged-right = ##t @}}
718 am Beginn des Beispiels.
721 Der Sinn der Minimalbeispiele ist, dass sie einfach lesbar sind:
724 @item Vermeiden Sie es, komplizierte Noten, Schlüssel oder Taktangaben
725 zu verwenden, es sei denn, Sie wollen genau an diesen Elementen
727 @item Benutzen Sie keine @code{\override}-Befehle, wenn sie nicht der
728 Zweck des Beispieles sind.
732 @node Scores and parts
733 @section Scores and parts
735 Orchesternoten werden alle zweimal gesetzt. Erstens als Stimmen für
736 die Musiker, und dann als große Partitur für den Dirigenten. Mit
738 kann hier doppelte Arbeit erspart werden. Die Musik muss nur einmal
739 eingegeben werden und wird in einer Variable abgelegt. Der Inhalt
741 Variable wird dann benutzt, um sowohl die Stimme als auch die Partitur
744 Es bietet sich an, die Noten in eigenen Dateien zu speichern. Sagen wir
745 beispielsweise, dass in der Datei @file{Horn-Noten.ly} die folgenden
746 Noten eines Duetts für Horn und Fagott gespeichert sind:
749 HornNoten = \relative c @{
756 Daraus wird dann eine eigene Stimme gemacht, indem folgende Datei
761 \include "Horn-Noten.ly"
763 instrument = "Horn in F"
767 \transpose f c' \HornNoten
774 \include "Horn-Noten.ly"
778 setzt den Inhalt der Datei @file{Horn-Noten.ly} an die Stelle des
779 Befehls in die aktuelle Datei. Damit besteht also eine Definition
780 für @code{HornNoten}, so dass die Variable verwendet werden kann.
781 Der Befehl @code{\transpose f@tie{}c'} zeigt an, dass das Argument,
782 also @code{\HornNoten}, um eine Quinte nach oben transponiert wird.
783 Klingendes @q{f} wird also als @code{c'} notiert. Das entspricht
784 der Notation eines Waldhorns in F. Die Transposition zeigt die folgende
787 @lilypond[quote,ragged-right]
788 \transpose f c' \relative c {
794 In der Musik für mehrere Instrumente kommt es oft vor, dass eine Stimme
795 für mehrere Takte nicht spielt. Das wird mit einer besonderen Pause
796 angezeigt, dem Pausenzeichen für mehrere Takte (engl. multi-measure
797 rest). Sie wird mit dem @emph{großen} Buchstaben @samp{R} eingegeben,
798 gefolgt von einer Dauer (@code{1}@tie{}für eine Ganze, @code{2}@tie{}
799 für eine Halbe usw.). Indem man die Dauer multipliziert, können längere
800 Pausen erstellt werden. Z. B. dauert diese Pause drei Takte eines
807 Wenn die Stimme gedruckt wird, müssen diese Pausen zusammengezogen
809 Das wird durch eine Variable erreicht:
812 \set Score.skipBars = ##t
816 Dieser Befehl setzt die Eigenschaft des @code{skipBars} (@qq{überspringe
817 Takte}) auf wahr (@code{##t}). Wenn diese Option und die Pause
818 zu der Musik des Beispiels gesetzt wird, erhält man folgendes Ergebnis:
820 @lilypond[quote,ragged-right]
821 \transpose f c' \relative c {
823 \set Score.skipBars = ##t
829 Die Partitur wird erstellt, indem alle Noten zusammengesetzt werden.
830 Angenommen, die andere Stimme trägt den Namen @code{FagottNoten}
831 und ist in der Datei @file{Fagott-Noten.ly} gespeichert. Die
832 Partitur sieht dann folgendermaßen aus:
835 \include "Fagott-Noten.ly"
836 \include "Horn-Noten.ly"
839 \new Staff \HornNoten
840 \new Staff \FagottNoten
845 Und mit LilyPond übersetzt:
847 @lilypond[quote,ragged-right]
855 r4 d,8 f | gis4 c | b bes |
856 a8 e f4 | g d | gis f