\input texinfo @c -*- coding: utf-8; mode: texinfo; documentlanguage: de -*-
@ignore
- Translation of GIT committish: ee314252b42fe4eb69c87c13a38644bc214ff27f
+ Translation of GIT committish: 67373601dabc72e32e3e7a4364c8be123d785e0b
When revising a translation, copy the HEAD committish of the
version that you are working on. See TRANSLATION for details.
@end ignore
@documentencoding UTF-8
@documentlanguage de
-@setfilename application.info
+@setfilename lilypond-application.info
@settitle GNU LilyPond Programmbenutzung
@include macros.itexi
@omflanguage German
@end ignore
-@c Translators: Till Rettig
+@c Translators: Till Paala
@ifnottex
@node Top
@ifnottex
Das ist das Handbuch zur Programmbenutzung für GNU LilyPond Version @version{}.
Für einen Überblick über die gesamte Dokumentation von LilyPond und die Intention
-dieses Handbuchs siehe @rlearning{Über die Dokumentation}.
+dieses Handbuchs siehe
+FIXME
+@c @rlearning{Über die Dokumentation}.
@cindex Internetseite
@cindex URL
@menu
* Installieren:: Wie das Programm installiert oder kompiliert wird.
* Setup:: Wie LilyPond mit anderen Programmen benutzt werden kann.
-* LilyPond starten:: Betrieb des Programms.
-* LilyPond-book:: Kombination von Text und Noten.
-* Von anderen Formaten konvertieren:: Konvertierungen in das LilyPond-Quellformat.
+* lilypond starten:: Betrieb des Programms.
+@c * Dateien mit convert-ly aktualisieren:: Eingabedateien konvertieren.
+* lilypond-book:: Kombination von Text und Noten.
+@c * Von anderen Formaten konvertieren:: Konvertierungen in das LilyPond-Quellformat.
+* An LilyPond-Projekten arbeiten:: Mit nicht funktionierenden Dateien umgehen.
+@c * Vorschläge, wie Dateien geschrieben werden sollten:: Goldene Regeln.
Anhänge
@include application/install.itely
@include application/setup.itely
@include application/running.itely
+@c @include application/updating.itely
@include application/lilypond-book.itely
@include application/converters.itely
+@include application/working.itely
+@c @include application/suggestions.itely
@include fdl.itexi
--- /dev/null
+@c -*- coding: utf-8; mode: texinfo; documentlanguage: de -*-
+
+@ignore
+ Translation of GIT committish: d96023d8792c8af202c7cb8508010c0d3648899d
+
+ When revising a translation, copy the HEAD committish of the
+ version that you are working on. See TRANSLATION for details.
+@end ignore
+
+@c \version "2.12.0"
+
+@node An LilyPond-Projekten arbeiten
+@chapter An LilyPond-Projekten arbeiten
+@translationof Working on LilyPond projects
+
+Dieses Kapitel erklärt, wie bestimmte häufige Probleme zu
+lösen oder ganz zu vermeiden sind. Wenn Sie schon
+Programmiererfahrung mitbringen, erscheinen diese Hinweise
+vielleicht überflüssig, aber es wird dennoch empfohlen, dieses Kapitel
+zu lesen.
+
+
+@menu
+* Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen::
+* Wenn etwas nicht funktioniert::
+* Partituren und Stimmen::
+* Make und Makefiles::
+@end menu
+
+
+@node Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen
+@section Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen
+@translationof Suggestions for writing LilyPond input files
+
+Jetzt sind Sie so weit, größere Stücke mit LilyPond zu schreiben --
+nicht nur die kleinen Beispiele aus der Übung, sondern ganze Stücke.
+Aber wie geht man das am besten an?
+
+Solange LilyPond Ihre Dateien versteht und die Noten so setzt,
+wie Sie das wollen, spielt es eigentlich keine Rolle, wie Ihre
+Dateien aussehen. Es gibt aber trotzdem ein paar Dinge, die man
+beim Schreiben von LilyPond-Code berücksichtigen sollte.
+
+@itemize @bullet
+@item Was ist, wenn Sie einen Fehler machen? Die Struktur einer
+LilyPond-Datei kann es erleichtern (oder erschweren), bestimmte
+Fehler zu finden.
+
+@item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen
+wollen? Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten
+wollen? Manche LilyPond-Dateien versteht man auf den ersten Blick,
+über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.
+
+@item Was ist, wenn sie Ihre Dateien auf eine neuere LilyPond-Version
+aktualisieren wollen? Die Syntax der Eingabesprache verändert sich
+allmählich mit Verbesserungen im Programm. Die meisten Veränderungen
+können automatisch durch @code{convert-ly} gelöst werden, aber
+bestimmte Änderungen brauchen Handarbeit. LilyPond-Dateien können
+strukturiert werden, damit sie einfacher aktualisierbar sind.
+@end itemize
+
+@menu
+* Allgemeine Vorschläge::
+* Das Kopieren von bereits vorhandener Musik::
+* Große Projekte::
+* Tipparbeit sparen durch Bezeichner und Funktionen::
+* Stil-Dateien::
+@end menu
+
+
+@node Allgemeine Vorschläge
+@subsection Allgemeine Vorschläge
+@translationof General suggestions
+
+Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:
+
+@itemize @bullet
+@item @strong{Schreiben Sie immer mit @code{\version} die
+Versionsnummer
+in jede Datei}. Beachten Sie, dass in allen Vorlagen die Versionsnummer
+@code{\version "2.12.0"} eingetragen ist. Es empfiehlt sich, in alle
+Dateien, unabhängig von ihrer Größe, den @code{\version}-Befehl
+einzufügen. Persönliche Erfahrung hat gezeigt, dass es ziemlich
+frustrierend sein kann zu erinnern, welche Programmversion man etwa
+vor einem Jahr verwendet hat. Auch @code{convert-ly} benötigt die
+Versionsnummer.
+
+@item @strong{Benutzen Sie Überprüfungen}: @ruser{Oktavenüberprüfung}, und
+@ruser{Takt- und Taktzahlüberprüfung}. Wenn Sie hier und da diese
+Überprüfungen einfügen, finden Sie einen möglichen Fehler weit
+schneller. Wie oft aber ist @qq{hier und da}? Das hängt von der
+Komplexität der Musik ab. ei einfachen Stücken reicht es vielleicht
+ein- oder zweimal, in sehr komplexer Musik sollte man sie vielleicht
+in jeden Takt einfügen.
+
+@item @strong{Ein Takt pro Textzeile}. Wenn irgendetwas kompliziertes
+vorkommt, entweder in der Musik selber oder in der Anpassung der
+Ausgabe,
+empfiehlt es sich oft, nur einen Takt pro Zeile zu schreiben.
+Bildschirmplatz zu sparen, indem Sie acht Takte in eine Zeile zwängen,
+hilft nicht weiter, wenn Sie ihre Datei @qq{debuggen} müssen.
+
+@item @strong{Kommentieren Sie ihre Dateien}. Benutzen Sie entweder
+Taktnummern (in regelmäßigen Abständen) oder Verweise auf musikalische
+Themen (@qq{Zweites Thema in den Geigen}, @qq{vierte Variation} usw.).
+Sie brauchen diese Kommentare vielleicht noch nicht, wenn Sie das Stück
+notieren, aber spätestens wenn Sie nach ein paar Jahren etwas
+verändern
+wollen oder Sie den Quelltext an einen Freund weitergeben wollen,
+ist es weitaus komplizierter, die Dateistruktur ohne Kommentare zu
+verstehen, als wenn Sie sie rechtzeitig eingefügt hätten.
+
+@item @strong{Schreiben Sie Klammern mit Einrückung}. Viele
+Probleme entstehen durch ungerade Anzahl von @code{@{} and
+@code{@}}-Klammern.
+
+@item @strong{Schreiben Sie Tondauerangaben} am Anfang von
+Abschnitten und Bezeichnern. Wenn Sie beispielsweise
+ @code{c4 d e} am Anfang eines Abschnittes schreiben,
+ersparen Sie sich viele Probleme, wenn Sie ihre Musik
+eines Tages umarrangieren wollen.
+
+@item @strong{Trennen Sie Einstellungen} von den eigentlichen
+Noten. Siehe auch @ref{Tipparbeit sparen durch Bezeichner und Funktionen}
+und
+@ref{Stil-Dateien}.
+
+@end itemize
+
+
+@node Das Kopieren von bereits vorhandener Musik
+@subsection Das Kopieren von bereits vorhandener Musik
+@translationof Typesetting existing music
+
+Wenn Sie Musik aus einer fertigen Partitur kopieren (z. B. die
+LilyPond-Eingabe einer gedruckten Partitur):
+
+@itemize @bullet
+
+@item Schreiben Sie ein System ihrer Quelle nach dem anderen
+(aber trotzdem nur einen Takt pro Textzeile) und überprüfen
+Sie jedes System, nachdem Sie es fertig kopiert haben. Mit dem
+@code{showLastLength}- oder @code{showFirstLenght}-Befehl können Sie den Übersetzungsprozess
+beschleunigen. Siehe auch
+@ruser{Korrigierte Musik überspringen}.
+
+@item Definieren Sie @code{mBreak = @{ \break @}} und schreiben Sie
+ @code{\mBreak} in der Quelldatei immer dann, wenn im Manuskript
+ein Zeilenumbruch vorkommt. Das macht es einfacher, die gesetzte
+Zeile mit den ursprünglichen Noten zu vergleichen. Wenn Sie die
+Partitur fertig gestellt haben, könne Sie @code{mBreak = @{ @}},
+also leer definieren, um diese manuellen Zeilenumbrüche zu entfernen.
+Damit kann dann LilyPond selber entscheiden, wohin es passende
+Zeilenumbrüche platziert.
+
+@item Wenn Sie eine Stimme für ein transponierendes Instrument als eine
+Variable notieren, wird empfohlen, dass die Noten von
+
+@example
+\transpose c klingende-Tonhöhe @{...@}
+@end example
+
+eingefasst werden (wobei @code{klingende-Tonhöhe} die klingende Tonhöhe
+des Instruments ist), sodass die Noten innerhalb der Variable für klingendes C
+geschrieben sind. Sie können die Variable zurücktransponieren, wenn es
+nötig ist, aber Sie müssen es nicht tun. Fehler in Transpositionen sind
+treten seltener auf, wenn alle Noten in den Variablen für die gleiche
+Ausgangstonhöhe geschrieben werden.
+
+Denken Sie auch daran, dass Sie nur von/nach C transponieren. Das heißt,
+dass die einzigen anderen Tonhöhen, die Sie in Transpositionen benutzen,
+die Tonhöhen der Instrumente sind, für die Sie schreiben: @code{bes} für
+eine B-Trompete oder @code{aes} für eine As-Klarinette usw.
+
+@end itemize
+
+
+@node Große Projekte
+@subsection Große Projekte
+@translationof Large projects
+
+Besonders wenn Sie an größeren Projekten arbeiten, ist es
+unumgänglich, dass Sie ihre LilyPond-Dateien klar strukturieren.
+
+@itemize @bullet
+
+@item @strong{Verwenden Sie Variablen für jede Stimme}, innerhalb
+der Definition sollte so wenig Struktur wie möglich sein. Die
+Struktur des @code{\score}-Abschnittes verändert sich am ehesten,
+während die @code{violine}-Definition sich wahrscheinlich mit einer
+neuen Programmversion nicht verändern wird.
+
+@example
+violine = \relative c'' @{
+g4 c'8. e16
+@}
+...
+\score @{
+ \new GrandStaff @{
+ \new Staff @{
+ \violine
+ @}
+ @}
+@}
+@end example
+
+@item @strong{Trennen Sie Einstellungen von den Noten}. Diese
+Empfehlung wurde schon im Abschnitt @ref{Allgemeine Vorschläge} gegeben,
+aber für große Projekte ist es unumgänglich. Muss z. B. die
+Definition für @code{fdannp} verändert werden, so braucht
+man es nur einmal vorzunehmen und die Noten in der Geigenstimme,
+@code{violin}, bleiben unberührt.
+
+@example
+fdannp = _\markup@{
+ \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
+violin = \relative c'' @{
+g4\fdannp c'8. e16
+@}
+@end example
+
+@end itemize
+
+
+@node Tipparbeit sparen durch Bezeichner und Funktionen
+@subsection Tipparbeit sparen durch Bezeichner und Funktionen
+@translationof Saving typing with variables and functions
+
+@cindex Variable
+@cindex Bezeichner
+
+Bis jetzt haben Sie immer etwa solche Noten gesehen:
+
+@lilypond[quote,verbatim,ragged-right]
+hornNotes = \relative c'' { c4 b dis c }
+\score {
+ {
+ \hornNotes
+ }
+}
+@end lilypond
+
+Das könnte auch nützlich in Minimal-Music sein:
+
+@lilypond[quote,verbatim,ragged-right]
+fragmentA = \relative c'' { a4 a8. b16 }
+fragmentB = \relative c'' { a8. gis16 ees4 }
+violin = \new Staff { \fragmentA \fragmentA \fragmentB \fragmentA }
+\score {
+ {
+ \violin
+ }
+}
+@end lilypond
+
+Sie können diese Bezeichner oder Variablen aber auch für
+(eigene) Einstellungen verwenden:
+
+@lilypond[quote,verbatim,ragged-right]
+dolce = \markup{ \italic \bold dolce }
+padText = { \once \override TextScript #'padding = #5.0 }
+fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p }
+violin = \relative c'' {
+ \repeat volta 2 {
+ c4._\dolce b8 a8 g a b |
+ \padText
+ c4.^"hi there!" d8 e' f g d |
+ c,4.\fthenp b8 c4 c-. |
+ }
+}
+\score {
+ {
+ \violin
+ }
+\layout{ragged-right=##t}
+}
+@end lilypond
+
+Die Variablen haben in diesem Beispiel deutlich die
+Tipparbeit erleichtert. Aber es lohnt sich, sie zu
+einzusetzen, auch wenn man sie nur einmal anwendet,
+denn sie vereinfachen die Struktur.
+Hier ist das vorangegangene Beispiel ohne
+Variablen. Es ist sehr viel komplizierter zu lesen,
+besonders die letzte Zeile.
+
+@example
+violin = \relative c'' @{
+ \repeat volta 2 @{
+ c4._\markup@{ \italic \bold dolce @} b8 a8 g a b |
+ \once \override TextScript #'padding = #5.0
+ c4.^"hi there!" d8 e' f g d |
+ c,4.\markup@{ \dynamic f \italic \small @{ 2nd @}
+ \hspace #0.1 \dynamic p @} b8 c4 c-. |
+ @}
+@}
+@end example
+
+@c TODO Replace the following with a better example -td
+@c Skylining handles this correctly without padText
+
+Bis jetzt wurde nur statische Substitution vorgestellt
+-- wenn LilyPond den Befehl @code{\padText} findet, wird
+er ersetzt durch durch unsere vorherige Definition (alles,
+was nach dem @code{padtext =} kommt).
+
+LilyPond kennt aber auch nicht-statische Substitutionen (man
+kann sie sich als Funktionen vorstellen).
+
+@lilypond[quote,verbatim,ragged-right]
+padText =
+#(define-music-function (parser location padding) (number?)
+ #{
+ \once \override TextScript #'padding = #$padding
+ #})
+
+\relative c''' {
+ c4^"piu mosso" b a b
+ \padText #1.8
+ c4^"piu mosso" d e f
+ \padText #2.6
+ c4^"piu mosso" fis a g
+}
+@end lilypond
+
+Die Benutzung von Variablen hilft auch, viele Schreibarbeit zu
+vermeiden, wenn die Eingabesyntax von LilyPond sich verändert
+(siehe auch @ref{Alte Dateien aktualisieren}). Wenn nur eine einzige
+Definition (etwa @code{\dolce}) für alle Dateien verwendet wird
+(vgl. @ref{Stil-Dateien}), muss nur diese einzige Definition
+verändert werden, wenn sich die Syntax ändert. Alle Verwendungen
+des Befehles beziehen sich dann auf die neue Definition.
+
+@node Stil-Dateien
+@subsection Stil-Dateien
+@translationof Style sheets
+
+Die Ausgabe, die LilyPond erstellt, kann sehr stark modifiziert
+werden, siehe @ref{Die Ausgabe verändern} für Einzelheiten. Aber wie
+kann man diese Änderungen auf eine ganze Serie von Dateien
+anwenden? Oder die Einstellungen von den Noten trennen? Das
+Verfahren ist ziemlich einfach.
+
+Hier ist ein Beispiel. Es ist nicht schlimm, wenn Sie nicht auf
+Anhieb die Abschnitte mit den ganzen @code{#()} verstehen. Das
+wird im Kapitel @ref{Fortgeschrittene Optimierungen mit Scheme} erklärt.
+
+@lilypond[quote,verbatim,ragged-right]
+mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
+ #:line(#:dynamic "mp" #:text #:italic "dolce" )))
+
+inst = #(define-music-function (parser location string) (string?)
+ (make-music
+ 'TextScriptEvent
+ 'direction UP
+ 'text (markup #:bold (#:box string))))
+
+\relative c'' {
+ \tempo 4=50
+ a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
+ \inst "Clarinet"
+ cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
+}
+@end lilypond
+
+Es treten einige Probleme mit überlappenden Symbolen auf. Sie
+werden beseitigt mit den Tricks aus dem Kapitel @ref{Verschieben von Objekten}.
+Aber auch die @code{mpdolce} und @code{inst}-Definitionen
+können verbessert werden. Sie produzieren das Ergebnis, das
+gewünscht ist, aber es wäre schön, sie auch in anderen Stücken
+verwenden zu können. Man könnte sie natürlich einfach kopieren
+und in die anderen Dateien einfügen, aber das ist lästig. Die
+Definitionen verbleiben auch in der Notendatei und diese @code{#()}
+sehen nicht wirklich schön aus. Sie sollen in einer anderen
+Datei versteckt werden:
+
+@example
+%%% speichern in einer Datei "definitions.ily"
+mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
+ #:line(#:dynamic "mp" #:text #:italic "dolce" )))
+
+inst = #(define-music-function (parser location string) (string?)
+ (make-music
+ 'TextScriptEvent
+ 'direction UP
+ 'text (markup #:bold (#:box string))))
+@end example
+
+Auf diese Datei kann dann später mit dem @code{\include}-Befehl
+im oberen Teil der LilyPond-Datei zurückgegriffen werden. (Die
+Erweiterung @code{.ily} wird benutzt, um diese eingefügte Datei,
+die nicht alleine kompiliert werden kann, von der Hauptdatei zu
+unterscheiden.)
+Jetzt muss natürlich noch die Notendatei angepasst werden (gespeichert
+unter dem Namen @file{"music.ly"}).
+
+@c We have to do this awkward example/lilypond-non-verbatim
+@c because we can't do the \include stuff in the manual.
+
+@example
+\include "definitions.ily"
+
+\relative c'' @{
+ \tempo 4=50
+ a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
+ \inst "Clarinet"
+ cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
+@}
+@end example
+
+@lilypond[quote,ragged-right]
+mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
+ #:line(#:dynamic "mp" #:text #:italic "dolce" )))
+
+inst = #(define-music-function (parser location string) (string?)
+ (make-music
+ 'TextScriptEvent
+ 'direction UP
+ 'text (markup #:bold (#:box string))))
+
+\relative c'' {
+ \tempo 4=50
+ a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
+ \inst "Clarinet"
+ cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
+}
+@end lilypond
+
+Das sieht schon besser aus, aber es sind noch einige Verbesserungen
+möglich.
+Das Glissando ist schwer zu sehen, also soll es etwas dicker erscheinen
+und dichter an den Notenköpfen gesetzt werden. Das Metronom-Zeichen
+soll über dem Schlüssel erscheinen, nicht über der ersten Note. Und
+schließlich kann unser Kompositionsprofessor @qq{C}-Taktangaben
+überhaupt nicht leiden, also
+müssen sie in @qq{4/4} verändert werden.
+
+Diese Veränderungen sollten Sie aber nicht in der @file{music.ly}-Datei
+vornehmen. Ersetzen Sie die @file{definitions.ily}-Datei hiermit:
+
+@example
+%%% definitions.ily
+mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
+ #:line( #:dynamic "mp" #:text #:italic "dolce" )))
+
+inst = #(define-music-function (parser location string) (string?)
+ (make-music
+ 'TextScriptEvent
+ 'direction UP
+ 'text (markup #:bold (#:box string))))
+
+\layout@{
+ \context @{ \Score
+ \override MetronomeMark #'extra-offset = #'(-9 . 0)
+ \override MetronomeMark #'padding = #'3
+ @}
+ \context @{ \Staff
+ \override TimeSignature #'style = #'numbered
+ @}
+ \context @{ \Voice
+ \override Glissando #'thickness = #3
+ \override Glissando #'gap = #0.1
+ @}
+@}
+@end example
+
+@lilypond[quote,ragged-right]
+mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
+ #:line( #:dynamic "mp" #:text #:italic "dolce" )))
+
+inst = #(define-music-function (parser location string) (string?)
+ (make-music
+ 'TextScriptEvent
+ 'direction UP
+ 'text (markup #:bold (#:box string))))
+
+\layout{
+ \context { \Score
+ \override MetronomeMark #'extra-offset = #'(-9 . 0)
+ \override MetronomeMark #'padding = #'3
+ }
+ \context { \Staff
+ \override TimeSignature #'style = #'numbered
+ }
+ \context { \Voice
+ \override Glissando #'thickness = #3
+ \override Glissando #'gap = #0.1
+ }
+}
+
+\relative c'' {
+ \tempo 4=50
+ a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
+ \inst "Clarinet"
+ cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
+}
+@end lilypond
+
+Das sieht schon besser aus! Aber angenommen Sie möchten dieses
+Stück jetzt veröffentlichen. Ihr Kompositionsprofessor mag
+die @qq{C}-Taktangaben nicht, aber Sie finden sie irgendwie
+schöner. Also kopieren Sie die Datei @file{definitions.ily} nach
+@file{web-publish.ily} und verändern diese. Weil die Noten
+in einer PDF-Datei auf dem Bildschirm angezeigt werden sollen,
+bietet es sich auch an, die gesamte Ausgabe zu vergrößern.
+
+@example
+%%% definitions.ily
+mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
+ #:line( #:dynamic "mp" #:text #:italic "dolce" )))
+
+inst = #(define-music-function (parser location string) (string?)
+ (make-music
+ 'TextScriptEvent
+ 'direction UP
+ 'text (markup #:bold (#:box string))))
+
+#(set-global-staff-size 23)
+\layout@{
+ \context @{ \Score
+ \override MetronomeMark #'extra-offset = #'(-9 . 0)
+ \override MetronomeMark #'padding = #'3
+ @}
+ \context @{ \Staff
+ @}
+ \context @{ \Voice
+ \override Glissando #'thickness = #3
+ \override Glissando #'gap = #0.1
+ @}
+@}
+@end example
+
+@lilypond[quote,ragged-right]
+mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
+ #:line( #:dynamic "mp" #:text #:italic "dolce" )))
+
+inst = #(define-music-function (parser location string) (string?)
+ (make-music
+ 'TextScriptEvent
+ 'direction UP
+ 'text (markup #:bold (#:box string))))
+
+#(set-global-staff-size 23)
+\layout{
+ \context { \Score
+ \override MetronomeMark #'extra-offset = #'(-9 . 0)
+ \override MetronomeMark #'padding = #'3
+ }
+ \context { \Voice
+ \override Glissando #'thickness = #3
+ \override Glissando #'gap = #0.1
+ }
+}
+
+\relative c'' {
+ \tempo 4=50
+ a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
+ \inst "Clarinet"
+ cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
+}
+@end lilypond
+
+In der Notendatei muss jetzt nur noch @code{\include "definitions.ily"}
+durch @code{\include "web-publish.ily"} ausgetauscht werden.
+Das könnte man natürlich noch weiter vereinfachen. Also
+eine Datei @file{definitions.ily}, die nur die Definitionen
+von @code{mpdolce} und @code{inst} enthält, eine Datei
+@file{web-publish.ily}, die alle die Änderungen für den
+@code{\layout}-Abschnitt enthält und eine Datei @file{university.ily}
+für eine Ausgabe, die den Wünschen des Professors entspricht.
+Der Anfang der @file{music.ly}-Datei würde dann so aussehen:
+
+@example
+\include "definitions.ily"
+
+%%% Nur eine der beiden Zeilen auskommentieren!
+\include "web-publish.ily"
+%\include "university.ily"
+@end example
+
+Durch diese Herangehensweise kann auch bei der Erstellung
+von nur einer Ausgabeversion Arbeit gespart werden. Ich
+benutze ein halbes Dutzend verschiedener Stilvorlagen
+für meine Projekte. Jede Notationsdatei fängt an mit
+@code{\include "../global.ily"}, welches folgenden Inhalt hat:
+
+
+@example
+%%% global.ly
+\version "2.12.0"
+#(ly:set-option 'point-and-click #f)
+\include "../init/init-defs.ily"
+\include "../init/init-layout.ily"
+\include "../init/init-headers.ily"
+\include "../init/init-paper.ily"
+@end example
+
+
+@node Wenn etwas nicht funktioniert
+@section Wenn etwas nicht funktioniert
+@translationof When things don't work
+
+@menu
+* Alte Dateien aktualisieren::
+* Fehlersuche (alles auseinandernehmen)::
+* Minimalbeispiele::
+@end menu
+
+@node Alte Dateien aktualisieren
+@subsection Alte Dateien aktualisieren
+@translationof Updating old files
+
+Die Syntax von LilyPond verändert sich ab und zu. Wenn LilyPond
+besser wird, muss auch die Syntax (Eingabesprache) entsprechend
+angepasst werden. Teilweise machen diese Veränderungen die
+Eingabesprache einfacher lesbar, teilweise dienen sie dazu, neue
+Eigenschaften des Programmes benutzbar zu machen.
+
+LilyPond stellt ein Programm bereit, das Aktualisierungen
+vereinfacht: @code{convert-ly}. Einzelheiten zur Programmbenutzung
+finden sich in @rprogram{Dateien mit convert-ly aktualisieren}.
+
+Leider kann @code{convert-ly} nicht alle Veränderungen der Syntax
+berücksichtigen. Hier werden einfache @qq{Suchen und
+Ersetzen}-Veränderungen vorgenommen (wie etwa @code{raggedright} zu
+@code{ragged-right}), aber einige Veränderungen sind zu
+kompliziert. Die Syntax-Veränderungen, die das Programm nicht
+berücksichtigt, sind im Kapitel @rprogram{Dateien mit convert-ly aktualisieren} aufgelistet.
+
+Zum Beispiel wurden in LilyPond 2.4 und früheren Versionen
+Akzente und Umlaute mit LaTeX-Befehlen eingegeben, ein
+@qq{No\"el} etwa ergäbe das französische Wort für Weihnachten.
+In LilyPond 2.6 und höher müssen diese Sonderzeichen direkt
+als utf-8-Zeichen eingegeben werden, in diesem Fall also @qq{ë}.
+@code{convert-ly} kann nicht alle dieser LaTeX-Befehle
+verändern, das muss manuell vorgenommen werden.
+
+
+@node Fehlersuche (alles auseinandernehmen)
+@subsection Fehlersuche (alles auseinandernehmen)
+@translationof Troubleshooting (taking it all apart)
+
+Früher oder später werden Sie in die Lage kommen,
+dass LilyPond Ihre Datei nicht kompilieren will. Die
+Information, die LilyPond während der Übersetzung
+gibt, können Ihnen helfen, den Fehler zu finden, aber
+in vielen Fällen müssen Sie nach der Fehlerquelle
+auf die Suche gehen.
+
+Die besten Hilfsmittel sind in diesem Fall das Zeilen-
+und Blockkommentar (angezeigt durch @code{%} bzw.
+@code{%@{ ... %@}}). Wenn Sie nicht bestimmen können,
+wo sich das Problem befindet, beginnen Sie damit, große
+Teile des Quelltextes auszukommentieren. Nachdem Sie
+einen Teil auskommentiert haben, versuchen Sie, die Datei
+erneut zu übersetzen. Wenn es jetzt funktioniert, muss
+sich das Problem innerhalb der Kommentare befinden.
+Wenn es nicht funktioniert, müssen Sie weitere Teile
+auskommentieren bis sie eine Version haben, die funktioniert.
+
+In Extremfällen bleibt nur noch solch ein Beispiel übrig:
+
+@example
+\score @{
+ <<
+ % \melody
+ % \harmony
+ % \bass
+ >>
+ \layout@{@}
+@}
+@end example
+
+@noindent
+(also eine Datei ohne Noten).
+
+Geben Sie nicht auf, wenn das vorkommen sollte. Nehmen
+Sie das Kommentarzeichen von einem Teil wieder weg, sagen
+wir der Bassstimme, und schauen Sie, ob es funktioniert.
+Wenn nicht, dann kommentieren Sie die gesamte Bassstimme
+aus, aber nicht den @code{\bass}-Befehl in dem
+ @code{\score}-Abschnitt:
+
+@example
+bass = \relative c' @{
+%@{
+ c4 c c c
+ d d d d
+%@}
+@}
+@end example
+
+Jetzt beginnen Sie damit, langsam Stück für Stück der
+Bassstimme wieder hineinzunehmen, bis Sie die problematische
+Zeile finden.
+
+Eine andere nützliche Technik zur Problemlösung ist es,
+@ref{Minimalbeispiele} zu konstruieren.
+
+
+@node Minimalbeispiele
+@subsection Minimalbeispiele
+@translationof Minimal examples
+
+Ein Minimalbeispiel ist eine Beispieldatei, die so klein wie
+möglich ist. Diese Beispiele sind sehr viel einfacher zu
+verstehen als die langen Originaldateien. Minimalbeispiele
+werden benutzt, um
+
+
+@itemize
+@item Fehlerberichte zu erstellen,
+@item eine Hilfeanfrage an die E-Mail-Liste zu schicken,
+@item Ein Beispiel zur @uref{http://lsr@/.dsi@/.unimi@/.it/,LilyPond
+Schnipselsammlung} hinzuzufügen.
+@end itemize
+
+Um ein Beispiel zu konstruieren, das so klein wie möglich ist,
+gibt es eine einfache Regel: Alles nicht Notwendige entfernen.
+Wenn Sie unnötige Teile einer Datei entfernen, bietet es sich an,
+sie auszukommentieren und nicht gleich zu löschen. Auf diese Weise
+können Sie eine Zeile leicht wieder mit aufnehmen, sollten Sie sie
+doch brauchen, anstatt sie von Anfang an neu zu schreiben.
+
+Es gibt zwei Ausnahmen dieser @qq{So klein wie möglich}-Regel:
+
+@itemize
+@item Fügen Sie immer einen @code{\version}Befehl ein.
+@item Wenn es möglich ist, benutzen Sie @code{\paper@{ ragged-right = ##t @}}
+am Beginn des Beispiels.
+@end itemize
+
+Der Sinn der Minimalbeispiele ist, dass sie einfach lesbar sind:
+
+@itemize
+@item Vermeiden Sie es, komplizierte Noten, Schlüssel oder Taktangaben
+zu verwenden, es sei denn, Sie wollen genau an diesen Elementen
+etwas demonstrieren.
+@item Benutzen Sie keine @code{\override}-Befehle, wenn sie nicht der
+Zweck des Beispieles sind.
+@end itemize
+
+
+@node Partituren und Stimmen
+@section Partituren und Stimmen
+@translationof Scores and parts
+
+Orchesternoten werden alle zweimal gesetzt. Erstens als Stimmen für
+die Musiker, und dann als große Partitur für den Dirigenten. Mit
+Variablen
+kann hier doppelte Arbeit erspart werden. Die Musik muss nur einmal
+eingegeben werden und wird in einer Variable abgelegt. Der Inhalt
+dieser
+Variable wird dann benutzt, um sowohl die Stimme als auch die Partitur
+zu erstellen.
+
+Es bietet sich an, die Noten in eigenen Dateien zu speichern. Sagen wir
+beispielsweise, dass in der Datei @file{Horn-Noten.ly} die folgenden
+Noten eines Duetts für Horn und Fagott gespeichert sind:
+
+@example
+HornNoten = \relative c @{
+ \time 2/4
+ r4 f8 a cis4 f e d
+@}
+@end example
+
+@noindent
+Daraus wird dann eine eigene Stimme gemacht, indem folgende Datei
+erstellt
+wird:
+
+@example
+\include "Horn-Noten.ly"
+\header @{
+ instrument = "Horn in F"
+@}
+
+@{
+ \transpose f c' \HornNoten
+@}
+@end example
+
+Die Zeile
+
+@example
+\include "Horn-Noten.ly"
+@end example
+
+@noindent
+setzt den Inhalt der Datei @file{Horn-Noten.ly} an die Stelle des
+Befehls in die aktuelle Datei. Damit besteht also eine Definition
+für @code{HornNoten}, so dass die Variable verwendet werden kann.
+Der Befehl @code{\transpose f@tie{}c'} zeigt an, dass das Argument,
+also @code{\HornNoten}, um eine Quinte nach oben transponiert wird.
+Klingendes @q{f} wird also als @code{c'} notiert. Das entspricht
+der Notation eines Waldhorns in F. Die Transposition zeigt die folgende
+Ausgabe:
+
+@lilypond[quote,ragged-right]
+\transpose f c' \relative c {
+ \time 2/4
+ r4 f8 a cis4 f e d
+}
+@end lilypond
+
+In der Musik für mehrere Instrumente kommt es oft vor, dass eine Stimme
+für mehrere Takte nicht spielt. Das wird mit einer besonderen Pause
+angezeigt, dem Pausenzeichen für mehrere Takte (engl. multi-measure
+rest). Sie wird mit dem @emph{großen} Buchstaben @samp{R} eingegeben,
+gefolgt von einer Dauer (@code{1}@tie{}für eine Ganze, @code{2}@tie{}
+für eine Halbe usw.). Indem man die Dauer multipliziert, können längere
+Pausen erstellt werden. Z. B. dauert diese Pause drei Takte eines
+2/4-Taktes:
+
+@example
+R2*3
+@end example
+
+Wenn die Stimme gedruckt wird, müssen diese Pausen zusammengezogen
+werden.
+Das wird durch eine Variable erreicht:
+
+@example
+\set Score.skipBars = ##t
+@end example
+
+@noindent
+Dieser Befehl setzt die Eigenschaft des @code{skipBars} (@qq{überspringe
+Takte}) auf wahr (@code{##t}). Wenn diese Option und die Pause
+zu der Musik des Beispiels gesetzt wird, erhält man folgendes Ergebnis:
+
+@lilypond[quote,ragged-right]
+\transpose f c' \relative c {
+ \time 2/4
+ \set Score.skipBars = ##t
+ R2*3
+ r4 f8 a cis4 f e d
+}
+@end lilypond
+
+Die Partitur wird erstellt, indem alle Noten zusammengesetzt werden.
+Angenommen, die andere Stimme trägt den Namen @code{FagottNoten}
+ und ist in der Datei @file{Fagott-Noten.ly} gespeichert. Die
+Partitur sieht dann folgendermaßen aus:
+
+@example
+\include "Fagott-Noten.ly"
+\include "Horn-Noten.ly"
+
+<<
+ \new Staff \HornNoten
+ \new Staff \FagottNoten
+>>
+@end example
+
+@noindent
+Und mit LilyPond übersetzt:
+
+@lilypond[quote,ragged-right]
+\relative c <<
+ \new Staff {
+ \time 2/4 R2*3
+ r4 f8 a cis4 f e d
+ }
+ \new Staff {
+ \clef bass
+ r4 d,8 f | gis4 c | b bes |
+ a8 e f4 | g d | gis f
+ }
+>>
+@end lilypond
+
+
+@node Make und Makefiles
+@section Make und Makefiles
+@translationof Make and Makefiles
+
+@cindex Makefile
+@cindex Make-Dateien
+@cindex make
+
+Fast alle Betriebssysteme, auf denen LilyPond benutzt werden kann,
+unterstützen ein Programm mit dem Namen @code{make}. Dieses Programm
+liest eine besondere Datei mit der Bezeichnung @code{Makefile},
+die definiert, welche Dateien von welchen anderen Dateien abhängen und
+welche Befehle für das Betriebssystem nötig sind, um eine Datei aus
+einer anderen zu erstellen. Ein Makefile könnte etwa erklären, wie
+@code{ballad.pdf} und @code{ballad.midi} aus @code{ballad.ly}
+erstellt werden können, indem LilyPond aufgerufen wird.
+
+Es gibt Fällen, wenn es sich sehr stark empfiehlt, ein @code{Makefile}
+für das aktuelle Projekt zu erstellen, entweder zur eigenen Bequemlichkeit,
+oder aber auch als Hilfe für andere, die vielleicht einmal die
+Quelldateien lesen und verstehen wollen. Insbesondere bei großen Projekten
+mit vielen eingefügten Dateien und unterschiedlichen Ausgabeoptionen
+(etwa Partitur, einzelne Stimmen, Dirigierpartitur, Klavierauszug usw.),
+aber auch bei Projekten, die komplizierte Programmaufrufe zur Verarbeitung
+erfordern (wenn man etwa mit @code{lilypond-book} arbeitet), lohnt
+sich die Erstellung einer Make-Datei. Diese Dateien können sehr
+unterschiedliche ausfallen, und ihre Komplexität und Flexibilität kann
+den Bedürfnissen aber auch Kenntnissen des Schreibers angepasst werden.
+Das Programm GNU Make ist auf GNU/Linux Distributionen und MacOS X
+installiert, aber es ist auch für Windows erhältlich.
+
+Das @strong{GNU Make Manual} gibt eine vollständige Anleitung, wie
+@code{make} benutzt werden kann. Hier sollen nur einige kleine
+Blicke auf die vielfältigen Möglichkeiten geworfen werden.
+
+Die Befehle, um Regeln in einer Make-Datei zu erstellen, unterscheidet
+sich zwischen den Betriebssystemen. Die verschiedenen Linuxe und
+MacOS X benutzen @code{bash}, während unter Windows @code{cmd} eingesetzt
+wird. Unter MacOS X muss man das System so konfigurieren, dass
+die Kommandozeile benutzt wird. Hier einige Beispiele für Make-Dateien,
+mit Versionen für Linux/MacOS und Windows.
+
+Das erste Beispiel ist für ein Orchesterstück in vier Stätzen unt mit
+der folgenden Dateistruktur:
+
+@example
+Symphony/
+|-- MIDI/
+|-- Makefile
+|-- Notes/
+| |-- cello.ily
+| |-- figures.ily
+| |-- horn.ily
+| |-- oboe.ily
+| |-- trioString.ily
+| |-- viola.ily
+| |-- violinOne.ily
+| `-- violinTwo.ily
+|-- PDF/
+|-- Parts/
+| |-- symphony-cello.ly
+| |-- symphony-horn.ly
+| |-- symphony-oboes.ly
+| |-- symphony-viola.ly
+| |-- symphony-violinOne.ly
+| `-- symphony-violinTwo.ly
+|-- Scores/
+| |-- symphony.ly
+| |-- symphonyI.ly
+| |-- symphonyII.ly
+| |-- symphonyIII.ly
+| `-- symphonyIV.ly
+`-- symphonyDefs.ily
+@end example
+
+Die @code{.ly}-Dateien un den Verzeichnissen @code{Scores} und
+@code{Parts} erhalten ihrere Noten aus @code{.ily}-Dateien, die
+sich im @code{Notes}-Verzeichnis befinden:
+
+@example
+%%% Kopfzeile der Datei "symphony-cello.ly"
+\include ../definitions.ily
+\include ../Notes/cello.ily
+@end example
+
+Die Make-Datei hat die Ziele @code{score} (das gesamte Stück als
+große Partitur), @code{movements} (die einzelnen Sätze als große
+Partitur) und @code{parts} (die einzelnen Stimmen für die Spieler).
+Es gibt auch das Ziel @code{archive}, welches ein Tar-Archiv
+der Quelldateien erstellt, etwa um die Quellen über das Internet
+oder per E-Mail zu verteilen. Hier die Make-Datei für GNU/Linux
+oder MacOS X. Sie sollte unter dem Namen @code{Makefile} im obersten
+Verzeichnis des Projektes gespeichert werden:
+
+@warning{Wenn ein Ziel oder eine Musterregel definiert ist, müssen
+die folgenden Zeilen mit Tabulatoren, nicht mit Leerzeichen beginnen.}
+
+@example
+# Namensstamm der Ausgabedateien
+piece = symphony
+# finde heraus, wieviele Prozessoren vorhanden sind
+CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
+# Der Befehl, um lilypond aufzurufen
+LILY_CMD = lilypond -ddelete-intermediate-files \
+ -dno-point-and-click -djob-count=$(CPU_CORES)
+
+# Die Endungen, die im Makefile benutzt werden
+.SUFFIXES: .ly .ily .pdf .midi
+
+# Eingabe- und Ausgabedateien werden in den Verzeichnissen durchsucht,
+# die sich in der VPATH-Variable befinden. Alle sind Unterverzeichnisse
+# des aktuellen Verzeichnisses (angegeben durch die GNU make-Variable
+# `CURDIR').
+VPATH = \
+ $(CURDIR)/Scores \
+ $(CURDIR)/PDF \
+ $(CURDIR)/Parts \
+ $(CURDIR)/Notes
+
+# Die Musterregel, um PDF und MIDI-Dateien aus der LY-Eingabedatei
+# zu erstellen. Die .pdf-Ausgabedateien werden in das
+# `PDF'-Unterverzeichnis abgelegt, die .midi-Dateien in das
+# `MIDI'-Unterverzeichnis.
+%.pdf %.midi: %.ly
+ $(LILY_CMD) $<; \ # this line begins with a tab
+ if test -f "$*.pdf"; then \
+ mv "$*.pdf" PDF/; \
+ fi; \
+ if test -f "$*.midi"; then \
+ mv "$*.midi" MIDI/; \
+ fi
+
+notes = \
+ cello.ily \
+ horn.ily \
+ oboe.ily \
+ viola.ily \
+ violinOne.ily \
+ violinTwo.ily
+
+# Abhängigkeiten der einzelnen Sätze.
+$(piece)I.pdf: $(piece)I.ly $(notes)
+$(piece)II.pdf: $(piece)II.ly $(notes)
+$(piece)III.pdf: $(piece)III.ly $(notes)
+$(piece)IV.pdf: $(piece)IV.ly $(notes)
+
+# Abhängigkeiten der großen Partitur.
+$(piece).pdf: $(piece).ly $(notes)
+
+# Abhängigkeiten der Stimmen.
+$(piece)-cello.pdf: $(piece)-cello.ly cello.ily
+$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
+$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
+$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
+$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
+$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
+
+# `make score' eintippen, um die große Partitur mit allen vier
+# Sätzen als eine Datei zu erstellen.
+.PHONY: score
+score: $(piece).pdf
+
+# `make parts' tippen, um alle Stimmen zu erstellen.
+# `make foo.pdf' tippen, um die Stimme für das Instrument `foo' zu erstellen.
+# Beispiel: `make symphony-cello.pdf'.
+.PHONY: parts
+parts: $(piece)-cello.pdf \
+ $(piece)-violinOne.pdf \
+ $(piece)-violinTwo.pdf \
+ $(piece)-viola.pdf \
+ $(piece)-oboes.pdf \
+ $(piece)-horn.pdf
+
+# `make movements' tippen um Dateien für die vier Sätze einzeln zu erstellen.
+.PHONY: movements
+movements: $(piece)I.pdf \
+ $(piece)II.pdf \
+ $(piece)III.pdf \
+ $(piece)IV.pdf
+
+all: score parts movements
+
+archive:
+ tar -cvvf stamitz.tar \ # this line begins with a tab
+ --exclude=*pdf --exclude=*~ \
+ --exclude=*midi --exclude=*.tar \
+ ../Stamitz/*
+@end example
+
+Unter Windows ergeben sich bestimmte Komplikationen. Nachdem man
+GNU Make für Windows heruntergeladen und installiert hat, muss
+man den richtigen Pfad in den Umgebungsvariablen des Systems setzen,
+damit die DOS-Kommandozeile das Make-Programm finden kann. Um das
+vorzunehmen, kann mit der rechten Maustaste auf "Arbeitsplatz"
+klicken, dann @code{Eigenschaften} und @code{Erweitert} geklickt
+werden. Hier wählt man @code{Umgebungsvariablen}. In der
+Liste @code{Systemvariablen} wählt man @code{Path} und mit
+einem Klick auf @code{Bearbeiten} kann man den Pfad zu der
+@code{.exe}-Datei von GNU Make hinzufügen, der etwa wie
+folgt aussieht:
+
+@example
+C:\Program Files\GnuWin32\bin
+@end example
+
+Die Make-Datei selber muss auch angepasst werden, um unterschiedliche
+Shell-Befehle zu verwenden und mit Leerzeichen umgehen zu können,
+die sich in einigen Standardverzeichnissen unter Windows befinden.
+Das @code{archive}-Ziel wird entfernt, da Windows den
+@code{tar}-Befehl nicht kennt, und Windows benutzt auch eine
+andere Dateiendung für midi-Dateien.
+
+
+@example
+## WINDOWS VERSION
+##
+piece = symphony
+LILY_CMD = lilypond -ddelete-intermediate-files \
+ -dno-point-and-click \
+ -djob-count=$(NUMBER_OF_PROCESSORS)
+
+# 8.3 Bezeichnung für CURDIR erhalten (Workaround wg. Leerzeichen in PATH)
+workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
+ do @@echo %%~sb)
+
+.SUFFIXES: .ly .ily .pdf .mid
+
+VPATH = \
+ $(workdir)/Scores \
+ $(workdir)/PDF \
+ $(workdir)/Parts \
+ $(workdir)/Notes
+
+%.pdf %.mid: %.ly
+ $(LILY_CMD) $< # diese Zeile beginnt mit Tabulator
+ if exist "$*.pdf" move /Y "$*.pdf" PDF/ # begin with tab
+ if exist "$*.mid" move /Y "$*.mid" MIDI/ # begin with tab
+
+notes = \
+ cello.ily \
+ figures.ily \
+ horn.ily \
+ oboe.ily \
+ trioString.ily \
+ viola.ily \
+ violinOne.ily \
+ violinTwo.ily
+
+$(piece)I.pdf: $(piece)I.ly $(notes)
+$(piece)II.pdf: $(piece)II.ly $(notes)
+$(piece)III.pdf: $(piece)III.ly $(notes)
+$(piece)IV.pdf: $(piece)IV.ly $(notes)
+
+$(piece).pdf: $(piece).ly $(notes)
+
+$(piece)-cello.pdf: $(piece)-cello.ly cello.ily
+$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
+$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
+$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
+$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
+$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
+
+.PHONY: score
+score: $(piece).pdf
+
+.PHONY: parts
+parts: $(piece)-cello.pdf \
+ $(piece)-violinOne.pdf \
+ $(piece)-violinTwo.pdf \
+ $(piece)-viola.pdf \
+ $(piece)-oboes.pdf \
+ $(piece)-horn.pdf
+
+.PHONY: movements
+movements: $(piece)I.pdf \
+ $(piece)II.pdf \
+ $(piece)III.pdf \
+ $(piece)IV.pdf
+
+all: score parts movements
+@end example
+
+Die nächste Make-Datei ist für ein @command{lilypond-book}-Dokument,
+das in LaTeX gesetzt wird. Das Projekt hat einen Index, welcher
+erfordert, dass der Befehl @command{latex} zweimal aufgerufen wird,
+um die Verweise zu aktualisieren. Ausgabedateien werden in einem
+@code{out}-Verzeichnis für die .pdf-Dateien gespeichert und in
+@code{htmlout} für die html-Dateien.
+
+@example
+SHELL=/bin/sh
+FILE=myproject
+OUTDIR=out
+WEBDIR=htmlout
+VIEWER=acroread
+BROWSER=firefox
+LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
+LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
+PDF=cd $(OUTDIR) && pdflatex $(FILE)
+HTML=cd $(WEBDIR) && latex2html $(FILE)
+INDEX=cd $(OUTDIR) && makeindex $(FILE)
+PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &
+
+all: pdf web keep
+
+pdf:
+ $(LILYBOOK_PDF) # begin with tab
+ $(PDF) # begin with tab
+ $(INDEX) # begin with tab
+ $(PDF) # begin with tab
+ $(PREVIEW) # begin with tab
+
+web:
+ $(LILYBOOK_HTML) # begin with tab
+ $(HTML) # begin with tab
+ cp -R $(WEBDIR)/$(FILE)/ ./ # begin with tab
+ $(BROWSER) $(FILE)/$(FILE).html & # begin with tab
+
+keep: pdf
+ cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf # begin with tab
+
+clean:
+ rm -rf $(OUTDIR) # begin with tab
+
+web-clean:
+ rm -rf $(WEBDIR) # begin with tab
+
+archive:
+ tar -cvvf myproject.tar \ # begin this line with tab
+ --exclude=out/* \
+ --exclude=htmlout/* \
+ --exclude=myproject/* \
+ --exclude=*midi \
+ --exclude=*pdf \
+ --exclude=*~ \
+ ../MyProject/*
+@end example
+
+TODO: soll auch unter Windows funktionieren
+
+Die vorige Make-Datei funktioniert nicht unter Windows. Als Alternative
+für Windows-Benutzer könnte man eine einfache batch-Datei erstellen,
+welche die erforderlichen Befehl enthält. Sie kümmert sich nicht
+um Abhängigkeiten, wie es eine Make-Datei kann, aber wenigstens
+wird die Kompilation auf einen einzigen Befehl beschränkt. Das folgende
+kann als Datei @command{build.bat} oder @command{build.cmd} gespeichert
+werden. Die Batch-Datei kann auf der Kommandozeile aufgerufen werden
+oder einfach doppelt angeklickt werden.
+
+@example
+lilypond-book --output=out --pdf myproject.lytex
+cd out
+pdflatex myproject
+makeindex myproject
+pdflatex myproject
+cd ..
+copy out\myproject.pdf MyProject.pdf
+@end example
+
+
+@seealso
+Programmbenutzung:
+@rprogram{Einrichtung für MacOS X},
+@rprogram{Benutzung auf der Kommandozeile},
+@rprogram{LilyPond-book}
@c -*- coding: utf-8; mode: texinfo; documentlanguage: de -*-
@ignore
- Translation of GIT committish: 499a511d4166feaada31114e097f86b5e0c56421
+ Translation of GIT committish: 67373601dabc72e32e3e7a4364c8be123d785e0b
When revising a translation, copy the HEAD committish of the
version that you are working on. See TRANSLATION for details.
@node Literatur
-@appendix Literatur
+@chapter Literatur
@translationof Literature list
Wenn Sie mehr über Notation und den Notenstich erfahren wollen, sind
<html>
<!--
- Translation of GIT committish: 7b70644b95f383b4281e9ffa146d315d2ada11d3
+ Translation of GIT committish: 67373601dabc72e32e3e7a4364c8be123d785e0b
When revising a translation, copy the HEAD committish of the
version that you are working on. See TRANSLATION for details.
@include learning/tutorial.itely
@include learning/fundamental.itely
@include learning/tweaks.itely
-@include learning/working.itely
+@c @include learning/working.itely
+@c moved to application.tely
@include learning/templates.itely
@include learning/scheme-tutorial.itely
@c -*- coding: utf-8; mode: texinfo; documentlanguage: de -*-
@ignore
- Translation of GIT committish: 01361d46dc9d514a79683d003eeea5f4fbf2b746
+ Translation of GIT committish: 67373601dabc72e32e3e7a4364c8be123d785e0b
When revising a translation, copy the HEAD committish of the
version that you are working on. See TRANSLATION for details.
@cindex Variablen
@cindex Bezeichner
-Eine gute Möglichkeit zur Vereinfachung sind selbst definierte Variablen.
+Eine gute Möglichkeit zur Vereinfachung sind selbst definierte Variablen (siehe auch @ref{Organizing pieces with variables}.)
Alle Vorlagen verwenden diese Möglichkeit.
@example
aus kleinen Teilen zusammensetzen. Noten können zu Akkorden
verbunden werden usw. Jetzt gehen wir aber in die andere Richtung
und betrachten, wie sich ein großer musikalischer Ausdruck
-zerlegen lässt.
-
-@example
-\score @{
- @{ % diese Klammer startet den großen mus. Ausdruck
- \new StaffGroup <<
- @var{...hier eine ganze Wagner-Oper einfügen...}
- >>
- @} % diese Klammer beendet den Ausdruck
- \layout @{ @}
-@}
-@end example
-
-Eine Wagner-Oper ist mindestens doppelt so lang wie dieses Handbuch,
-beschränken wir uns also auf einen Sänger und Klavier. Wir brauchen
-keine ganze Orchesterpartitur, infolgedessen können wir die Systemgruppe
-(StaffGroup) auslassen, aber wir brauchen einen Sänger und ein Klavier.
+zerlegen lässt. Zur Einfachheit soll nur ein Sänger und Klavier
+in unserem Beispiel eingesetzt werden. Wir brauchen
+keine Systemgruppe (StaffGroup), die einfach nur bewirkt,
+dass die Systeme mit einer Klammer zusammengefasst werden; sie
+wird also entfernt. Wir @emph{brauchen} aber einen Sänger und ein Klavier.
@example
\score @{
@}
@end example
+Hier wurden die Systeme (Staff) benannt: @qq{Sänger} und
+@qq{Klavier}. Das ist nicht direkt notwendig in diesem Fall,
+aber es ist gut, sich diese Schreibweise anzugewöhnen, damit man
+immer sofort erkennt, um welches System es sich handelt.
+
Zur Erinnerung: mit @code{<<} und @code{>>} werden Noten gleichzeitig
-gesetzt; wir wollen ja auch Klavier- und Sängerstimme gleichzeitig
-und nicht hintereinander haben. Bei genauerem Hinsehen fällt auf, dass
-die @code{<< ... >>}-Konstruktion für die Notenzeile des Sängers eigentlich
-nicht unbedingt nötig wäre, da sie ja nur einen (sequenzielle) musikalischen
-Ausdruck enthält, nämlich alle Noten des Sängers hintereinander. Daher
-könnte an sich auch einfach ein @code{@{...@}} benutzt werden. Die
-Spitzklammern sind allerdings notwendig, sobald die Notenzeile mehrere
-parallelle Ausdrücke -- wie etwa zwei parallele Stimmen oder eine Stimme
-mit zugehörigem Text -- enthält.
-Wir werden die Musik später in das Beispiel einfügen, im Moment begnügen
-wir uns mit einigen Platzhalter-Noten und -Texten.
+gesetzt. Dadurch werden Vokalstimme und Klaviersysteme übereinander
+ausgegeben. Die @code{<< ... >>}-Konstruktion ist für das
+Sänger-System nicht notwendig, wenn hier nur die Noten einer
+einzigen Stimme eingefügt werden sollen, aber @code{<< ... >>}
+anstelle von geschwungenen Klammern sind notwendig,
+sobald mehr als eine Stimme oder etwa eine Notenstimme und
+Gesangstext eingefügt werden sollen. In unserem Fall soll eine
+Stimme mit Gesangstext notiert werden, sodass die spitzen Klammern
+benötigt werden. Die Noten sollen erst später hinzugefügt werden,
+hier also erstmal nur ein paar Platzhalternoten und Text. Wenn
+Sie sich nicht erinnern, wie man Gesangstext notiert, lesen
+Sie noch einmal @code{\addlyrics} in @ref{Setting simple songs}.
@lilypond[verbatim,quote,ragged-right]
\score {
durchgehende Taktstriche und die geschweifte Klammer am Anfang), in der
dann wiederum zwei eigene Systeme ("oben" für die rechte Hand und
"unten"
-für die linke) erstellt werden.
+für die linke) erstellt werden, auch wenn das untere System noch
+einen Bassschlüssel erhalten muss.
Jetzt könnte man in diese Umgebung Noten einfügen. Innerhalb der
geschweiften Klammern neben @code{\new Voice = "Singstimme"}
schreiben. Aber wenn man seine Datei so direkt schreibt, wird
der @code{\score}-Abschnitt sehr lang und es wird ziemlich schwer zu
verstehen, wie alles zusammenhängt. Darum bietet es sich an, Bezeichner
-(oder Variablen) zu verwenden.
+(oder Variablen) zu verwenden. Sie wurden zu Beginn des vorigen
+Abschnitts erklärt, erinnern Sie sich? Damit wir sicher gehen
+können, dass der Inhalt der @code{text}-Variable als Gesangstext
+interpretiert wird, wird ihm @code{\lyricmode} vorangesetzt. Wie
+@code{\addlyrics} wird hiermit in den Eingabemodus für Gesangstext
+gewechselt. Ohne diesen Befehl würde LilyPond versuchen, den Inhalt
+der Variable als Noten zu interpretieren und dabei eine Menge
+Fehler produzieren. (Einige andere Eingabemodi sind außerdem noch
+verfügtbar, siehe @ruser{Input modes}.)
+
+Also haben wir, wenn wir ein paar Noten und einen Bassschlüssel
+für die linke Hand hinzufügen, folgendes Beispiel:
@lilypond[verbatim,quote,ragged-right]
melodie = \relative c'' { r4 d8\noBeam g, c4 r }
}
@end lilypond
-Achten Sie auf den Unterschied zwischen Noten, die mit @code{\relative}
-oder direkt in einem musikalischen Ausruck eingegeben werden, und
-dem Text des Lieds, der innerhalb @code{\lyricmode} angegeben
-werden muss. Diese Unterscheidung ist für LilyPond essentiell,
-um zu entscheiden, ob der folgende Inhalt als Musik oder Text
-interpretiert werden soll. Wie könnte LilyPond sonst entscheiden,
-ob @code{@{a b c@}} die drei Noten a, b und c darstellen soll oder
-den Text eines Lieds über das Alphabet!
-
Beim Schreiben (oder Lesen) einer @code{\score}-Umgebung
sollte man langsam und sorgfältig vorgehen. Am besten fängt
man mit dem größten Gebilde an und definiert dann die darin
für die Stimmen 1 und 2 stimmen, aber die Hälse in der dritten Stimme
sollen in diesem Beispiel eigentlich nach unten zeigen. Wir können das
korrigieren, indem wir die dritte Stimme einfach auslassen und die
-Noten in die vierte Stimme verschieben:
+Noten in die vierte Stimme verschieben. Das wird einfach vorgenommen,
+indem noch ein Paar @code{\\}-Stimmen hinzugefügt wird.
@c KEEP LY
@lilypond[quote,verbatim,fragment,ragged-right]
Notenausgabe Taktlinien, Vorzeichen, ein Schlüssel und
eine Taktart hinzugefügt wurden. Während LilyPond
den Eingabetext @emph{interpretiert}, wird die
-musikalische Information in zeitlicher Reihenfolge
-inspiziert, etwa wie man eine Partitur von links nach
+musikalische Information von rechts nach links gelesen,
+in etwa, wie man eine Partitur von links nach
rechts liest. Während das Programm den Code liest,
merkt es sich, wo sich Taktgrenzen befinden und
für welche Tonhöhen Versetzungszeichen gesetzt werden
Innerhalb von LilyPond sind diese Regeln und
Informationshappen in @emph{Kontexten} (engl.
-contexts) gruppiert. Wir sind schon auf den
-@code{Voice} (Stimmen)-Kontext gestoßen. Daneben
+contexts) gruppiert. Der @code{Voice} (Stimmen)-Kontext
+wurde schon vorgestellt. Daneben
gibt es noch die @code{Staff} (Notensystem-) und
@code{Score} (Partitur)-Kontexte. Kontexte sind
hierarchisch geschichtet um die hierarchische
notiert) immer mit zwei Rauten beginnen. Eine Eigenschaft, die
aus Text besteht, muss in doppelte Anführungsstriche gesetzt werden,
auch wenn wir später sehen werden, dass Text auf eine sehr viel
-allgmeinere und mächtigere Art mit dem @code{markup}-Befehl
+allgmeinere und mächtigere Art mit dem @code{\markup}-Befehl
eingegeben werden kann.
@subsubheading Kontexteigenschaften mit @code{\with} setzen
* Sopran und Cello::
* Vierstimmige SATB-Partitur::
* Eine Partitur von Grund auf erstellen::
+* Tipparbeit durch Variablen und Funktionen ersparen::
+* Partitur und Stimmen::
@end menu
@end lilypond
+@node Tipparbeit durch Variablen und Funktionen ersparen
+@subsection Tipparbeit durch Variablen und Funktionen ersparen
+@translationof Saving typing with variables and functions
+
+@cindex Variablen
+
+Bis jetzt wurde immer derartige Notation vorgestellt:
+
+@lilypond[quote,verbatim,ragged-right]
+hornNotes = \relative c'' { c4 b dis c }
+\score {
+ {
+ \hornNotes
+ }
+}
+@end lilypond
+
+Sie können sich vorstellen, dass das etwa für minimalistische
+Musik sehr nützlich sein könnte:
+
+@lilypond[quote,verbatim,ragged-right]
+fragmentA = \relative c'' { a4 a8. b16 }
+fragmentB = \relative c'' { a8. gis16 ees4 }
+violin = \new Staff { \fragmentA \fragmentA \fragmentB fragmentA }
+\score {
+ {
+ \violin
+ }
+}
+@end lilypond
+
+Diese Variablen (die man auch als Makros oder Benutzer-Befehl
+bezeichnet) können jedoch auch für eigene Anpassungen eingesetzt
+werden:
+
+@c TODO Avoid padtext - not needed with skylining
+@lilypond[quote,verbatim,ragged-right]
+dolce = \markup{ \italic \bold dolce }
+padText = { \once \override TextScript #'padding = #5.0 }
+fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 dynamic p }
+violin = \relative c'' {
+ \repeat volta 2 {
+ c4._\dolce b8 a8 g a b |
+ \padText
+ c4.^"hi there!" d8 e' f g d |
+ c,4.\fthenp b8 c4 c-. |
+ }
+}
+\score {
+ {
+ \violin
+ }
+\layout{ragged-right=##t}
+}
+@end lilypond
+
+Derartige Variablen sind offensichtlich sehr nützlich, zu Tipparbeit zu ersparen. Aber es lohnt sich schon, sie zu
+benutzen, wenn man sie nur einmal benutzen will, denn sie
+vereinfachen die Struktur einer Datei sehr stark. Hier das
+vorige Beispiel ohne jede Benutzung von Variablen. Es ist
+sehr viel schwerer lesbar, besonders die letzte Zeile.
+
+@example
+violin = \relative c'' @{
+ \repeat volta 2 @{
+ c4._\markup@{ \italic \bold dolce @} b8 a8 g a b |
+ \once \override TextScript #'padding = #5.0
+ c4.^"hi there!" d8 e' f g d |
+ c,4.\markup@{ \dynamic f \italic \small @{ 2nd @}
+ \hspace #0.1 \dynamic p @} b8 c4 c-. |
+ @}
+@}
+@end example
+
+@c TODO Replace the following with a better example -td
+@c Skylining handles this correctly without padText
+
+Bisher haben wir vor allem statische Ersetzungen betrachtet:
+wenn LilyPond etwa @code{\padText} sieht, wird es ersetzt mit
+all dem Code, mit dem wir es definiert haben (also alles,
+was sich rechts von @code{padtext=} befindet).
+
+LilyPond kann auch nicht-statische Ersetzungen bewältigen. Man
+kann sie sich als Funktionen vorstellen.
+
+@lilypond[quote,verbatim,ragged-right]
+padText =
+#(define-music-function (parser location padding) (number?)
+ #{
+ \once \override TextScript #'padding = #$padding
+ #})
+
+\relative c''' {
+ c4^"piu mosso" b a b
+ \padText #1.8
+ c4^"piu mosso" d e f
+ \padText #2.6
+ c4^"piu mosso" fis a g
+}
+@end lilypond
+
+Die Benutzung von Variablen ist auch eine gute Möglichkeit,
+Arbeit zu vermeiden, wenn sich einmal die Syntax von LilyPond
+ändern sollte (siehe auch @rprogram{Updating old input iles}).
+Wenn man eine einzige Definition hat (wie etwa @code{\dolce}),
+die für alle Vorkommen in der Notation eingesetzt wird, muss
+man auch nur einmal diese Definition aktualisieren, anstatt
+dass man sie in jeder @code{.ly}-Datei einzeln ändern müsste.
+
+
+@node Partitur und Stimmen
+@subsection Partitur und Stimmen
+@translationof Scores and parts
+
+In Orchestermusik werden alle Noten zweimal gedruckt. Einmal
+in einer Stimme für die Spieler, und einmal ein der Partitur
+für den Dirigenten. Variablen können benutzen, um sich doppelte
+Arbeit zu ersparen. Die Noten werden nur einmal eingegeben und
+in einer Variable abgelegt. Der Inhalt der Variable wird dann
+benutzt um sowohl die Stimme als auch die Paritur zu erstellen.
+
+Es bietet sich an, die Noten in einer extra Datei abzulegen.
+Nehmen wir an, dass die Datei @file{horn-music.ly} folgende
+Noten eines Horn/@/Fagott-Duos enthält:
+
+@example
+hornNotes = \relative c @{
+ \time 2/4
+ r4 f8 a cis4 f e d
+@}
+@end example
+
+@noindent
+Eine Stimme wird also erstellt, indem man folgendes in eine
+Datei schreibt:
+
+@example
+\include "horn-music.ly"
+\header @{
+ instrument = "Horn in F"
+@}
+
+@{
+ \transpose f c' \hornNotes
+@}
+@end example
+
+Die Zeile
+
+@example
+\include "horn-music.ly"
+@end example
+
+@noindent
+ersetzt den Inhalt von @file{horn-music.ly} an dieser Position
+in der Datei, sodass @code{hornNotes} im Folgenden definiert
+ist. Der Befehl @code{\transpose f@tie{}c'} zeigt an, dass
+das Argument (@code{\hornNotes}) eine Quinte nach oben transponiert
+werden soll. Klingendes @code{f} wird als @code{c'}, wie es
+die Stimmung eines normalen F-Hornes verlangt. Die Transposition
+kann in folgender Notenausgabe gesehen werden:
+
+@lilypond[quote,ragged-right]
+\transpose f c' \relative c {
+ \time 2/4
+ r4 f8 a cis4 f e d
+}
+@end lilypond
+
+In Ensemblestücken sind manche Stimmen für viele Takte stumm.
+Das wird durch eine besondere Pause notiert, die Mehrtaktpause.
+Sie wird mit einem großen @code{R} notiert, gefolgt von der
+Dauer (@code{1}@tie{}für eine Ganze, @code{2}@tie{}für eine Halbe usw.). Indem man die Dauern multipliziert, kann man auch
+längere Dauern erzeugen. Diese Pause etwa dauert drei Takte
+in einem 2/4-Takt:
+
+@example
+R2*3
+@end example
+Wenn die Stimme gesetzt wird, werden Mehrtaktpausen komprimiert. Das schieht, indem man folgendes in die Datei
+schreibt:
+
+@example
+\set Score.skipBars = ##t
+@end example
+
+@noindent
+Dieser Befehl setzt die Eigenschaft @code{skipBars} im
+@code{Score}-Kontext auf wahr (@code{##t}). Die Pause und diese Option zu der Musik von oben hinzugefügt, ergibt folgendes
+Beispiel:
+
+@lilypond[quote,ragged-right]
+\transpose f c' \relative c {
+ \time 2/4
+ \set Score.skipBars = ##t
+ R2*3
+ r4 f8 a cis4 f e d
+}
+@end lilypond
+
+Die Partitur wird erstellt, indem man alle Noten kombiniert.
+Angenommen, die andere Stimme ist in @code{bassoonNotes}
+in der Datei @file{bassoon-music.ly} definiert, würde eine
+Paritur erstellt mit:
+
+@example
+\include "bassoon-music.ly"
+\include "horn-music.ly"
+
+<<
+ \new Staff \hornNotes
+ \new Staff \bassoonNotes
+>>
+@end example
+
+@noindent
+leading to
+
+@lilypond[quote,ragged-right]
+\relative c <<
+ \new Staff {
+ \time 2/4 R2*3
+ r4 f8 a cis4 f e d
+ }
+ \new Staff {
+ \clef bass
+ r4 d,8 f | gis4 c | b bes |
+ a8 e f4 | g d | gis f
+ }
+>>
+@end lilypond
+++ /dev/null
-@c -*- coding: utf-8; mode: texinfo; documentlanguage: de -*-
-
-@ignore
- Translation of GIT committish: d96023d8792c8af202c7cb8508010c0d3648899d
-
- When revising a translation, copy the HEAD committish of the
- version that you are working on. See TRANSLATION for details.
-@end ignore
-
-@c \version "2.12.0"
-
-@node An LilyPond-Projekten arbeiten
-@chapter An LilyPond-Projekten arbeiten
-@translationof Working on LilyPond projects
-
-Dieses Kapitel erklärt, wie bestimmte häufige Probleme zu
-lösen oder ganz zu vermeiden sind. Wenn Sie schon
-Programmiererfahrung mitbringen, erscheinen diese Hinweise
-vielleicht überflüssig, aber es wird dennoch empfohlen, dieses Kapitel
-zu lesen.
-
-
-@menu
-* Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen::
-* Wenn etwas nicht funktioniert::
-* Partituren und Stimmen::
-* Make und Makefiles::
-@end menu
-
-
-@node Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen
-@section Vorschläge, wie LilyPond-Eingabe-Dateien geschrieben werden sollen
-@translationof Suggestions for writing LilyPond input files
-
-Jetzt sind Sie so weit, größere Stücke mit LilyPond zu schreiben --
-nicht nur die kleinen Beispiele aus der Übung, sondern ganze Stücke.
-Aber wie geht man das am besten an?
-
-Solange LilyPond Ihre Dateien versteht und die Noten so setzt,
-wie Sie das wollen, spielt es eigentlich keine Rolle, wie Ihre
-Dateien aussehen. Es gibt aber trotzdem ein paar Dinge, die man
-beim Schreiben von LilyPond-Code berücksichtigen sollte.
-
-@itemize @bullet
-@item Was ist, wenn Sie einen Fehler machen? Die Struktur einer
-LilyPond-Datei kann es erleichtern (oder erschweren), bestimmte
-Fehler zu finden.
-
-@item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen
-wollen? Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten
-wollen? Manche LilyPond-Dateien versteht man auf den ersten Blick,
-über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.
-
-@item Was ist, wenn sie Ihre Dateien auf eine neuere LilyPond-Version
-aktualisieren wollen? Die Syntax der Eingabesprache verändert sich
-allmählich mit Verbesserungen im Programm. Die meisten Veränderungen
-können automatisch durch @code{convert-ly} gelöst werden, aber
-bestimmte Änderungen brauchen Handarbeit. LilyPond-Dateien können
-strukturiert werden, damit sie einfacher aktualisierbar sind.
-@end itemize
-
-@menu
-* Allgemeine Vorschläge::
-* Das Kopieren von bereits vorhandener Musik::
-* Große Projekte::
-* Tipparbeit sparen durch Bezeichner und Funktionen::
-* Stil-Dateien::
-@end menu
-
-
-@node Allgemeine Vorschläge
-@subsection Allgemeine Vorschläge
-@translationof General suggestions
-
-Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:
-
-@itemize @bullet
-@item @strong{Schreiben Sie immer mit @code{\version} die
-Versionsnummer
-in jede Datei}. Beachten Sie, dass in allen Vorlagen die Versionsnummer
-@code{\version "2.12.0"} eingetragen ist. Es empfiehlt sich, in alle
-Dateien, unabhängig von ihrer Größe, den @code{\version}-Befehl
-einzufügen. Persönliche Erfahrung hat gezeigt, dass es ziemlich
-frustrierend sein kann zu erinnern, welche Programmversion man etwa
-vor einem Jahr verwendet hat. Auch @code{convert-ly} benötigt die
-Versionsnummer.
-
-@item @strong{Benutzen Sie Überprüfungen}: @ruser{Oktavenüberprüfung}, und
-@ruser{Takt- und Taktzahlüberprüfung}. Wenn Sie hier und da diese
-Überprüfungen einfügen, finden Sie einen möglichen Fehler weit
-schneller. Wie oft aber ist @qq{hier und da}? Das hängt von der
-Komplexität der Musik ab. ei einfachen Stücken reicht es vielleicht
-ein- oder zweimal, in sehr komplexer Musik sollte man sie vielleicht
-in jeden Takt einfügen.
-
-@item @strong{Ein Takt pro Textzeile}. Wenn irgendetwas kompliziertes
-vorkommt, entweder in der Musik selber oder in der Anpassung der
-Ausgabe,
-empfiehlt es sich oft, nur einen Takt pro Zeile zu schreiben.
-Bildschirmplatz zu sparen, indem Sie acht Takte in eine Zeile zwängen,
-hilft nicht weiter, wenn Sie ihre Datei @qq{debuggen} müssen.
-
-@item @strong{Kommentieren Sie ihre Dateien}. Benutzen Sie entweder
-Taktnummern (in regelmäßigen Abständen) oder Verweise auf musikalische
-Themen (@qq{Zweites Thema in den Geigen}, @qq{vierte Variation} usw.).
-Sie brauchen diese Kommentare vielleicht noch nicht, wenn Sie das Stück
-notieren, aber spätestens wenn Sie nach ein paar Jahren etwas
-verändern
-wollen oder Sie den Quelltext an einen Freund weitergeben wollen,
-ist es weitaus komplizierter, die Dateistruktur ohne Kommentare zu
-verstehen, als wenn Sie sie rechtzeitig eingefügt hätten.
-
-@item @strong{Schreiben Sie Klammern mit Einrückung}. Viele
-Probleme entstehen durch ungerade Anzahl von @code{@{} and
-@code{@}}-Klammern.
-
-@item @strong{Schreiben Sie Tondauerangaben} am Anfang von
-Abschnitten und Bezeichnern. Wenn Sie beispielsweise
- @code{c4 d e} am Anfang eines Abschnittes schreiben,
-ersparen Sie sich viele Probleme, wenn Sie ihre Musik
-eines Tages umarrangieren wollen.
-
-@item @strong{Trennen Sie Einstellungen} von den eigentlichen
-Noten. Siehe auch @ref{Tipparbeit sparen durch Bezeichner und Funktionen}
-und
-@ref{Stil-Dateien}.
-
-@end itemize
-
-
-@node Das Kopieren von bereits vorhandener Musik
-@subsection Das Kopieren von bereits vorhandener Musik
-@translationof Typesetting existing music
-
-Wenn Sie Musik aus einer fertigen Partitur kopieren (z. B. die
-LilyPond-Eingabe einer gedruckten Partitur):
-
-@itemize @bullet
-
-@item Schreiben Sie ein System ihrer Quelle nach dem anderen
-(aber trotzdem nur einen Takt pro Textzeile) und überprüfen
-Sie jedes System, nachdem Sie es fertig kopiert haben. Mit dem
-@code{showLastLength}- oder @code{showFirstLenght}-Befehl können Sie den Übersetzungsprozess
-beschleunigen. Siehe auch
-@ruser{Korrigierte Musik überspringen}.
-
-@item Definieren Sie @code{mBreak = @{ \break @}} und schreiben Sie
- @code{\mBreak} in der Quelldatei immer dann, wenn im Manuskript
-ein Zeilenumbruch vorkommt. Das macht es einfacher, die gesetzte
-Zeile mit den ursprünglichen Noten zu vergleichen. Wenn Sie die
-Partitur fertig gestellt haben, könne Sie @code{mBreak = @{ @}},
-also leer definieren, um diese manuellen Zeilenumbrüche zu entfernen.
-Damit kann dann LilyPond selber entscheiden, wohin es passende
-Zeilenumbrüche platziert.
-
-@item Wenn Sie eine Stimme für ein transponierendes Instrument als eine
-Variable notieren, wird empfohlen, dass die Noten von
-
-@example
-\transpose c klingende-Tonhöhe @{...@}
-@end example
-
-eingefasst werden (wobei @code{klingende-Tonhöhe} die klingende Tonhöhe
-des Instruments ist), sodass die Noten innerhalb der Variable für klingendes C
-geschrieben sind. Sie können die Variable zurücktransponieren, wenn es
-nötig ist, aber Sie müssen es nicht tun. Fehler in Transpositionen sind
-treten seltener auf, wenn alle Noten in den Variablen für die gleiche
-Ausgangstonhöhe geschrieben werden.
-
-Denken Sie auch daran, dass Sie nur von/nach C transponieren. Das heißt,
-dass die einzigen anderen Tonhöhen, die Sie in Transpositionen benutzen,
-die Tonhöhen der Instrumente sind, für die Sie schreiben: @code{bes} für
-eine B-Trompete oder @code{aes} für eine As-Klarinette usw.
-
-@end itemize
-
-
-@node Große Projekte
-@subsection Große Projekte
-@translationof Large projects
-
-Besonders wenn Sie an größeren Projekten arbeiten, ist es
-unumgänglich, dass Sie ihre LilyPond-Dateien klar strukturieren.
-
-@itemize @bullet
-
-@item @strong{Verwenden Sie Variablen für jede Stimme}, innerhalb
-der Definition sollte so wenig Struktur wie möglich sein. Die
-Struktur des @code{\score}-Abschnittes verändert sich am ehesten,
-während die @code{violine}-Definition sich wahrscheinlich mit einer
-neuen Programmversion nicht verändern wird.
-
-@example
-violine = \relative c'' @{
-g4 c'8. e16
-@}
-...
-\score @{
- \new GrandStaff @{
- \new Staff @{
- \violine
- @}
- @}
-@}
-@end example
-
-@item @strong{Trennen Sie Einstellungen von den Noten}. Diese
-Empfehlung wurde schon im Abschnitt @ref{Allgemeine Vorschläge} gegeben,
-aber für große Projekte ist es unumgänglich. Muss z. B. die
-Definition für @code{fdannp} verändert werden, so braucht
-man es nur einmal vorzunehmen und die Noten in der Geigenstimme,
-@code{violin}, bleiben unberührt.
-
-@example
-fdannp = _\markup@{
- \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
-violin = \relative c'' @{
-g4\fdannp c'8. e16
-@}
-@end example
-
-@end itemize
-
-
-@node Tipparbeit sparen durch Bezeichner und Funktionen
-@subsection Tipparbeit sparen durch Bezeichner und Funktionen
-@translationof Saving typing with variables and functions
-
-@cindex Variable
-@cindex Bezeichner
-
-Bis jetzt haben Sie immer etwa solche Noten gesehen:
-
-@lilypond[quote,verbatim,ragged-right]
-hornNotes = \relative c'' { c4 b dis c }
-\score {
- {
- \hornNotes
- }
-}
-@end lilypond
-
-Das könnte auch nützlich in Minimal-Music sein:
-
-@lilypond[quote,verbatim,ragged-right]
-fragmentA = \relative c'' { a4 a8. b16 }
-fragmentB = \relative c'' { a8. gis16 ees4 }
-violin = \new Staff { \fragmentA \fragmentA \fragmentB \fragmentA }
-\score {
- {
- \violin
- }
-}
-@end lilypond
-
-Sie können diese Bezeichner oder Variablen aber auch für
-(eigene) Einstellungen verwenden:
-
-@lilypond[quote,verbatim,ragged-right]
-dolce = \markup{ \italic \bold dolce }
-padText = { \once \override TextScript #'padding = #5.0 }
-fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p }
-violin = \relative c'' {
- \repeat volta 2 {
- c4._\dolce b8 a8 g a b |
- \padText
- c4.^"hi there!" d8 e' f g d |
- c,4.\fthenp b8 c4 c-. |
- }
-}
-\score {
- {
- \violin
- }
-\layout{ragged-right=##t}
-}
-@end lilypond
-
-Die Variablen haben in diesem Beispiel deutlich die
-Tipparbeit erleichtert. Aber es lohnt sich, sie zu
-einzusetzen, auch wenn man sie nur einmal anwendet,
-denn sie vereinfachen die Struktur.
-Hier ist das vorangegangene Beispiel ohne
-Variablen. Es ist sehr viel komplizierter zu lesen,
-besonders die letzte Zeile.
-
-@example
-violin = \relative c'' @{
- \repeat volta 2 @{
- c4._\markup@{ \italic \bold dolce @} b8 a8 g a b |
- \once \override TextScript #'padding = #5.0
- c4.^"hi there!" d8 e' f g d |
- c,4.\markup@{ \dynamic f \italic \small @{ 2nd @}
- \hspace #0.1 \dynamic p @} b8 c4 c-. |
- @}
-@}
-@end example
-
-@c TODO Replace the following with a better example -td
-@c Skylining handles this correctly without padText
-
-Bis jetzt wurde nur statische Substitution vorgestellt
--- wenn LilyPond den Befehl @code{\padText} findet, wird
-er ersetzt durch durch unsere vorherige Definition (alles,
-was nach dem @code{padtext =} kommt).
-
-LilyPond kennt aber auch nicht-statische Substitutionen (man
-kann sie sich als Funktionen vorstellen).
-
-@lilypond[quote,verbatim,ragged-right]
-padText =
-#(define-music-function (parser location padding) (number?)
- #{
- \once \override TextScript #'padding = #$padding
- #})
-
-\relative c''' {
- c4^"piu mosso" b a b
- \padText #1.8
- c4^"piu mosso" d e f
- \padText #2.6
- c4^"piu mosso" fis a g
-}
-@end lilypond
-
-Die Benutzung von Variablen hilft auch, viele Schreibarbeit zu
-vermeiden, wenn die Eingabesyntax von LilyPond sich verändert
-(siehe auch @ref{Alte Dateien aktualisieren}). Wenn nur eine einzige
-Definition (etwa @code{\dolce}) für alle Dateien verwendet wird
-(vgl. @ref{Stil-Dateien}), muss nur diese einzige Definition
-verändert werden, wenn sich die Syntax ändert. Alle Verwendungen
-des Befehles beziehen sich dann auf die neue Definition.
-
-@node Stil-Dateien
-@subsection Stil-Dateien
-@translationof Style sheets
-
-Die Ausgabe, die LilyPond erstellt, kann sehr stark modifiziert
-werden, siehe @ref{Die Ausgabe verändern} für Einzelheiten. Aber wie
-kann man diese Änderungen auf eine ganze Serie von Dateien
-anwenden? Oder die Einstellungen von den Noten trennen? Das
-Verfahren ist ziemlich einfach.
-
-Hier ist ein Beispiel. Es ist nicht schlimm, wenn Sie nicht auf
-Anhieb die Abschnitte mit den ganzen @code{#()} verstehen. Das
-wird im Kapitel @ref{Fortgeschrittene Optimierungen mit Scheme} erklärt.
-
-@lilypond[quote,verbatim,ragged-right]
-mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
- #:line(#:dynamic "mp" #:text #:italic "dolce" )))
-
-inst = #(define-music-function (parser location string) (string?)
- (make-music
- 'TextScriptEvent
- 'direction UP
- 'text (markup #:bold (#:box string))))
-
-\relative c'' {
- \tempo 4=50
- a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
- \inst "Clarinet"
- cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
-}
-@end lilypond
-
-Es treten einige Probleme mit überlappenden Symbolen auf. Sie
-werden beseitigt mit den Tricks aus dem Kapitel @ref{Verschieben von Objekten}.
-Aber auch die @code{mpdolce} und @code{inst}-Definitionen
-können verbessert werden. Sie produzieren das Ergebnis, das
-gewünscht ist, aber es wäre schön, sie auch in anderen Stücken
-verwenden zu können. Man könnte sie natürlich einfach kopieren
-und in die anderen Dateien einfügen, aber das ist lästig. Die
-Definitionen verbleiben auch in der Notendatei und diese @code{#()}
-sehen nicht wirklich schön aus. Sie sollen in einer anderen
-Datei versteckt werden:
-
-@example
-%%% speichern in einer Datei "definitions.ily"
-mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
- #:line(#:dynamic "mp" #:text #:italic "dolce" )))
-
-inst = #(define-music-function (parser location string) (string?)
- (make-music
- 'TextScriptEvent
- 'direction UP
- 'text (markup #:bold (#:box string))))
-@end example
-
-Auf diese Datei kann dann später mit dem @code{\include}-Befehl
-im oberen Teil der LilyPond-Datei zurückgegriffen werden. (Die
-Erweiterung @code{.ily} wird benutzt, um diese eingefügte Datei,
-die nicht alleine kompiliert werden kann, von der Hauptdatei zu
-unterscheiden.)
-Jetzt muss natürlich noch die Notendatei angepasst werden (gespeichert
-unter dem Namen @file{"music.ly"}).
-
-@c We have to do this awkward example/lilypond-non-verbatim
-@c because we can't do the \include stuff in the manual.
-
-@example
-\include "definitions.ily"
-
-\relative c'' @{
- \tempo 4=50
- a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
- \inst "Clarinet"
- cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
-@}
-@end example
-
-@lilypond[quote,ragged-right]
-mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
- #:line(#:dynamic "mp" #:text #:italic "dolce" )))
-
-inst = #(define-music-function (parser location string) (string?)
- (make-music
- 'TextScriptEvent
- 'direction UP
- 'text (markup #:bold (#:box string))))
-
-\relative c'' {
- \tempo 4=50
- a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
- \inst "Clarinet"
- cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
-}
-@end lilypond
-
-Das sieht schon besser aus, aber es sind noch einige Verbesserungen
-möglich.
-Das Glissando ist schwer zu sehen, also soll es etwas dicker erscheinen
-und dichter an den Notenköpfen gesetzt werden. Das Metronom-Zeichen
-soll über dem Schlüssel erscheinen, nicht über der ersten Note. Und
-schließlich kann unser Kompositionsprofessor @qq{C}-Taktangaben
-überhaupt nicht leiden, also
-müssen sie in @qq{4/4} verändert werden.
-
-Diese Veränderungen sollten Sie aber nicht in der @file{music.ly}-Datei
-vornehmen. Ersetzen Sie die @file{definitions.ily}-Datei hiermit:
-
-@example
-%%% definitions.ily
-mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
- #:line( #:dynamic "mp" #:text #:italic "dolce" )))
-
-inst = #(define-music-function (parser location string) (string?)
- (make-music
- 'TextScriptEvent
- 'direction UP
- 'text (markup #:bold (#:box string))))
-
-\layout@{
- \context @{ \Score
- \override MetronomeMark #'extra-offset = #'(-9 . 0)
- \override MetronomeMark #'padding = #'3
- @}
- \context @{ \Staff
- \override TimeSignature #'style = #'numbered
- @}
- \context @{ \Voice
- \override Glissando #'thickness = #3
- \override Glissando #'gap = #0.1
- @}
-@}
-@end example
-
-@lilypond[quote,ragged-right]
-mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
- #:line( #:dynamic "mp" #:text #:italic "dolce" )))
-
-inst = #(define-music-function (parser location string) (string?)
- (make-music
- 'TextScriptEvent
- 'direction UP
- 'text (markup #:bold (#:box string))))
-
-\layout{
- \context { \Score
- \override MetronomeMark #'extra-offset = #'(-9 . 0)
- \override MetronomeMark #'padding = #'3
- }
- \context { \Staff
- \override TimeSignature #'style = #'numbered
- }
- \context { \Voice
- \override Glissando #'thickness = #3
- \override Glissando #'gap = #0.1
- }
-}
-
-\relative c'' {
- \tempo 4=50
- a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
- \inst "Clarinet"
- cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
-}
-@end lilypond
-
-Das sieht schon besser aus! Aber angenommen Sie möchten dieses
-Stück jetzt veröffentlichen. Ihr Kompositionsprofessor mag
-die @qq{C}-Taktangaben nicht, aber Sie finden sie irgendwie
-schöner. Also kopieren Sie die Datei @file{definitions.ily} nach
-@file{web-publish.ily} und verändern diese. Weil die Noten
-in einer PDF-Datei auf dem Bildschirm angezeigt werden sollen,
-bietet es sich auch an, die gesamte Ausgabe zu vergrößern.
-
-@example
-%%% definitions.ily
-mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
- #:line( #:dynamic "mp" #:text #:italic "dolce" )))
-
-inst = #(define-music-function (parser location string) (string?)
- (make-music
- 'TextScriptEvent
- 'direction UP
- 'text (markup #:bold (#:box string))))
-
-#(set-global-staff-size 23)
-\layout@{
- \context @{ \Score
- \override MetronomeMark #'extra-offset = #'(-9 . 0)
- \override MetronomeMark #'padding = #'3
- @}
- \context @{ \Staff
- @}
- \context @{ \Voice
- \override Glissando #'thickness = #3
- \override Glissando #'gap = #0.1
- @}
-@}
-@end example
-
-@lilypond[quote,ragged-right]
-mpdolce = #(make-dynamic-script (markup #:hspace 0 #:translate '(5 . 0)
- #:line( #:dynamic "mp" #:text #:italic "dolce" )))
-
-inst = #(define-music-function (parser location string) (string?)
- (make-music
- 'TextScriptEvent
- 'direction UP
- 'text (markup #:bold (#:box string))))
-
-#(set-global-staff-size 23)
-\layout{
- \context { \Score
- \override MetronomeMark #'extra-offset = #'(-9 . 0)
- \override MetronomeMark #'padding = #'3
- }
- \context { \Voice
- \override Glissando #'thickness = #3
- \override Glissando #'gap = #0.1
- }
-}
-
-\relative c'' {
- \tempo 4=50
- a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
- \inst "Clarinet"
- cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
-}
-@end lilypond
-
-In der Notendatei muss jetzt nur noch @code{\include "definitions.ily"}
-durch @code{\include "web-publish.ily"} ausgetauscht werden.
-Das könnte man natürlich noch weiter vereinfachen. Also
-eine Datei @file{definitions.ily}, die nur die Definitionen
-von @code{mpdolce} und @code{inst} enthält, eine Datei
-@file{web-publish.ily}, die alle die Änderungen für den
-@code{\layout}-Abschnitt enthält und eine Datei @file{university.ily}
-für eine Ausgabe, die den Wünschen des Professors entspricht.
-Der Anfang der @file{music.ly}-Datei würde dann so aussehen:
-
-@example
-\include "definitions.ily"
-
-%%% Nur eine der beiden Zeilen auskommentieren!
-\include "web-publish.ily"
-%\include "university.ily"
-@end example
-
-Durch diese Herangehensweise kann auch bei der Erstellung
-von nur einer Ausgabeversion Arbeit gespart werden. Ich
-benutze ein halbes Dutzend verschiedener Stilvorlagen
-für meine Projekte. Jede Notationsdatei fängt an mit
-@code{\include "../global.ily"}, welches folgenden Inhalt hat:
-
-
-@example
-%%% global.ly
-\version "2.12.0"
-#(ly:set-option 'point-and-click #f)
-\include "../init/init-defs.ily"
-\include "../init/init-layout.ily"
-\include "../init/init-headers.ily"
-\include "../init/init-paper.ily"
-@end example
-
-
-@node Wenn etwas nicht funktioniert
-@section Wenn etwas nicht funktioniert
-@translationof When things don't work
-
-@menu
-* Alte Dateien aktualisieren::
-* Fehlersuche (alles auseinandernehmen)::
-* Minimalbeispiele::
-@end menu
-
-@node Alte Dateien aktualisieren
-@subsection Alte Dateien aktualisieren
-@translationof Updating old files
-
-Die Syntax von LilyPond verändert sich ab und zu. Wenn LilyPond
-besser wird, muss auch die Syntax (Eingabesprache) entsprechend
-angepasst werden. Teilweise machen diese Veränderungen die
-Eingabesprache einfacher lesbar, teilweise dienen sie dazu, neue
-Eigenschaften des Programmes benutzbar zu machen.
-
-LilyPond stellt ein Programm bereit, das Aktualisierungen
-vereinfacht: @code{convert-ly}. Einzelheiten zur Programmbenutzung
-finden sich in @rprogram{Dateien mit convert-ly aktualisieren}.
-
-Leider kann @code{convert-ly} nicht alle Veränderungen der Syntax
-berücksichtigen. Hier werden einfache @qq{Suchen und
-Ersetzen}-Veränderungen vorgenommen (wie etwa @code{raggedright} zu
-@code{ragged-right}), aber einige Veränderungen sind zu
-kompliziert. Die Syntax-Veränderungen, die das Programm nicht
-berücksichtigt, sind im Kapitel @rprogram{Dateien mit convert-ly aktualisieren} aufgelistet.
-
-Zum Beispiel wurden in LilyPond 2.4 und früheren Versionen
-Akzente und Umlaute mit LaTeX-Befehlen eingegeben, ein
-@qq{No\"el} etwa ergäbe das französische Wort für Weihnachten.
-In LilyPond 2.6 und höher müssen diese Sonderzeichen direkt
-als utf-8-Zeichen eingegeben werden, in diesem Fall also @qq{ë}.
-@code{convert-ly} kann nicht alle dieser LaTeX-Befehle
-verändern, das muss manuell vorgenommen werden.
-
-
-@node Fehlersuche (alles auseinandernehmen)
-@subsection Fehlersuche (alles auseinandernehmen)
-@translationof Troubleshooting (taking it all apart)
-
-Früher oder später werden Sie in die Lage kommen,
-dass LilyPond Ihre Datei nicht kompilieren will. Die
-Information, die LilyPond während der Übersetzung
-gibt, können Ihnen helfen, den Fehler zu finden, aber
-in vielen Fällen müssen Sie nach der Fehlerquelle
-auf die Suche gehen.
-
-Die besten Hilfsmittel sind in diesem Fall das Zeilen-
-und Blockkommentar (angezeigt durch @code{%} bzw.
-@code{%@{ ... %@}}). Wenn Sie nicht bestimmen können,
-wo sich das Problem befindet, beginnen Sie damit, große
-Teile des Quelltextes auszukommentieren. Nachdem Sie
-einen Teil auskommentiert haben, versuchen Sie, die Datei
-erneut zu übersetzen. Wenn es jetzt funktioniert, muss
-sich das Problem innerhalb der Kommentare befinden.
-Wenn es nicht funktioniert, müssen Sie weitere Teile
-auskommentieren bis sie eine Version haben, die funktioniert.
-
-In Extremfällen bleibt nur noch solch ein Beispiel übrig:
-
-@example
-\score @{
- <<
- % \melody
- % \harmony
- % \bass
- >>
- \layout@{@}
-@}
-@end example
-
-@noindent
-(also eine Datei ohne Noten).
-
-Geben Sie nicht auf, wenn das vorkommen sollte. Nehmen
-Sie das Kommentarzeichen von einem Teil wieder weg, sagen
-wir der Bassstimme, und schauen Sie, ob es funktioniert.
-Wenn nicht, dann kommentieren Sie die gesamte Bassstimme
-aus, aber nicht den @code{\bass}-Befehl in dem
- @code{\score}-Abschnitt:
-
-@example
-bass = \relative c' @{
-%@{
- c4 c c c
- d d d d
-%@}
-@}
-@end example
-
-Jetzt beginnen Sie damit, langsam Stück für Stück der
-Bassstimme wieder hineinzunehmen, bis Sie die problematische
-Zeile finden.
-
-Eine andere nützliche Technik zur Problemlösung ist es,
-@ref{Minimalbeispiele} zu konstruieren.
-
-
-@node Minimalbeispiele
-@subsection Minimalbeispiele
-@translationof Minimal examples
-
-Ein Minimalbeispiel ist eine Beispieldatei, die so klein wie
-möglich ist. Diese Beispiele sind sehr viel einfacher zu
-verstehen als die langen Originaldateien. Minimalbeispiele
-werden benutzt, um
-
-
-@itemize
-@item Fehlerberichte zu erstellen,
-@item eine Hilfeanfrage an die E-Mail-Liste zu schicken,
-@item Ein Beispiel zur @uref{http://lsr@/.dsi@/.unimi@/.it/,LilyPond
-Schnipselsammlung} hinzuzufügen.
-@end itemize
-
-Um ein Beispiel zu konstruieren, das so klein wie möglich ist,
-gibt es eine einfache Regel: Alles nicht Notwendige entfernen.
-Wenn Sie unnötige Teile einer Datei entfernen, bietet es sich an,
-sie auszukommentieren und nicht gleich zu löschen. Auf diese Weise
-können Sie eine Zeile leicht wieder mit aufnehmen, sollten Sie sie
-doch brauchen, anstatt sie von Anfang an neu zu schreiben.
-
-Es gibt zwei Ausnahmen dieser @qq{So klein wie möglich}-Regel:
-
-@itemize
-@item Fügen Sie immer einen @code{\version}Befehl ein.
-@item Wenn es möglich ist, benutzen Sie @code{\paper@{ ragged-right = ##t @}}
-am Beginn des Beispiels.
-@end itemize
-
-Der Sinn der Minimalbeispiele ist, dass sie einfach lesbar sind:
-
-@itemize
-@item Vermeiden Sie es, komplizierte Noten, Schlüssel oder Taktangaben
-zu verwenden, es sei denn, Sie wollen genau an diesen Elementen
-etwas demonstrieren.
-@item Benutzen Sie keine @code{\override}-Befehle, wenn sie nicht der
-Zweck des Beispieles sind.
-@end itemize
-
-
-@node Partituren und Stimmen
-@section Partituren und Stimmen
-@translationof Scores and parts
-
-Orchesternoten werden alle zweimal gesetzt. Erstens als Stimmen für
-die Musiker, und dann als große Partitur für den Dirigenten. Mit
-Variablen
-kann hier doppelte Arbeit erspart werden. Die Musik muss nur einmal
-eingegeben werden und wird in einer Variable abgelegt. Der Inhalt
-dieser
-Variable wird dann benutzt, um sowohl die Stimme als auch die Partitur
-zu erstellen.
-
-Es bietet sich an, die Noten in eigenen Dateien zu speichern. Sagen wir
-beispielsweise, dass in der Datei @file{Horn-Noten.ly} die folgenden
-Noten eines Duetts für Horn und Fagott gespeichert sind:
-
-@example
-HornNoten = \relative c @{
- \time 2/4
- r4 f8 a cis4 f e d
-@}
-@end example
-
-@noindent
-Daraus wird dann eine eigene Stimme gemacht, indem folgende Datei
-erstellt
-wird:
-
-@example
-\include "Horn-Noten.ly"
-\header @{
- instrument = "Horn in F"
-@}
-
-@{
- \transpose f c' \HornNoten
-@}
-@end example
-
-Die Zeile
-
-@example
-\include "Horn-Noten.ly"
-@end example
-
-@noindent
-setzt den Inhalt der Datei @file{Horn-Noten.ly} an die Stelle des
-Befehls in die aktuelle Datei. Damit besteht also eine Definition
-für @code{HornNoten}, so dass die Variable verwendet werden kann.
-Der Befehl @code{\transpose f@tie{}c'} zeigt an, dass das Argument,
-also @code{\HornNoten}, um eine Quinte nach oben transponiert wird.
-Klingendes @q{f} wird also als @code{c'} notiert. Das entspricht
-der Notation eines Waldhorns in F. Die Transposition zeigt die folgende
-Ausgabe:
-
-@lilypond[quote,ragged-right]
-\transpose f c' \relative c {
- \time 2/4
- r4 f8 a cis4 f e d
-}
-@end lilypond
-
-In der Musik für mehrere Instrumente kommt es oft vor, dass eine Stimme
-für mehrere Takte nicht spielt. Das wird mit einer besonderen Pause
-angezeigt, dem Pausenzeichen für mehrere Takte (engl. multi-measure
-rest). Sie wird mit dem @emph{großen} Buchstaben @samp{R} eingegeben,
-gefolgt von einer Dauer (@code{1}@tie{}für eine Ganze, @code{2}@tie{}
-für eine Halbe usw.). Indem man die Dauer multipliziert, können längere
-Pausen erstellt werden. Z. B. dauert diese Pause drei Takte eines
-2/4-Taktes:
-
-@example
-R2*3
-@end example
-
-Wenn die Stimme gedruckt wird, müssen diese Pausen zusammengezogen
-werden.
-Das wird durch eine Variable erreicht:
-
-@example
-\set Score.skipBars = ##t
-@end example
-
-@noindent
-Dieser Befehl setzt die Eigenschaft des @code{skipBars} (@qq{überspringe
-Takte}) auf wahr (@code{##t}). Wenn diese Option und die Pause
-zu der Musik des Beispiels gesetzt wird, erhält man folgendes Ergebnis:
-
-@lilypond[quote,ragged-right]
-\transpose f c' \relative c {
- \time 2/4
- \set Score.skipBars = ##t
- R2*3
- r4 f8 a cis4 f e d
-}
-@end lilypond
-
-Die Partitur wird erstellt, indem alle Noten zusammengesetzt werden.
-Angenommen, die andere Stimme trägt den Namen @code{FagottNoten}
- und ist in der Datei @file{Fagott-Noten.ly} gespeichert. Die
-Partitur sieht dann folgendermaßen aus:
-
-@example
-\include "Fagott-Noten.ly"
-\include "Horn-Noten.ly"
-
-<<
- \new Staff \HornNoten
- \new Staff \FagottNoten
->>
-@end example
-
-@noindent
-Und mit LilyPond übersetzt:
-
-@lilypond[quote,ragged-right]
-\relative c <<
- \new Staff {
- \time 2/4 R2*3
- r4 f8 a cis4 f e d
- }
- \new Staff {
- \clef bass
- r4 d,8 f | gis4 c | b bes |
- a8 e f4 | g d | gis f
- }
->>
-@end lilypond
-
-
-@node Make und Makefiles
-@section Make und Makefiles
-@translationof Make and Makefiles
-
-@cindex Makefile
-@cindex Make-Dateien
-@cindex make
-
-Fast alle Betriebssysteme, auf denen LilyPond benutzt werden kann,
-unterstützen ein Programm mit dem Namen @code{make}. Dieses Programm
-liest eine besondere Datei mit der Bezeichnung @code{Makefile},
-die definiert, welche Dateien von welchen anderen Dateien abhängen und
-welche Befehle für das Betriebssystem nötig sind, um eine Datei aus
-einer anderen zu erstellen. Ein Makefile könnte etwa erklären, wie
-@code{ballad.pdf} und @code{ballad.midi} aus @code{ballad.ly}
-erstellt werden können, indem LilyPond aufgerufen wird.
-
-Es gibt Fällen, wenn es sich sehr stark empfiehlt, ein @code{Makefile}
-für das aktuelle Projekt zu erstellen, entweder zur eigenen Bequemlichkeit,
-oder aber auch als Hilfe für andere, die vielleicht einmal die
-Quelldateien lesen und verstehen wollen. Insbesondere bei großen Projekten
-mit vielen eingefügten Dateien und unterschiedlichen Ausgabeoptionen
-(etwa Partitur, einzelne Stimmen, Dirigierpartitur, Klavierauszug usw.),
-aber auch bei Projekten, die komplizierte Programmaufrufe zur Verarbeitung
-erfordern (wenn man etwa mit @code{lilypond-book} arbeitet), lohnt
-sich die Erstellung einer Make-Datei. Diese Dateien können sehr
-unterschiedliche ausfallen, und ihre Komplexität und Flexibilität kann
-den Bedürfnissen aber auch Kenntnissen des Schreibers angepasst werden.
-Das Programm GNU Make ist auf GNU/Linux Distributionen und MacOS X
-installiert, aber es ist auch für Windows erhältlich.
-
-Das @strong{GNU Make Manual} gibt eine vollständige Anleitung, wie
-@code{make} benutzt werden kann. Hier sollen nur einige kleine
-Blicke auf die vielfältigen Möglichkeiten geworfen werden.
-
-Die Befehle, um Regeln in einer Make-Datei zu erstellen, unterscheidet
-sich zwischen den Betriebssystemen. Die verschiedenen Linuxe und
-MacOS X benutzen @code{bash}, während unter Windows @code{cmd} eingesetzt
-wird. Unter MacOS X muss man das System so konfigurieren, dass
-die Kommandozeile benutzt wird. Hier einige Beispiele für Make-Dateien,
-mit Versionen für Linux/MacOS und Windows.
-
-Das erste Beispiel ist für ein Orchesterstück in vier Stätzen unt mit
-der folgenden Dateistruktur:
-
-@example
-Symphony/
-|-- MIDI/
-|-- Makefile
-|-- Notes/
-| |-- cello.ily
-| |-- figures.ily
-| |-- horn.ily
-| |-- oboe.ily
-| |-- trioString.ily
-| |-- viola.ily
-| |-- violinOne.ily
-| `-- violinTwo.ily
-|-- PDF/
-|-- Parts/
-| |-- symphony-cello.ly
-| |-- symphony-horn.ly
-| |-- symphony-oboes.ly
-| |-- symphony-viola.ly
-| |-- symphony-violinOne.ly
-| `-- symphony-violinTwo.ly
-|-- Scores/
-| |-- symphony.ly
-| |-- symphonyI.ly
-| |-- symphonyII.ly
-| |-- symphonyIII.ly
-| `-- symphonyIV.ly
-`-- symphonyDefs.ily
-@end example
-
-Die @code{.ly}-Dateien un den Verzeichnissen @code{Scores} und
-@code{Parts} erhalten ihrere Noten aus @code{.ily}-Dateien, die
-sich im @code{Notes}-Verzeichnis befinden:
-
-@example
-%%% Kopfzeile der Datei "symphony-cello.ly"
-\include ../definitions.ily
-\include ../Notes/cello.ily
-@end example
-
-Die Make-Datei hat die Ziele @code{score} (das gesamte Stück als
-große Partitur), @code{movements} (die einzelnen Sätze als große
-Partitur) und @code{parts} (die einzelnen Stimmen für die Spieler).
-Es gibt auch das Ziel @code{archive}, welches ein Tar-Archiv
-der Quelldateien erstellt, etwa um die Quellen über das Internet
-oder per E-Mail zu verteilen. Hier die Make-Datei für GNU/Linux
-oder MacOS X. Sie sollte unter dem Namen @code{Makefile} im obersten
-Verzeichnis des Projektes gespeichert werden:
-
-@warning{Wenn ein Ziel oder eine Musterregel definiert ist, müssen
-die folgenden Zeilen mit Tabulatoren, nicht mit Leerzeichen beginnen.}
-
-@example
-# Namensstamm der Ausgabedateien
-piece = symphony
-# finde heraus, wieviele Prozessoren vorhanden sind
-CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
-# Der Befehl, um lilypond aufzurufen
-LILY_CMD = lilypond -ddelete-intermediate-files \
- -dno-point-and-click -djob-count=$(CPU_CORES)
-
-# Die Endungen, die im Makefile benutzt werden
-.SUFFIXES: .ly .ily .pdf .midi
-
-# Eingabe- und Ausgabedateien werden in den Verzeichnissen durchsucht,
-# die sich in der VPATH-Variable befinden. Alle sind Unterverzeichnisse
-# des aktuellen Verzeichnisses (angegeben durch die GNU make-Variable
-# `CURDIR').
-VPATH = \
- $(CURDIR)/Scores \
- $(CURDIR)/PDF \
- $(CURDIR)/Parts \
- $(CURDIR)/Notes
-
-# Die Musterregel, um PDF und MIDI-Dateien aus der LY-Eingabedatei
-# zu erstellen. Die .pdf-Ausgabedateien werden in das
-# `PDF'-Unterverzeichnis abgelegt, die .midi-Dateien in das
-# `MIDI'-Unterverzeichnis.
-%.pdf %.midi: %.ly
- $(LILY_CMD) $<; \ # this line begins with a tab
- if test -f "$*.pdf"; then \
- mv "$*.pdf" PDF/; \
- fi; \
- if test -f "$*.midi"; then \
- mv "$*.midi" MIDI/; \
- fi
-
-notes = \
- cello.ily \
- horn.ily \
- oboe.ily \
- viola.ily \
- violinOne.ily \
- violinTwo.ily
-
-# Abhängigkeiten der einzelnen Sätze.
-$(piece)I.pdf: $(piece)I.ly $(notes)
-$(piece)II.pdf: $(piece)II.ly $(notes)
-$(piece)III.pdf: $(piece)III.ly $(notes)
-$(piece)IV.pdf: $(piece)IV.ly $(notes)
-
-# Abhängigkeiten der großen Partitur.
-$(piece).pdf: $(piece).ly $(notes)
-
-# Abhängigkeiten der Stimmen.
-$(piece)-cello.pdf: $(piece)-cello.ly cello.ily
-$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
-$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
-$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
-$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
-$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
-
-# `make score' eintippen, um die große Partitur mit allen vier
-# Sätzen als eine Datei zu erstellen.
-.PHONY: score
-score: $(piece).pdf
-
-# `make parts' tippen, um alle Stimmen zu erstellen.
-# `make foo.pdf' tippen, um die Stimme für das Instrument `foo' zu erstellen.
-# Beispiel: `make symphony-cello.pdf'.
-.PHONY: parts
-parts: $(piece)-cello.pdf \
- $(piece)-violinOne.pdf \
- $(piece)-violinTwo.pdf \
- $(piece)-viola.pdf \
- $(piece)-oboes.pdf \
- $(piece)-horn.pdf
-
-# `make movements' tippen um Dateien für die vier Sätze einzeln zu erstellen.
-.PHONY: movements
-movements: $(piece)I.pdf \
- $(piece)II.pdf \
- $(piece)III.pdf \
- $(piece)IV.pdf
-
-all: score parts movements
-
-archive:
- tar -cvvf stamitz.tar \ # this line begins with a tab
- --exclude=*pdf --exclude=*~ \
- --exclude=*midi --exclude=*.tar \
- ../Stamitz/*
-@end example
-
-Unter Windows ergeben sich bestimmte Komplikationen. Nachdem man
-GNU Make für Windows heruntergeladen und installiert hat, muss
-man den richtigen Pfad in den Umgebungsvariablen des Systems setzen,
-damit die DOS-Kommandozeile das Make-Programm finden kann. Um das
-vorzunehmen, kann mit der rechten Maustaste auf "Arbeitsplatz"
-klicken, dann @code{Eigenschaften} und @code{Erweitert} geklickt
-werden. Hier wählt man @code{Umgebungsvariablen}. In der
-Liste @code{Systemvariablen} wählt man @code{Path} und mit
-einem Klick auf @code{Bearbeiten} kann man den Pfad zu der
-@code{.exe}-Datei von GNU Make hinzufügen, der etwa wie
-folgt aussieht:
-
-@example
-C:\Program Files\GnuWin32\bin
-@end example
-
-Die Make-Datei selber muss auch angepasst werden, um unterschiedliche
-Shell-Befehle zu verwenden und mit Leerzeichen umgehen zu können,
-die sich in einigen Standardverzeichnissen unter Windows befinden.
-Das @code{archive}-Ziel wird entfernt, da Windows den
-@code{tar}-Befehl nicht kennt, und Windows benutzt auch eine
-andere Dateiendung für midi-Dateien.
-
-
-@example
-## WINDOWS VERSION
-##
-piece = symphony
-LILY_CMD = lilypond -ddelete-intermediate-files \
- -dno-point-and-click \
- -djob-count=$(NUMBER_OF_PROCESSORS)
-
-# 8.3 Bezeichnung für CURDIR erhalten (Workaround wg. Leerzeichen in PATH)
-workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
- do @@echo %%~sb)
-
-.SUFFIXES: .ly .ily .pdf .mid
-
-VPATH = \
- $(workdir)/Scores \
- $(workdir)/PDF \
- $(workdir)/Parts \
- $(workdir)/Notes
-
-%.pdf %.mid: %.ly
- $(LILY_CMD) $< # diese Zeile beginnt mit Tabulator
- if exist "$*.pdf" move /Y "$*.pdf" PDF/ # begin with tab
- if exist "$*.mid" move /Y "$*.mid" MIDI/ # begin with tab
-
-notes = \
- cello.ily \
- figures.ily \
- horn.ily \
- oboe.ily \
- trioString.ily \
- viola.ily \
- violinOne.ily \
- violinTwo.ily
-
-$(piece)I.pdf: $(piece)I.ly $(notes)
-$(piece)II.pdf: $(piece)II.ly $(notes)
-$(piece)III.pdf: $(piece)III.ly $(notes)
-$(piece)IV.pdf: $(piece)IV.ly $(notes)
-
-$(piece).pdf: $(piece).ly $(notes)
-
-$(piece)-cello.pdf: $(piece)-cello.ly cello.ily
-$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
-$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
-$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
-$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
-$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
-
-.PHONY: score
-score: $(piece).pdf
-
-.PHONY: parts
-parts: $(piece)-cello.pdf \
- $(piece)-violinOne.pdf \
- $(piece)-violinTwo.pdf \
- $(piece)-viola.pdf \
- $(piece)-oboes.pdf \
- $(piece)-horn.pdf
-
-.PHONY: movements
-movements: $(piece)I.pdf \
- $(piece)II.pdf \
- $(piece)III.pdf \
- $(piece)IV.pdf
-
-all: score parts movements
-@end example
-
-Die nächste Make-Datei ist für ein @command{lilypond-book}-Dokument,
-das in LaTeX gesetzt wird. Das Projekt hat einen Index, welcher
-erfordert, dass der Befehl @command{latex} zweimal aufgerufen wird,
-um die Verweise zu aktualisieren. Ausgabedateien werden in einem
-@code{out}-Verzeichnis für die .pdf-Dateien gespeichert und in
-@code{htmlout} für die html-Dateien.
-
-@example
-SHELL=/bin/sh
-FILE=myproject
-OUTDIR=out
-WEBDIR=htmlout
-VIEWER=acroread
-BROWSER=firefox
-LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
-LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
-PDF=cd $(OUTDIR) && pdflatex $(FILE)
-HTML=cd $(WEBDIR) && latex2html $(FILE)
-INDEX=cd $(OUTDIR) && makeindex $(FILE)
-PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &
-
-all: pdf web keep
-
-pdf:
- $(LILYBOOK_PDF) # begin with tab
- $(PDF) # begin with tab
- $(INDEX) # begin with tab
- $(PDF) # begin with tab
- $(PREVIEW) # begin with tab
-
-web:
- $(LILYBOOK_HTML) # begin with tab
- $(HTML) # begin with tab
- cp -R $(WEBDIR)/$(FILE)/ ./ # begin with tab
- $(BROWSER) $(FILE)/$(FILE).html & # begin with tab
-
-keep: pdf
- cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf # begin with tab
-
-clean:
- rm -rf $(OUTDIR) # begin with tab
-
-web-clean:
- rm -rf $(WEBDIR) # begin with tab
-
-archive:
- tar -cvvf myproject.tar \ # begin this line with tab
- --exclude=out/* \
- --exclude=htmlout/* \
- --exclude=myproject/* \
- --exclude=*midi \
- --exclude=*pdf \
- --exclude=*~ \
- ../MyProject/*
-@end example
-
-TODO: soll auch unter Windows funktionieren
-
-Die vorige Make-Datei funktioniert nicht unter Windows. Als Alternative
-für Windows-Benutzer könnte man eine einfache batch-Datei erstellen,
-welche die erforderlichen Befehl enthält. Sie kümmert sich nicht
-um Abhängigkeiten, wie es eine Make-Datei kann, aber wenigstens
-wird die Kompilation auf einen einzigen Befehl beschränkt. Das folgende
-kann als Datei @command{build.bat} oder @command{build.cmd} gespeichert
-werden. Die Batch-Datei kann auf der Kommandozeile aufgerufen werden
-oder einfach doppelt angeklickt werden.
-
-@example
-lilypond-book --output=out --pdf myproject.lytex
-cd out
-pdflatex myproject
-makeindex myproject
-pdflatex myproject
-cd ..
-copy out\myproject.pdf MyProject.pdf
-@end example
-
-
-@seealso
-Programmbenutzung:
-@rprogram{Einrichtung für MacOS X},
-@rprogram{Benutzung auf der Kommandozeile},
-@rprogram{LilyPond-book}
projects / lilypond.git / commitdiff