version that you are working on. See TRANSLATION for details.
@end ignore
-@c \version "2.11.38"
+@c \version "2.11.51"
@node Working on LilyPond projects
@chapter Working on LilyPond projects
@item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen
wollen? Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten
-wollen? Manche LilyPond-Dateien vesteht man auf den ersten Blick,
+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ändernungen
+allmählich mit Verbesserungen im Programm. Die meisten Veränderungen
können automatisch durch @code{convert-ly} gelöst werden, aber
-bestimmte Änderungen brauchen Hanbarbeit. LilyPond-Dateien können
+bestimmte Änderungen brauchen Handarbeit. LilyPond-Dateien können
strukturiert werden, damit sie einfacher aktualisierbar sind.
@end itemize
@item @strong{Schreiben Sie immer mit @code{\version} die
Versionsnummer
in jede Datei}. Beachten Sie, dass in allen Vorlagen die Versionsnummer
-@code{\version "2.11.38"} eingetragen ist. Es empfielt sich, in alle
+@code{\version "2.11.51"} 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
@item @strong{Ein Takt pro Textzeile}. Wenn irgendetwas kompliziertes
vorkommt, entweder in der Musik selber oder in der Anpassung der
Ausgabe,
-empfielt es sich oft, nur einen Takt pro Zeile zu schreiben.
+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.
eines Tages umarrangieren wollen.
@item @strong{Trennen Sie Einstellungen} von den eigentlichen
-Noten. Siehe auch @ruser{Saving typing with identifiers and functions}
+Noten. Siehe auch @ref{Saving typing with variables and functions}
und
-@ruser{Style sheets}.
+@ref{Style sheets}.
@end itemize
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 plaziert.
+Zeilenumbrüche platziert.
@end itemize
@end example
@item @strong{Trennen Sie Einstellungen von den Noten}. Diese
-Empfehlung wurde schon im Abschnitt @ruser{General suggestions} gegeben,
+Empfehlung wurde schon im Abschnitt @ref{General suggestions} 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,
Die Benutzung von Variablen hilft auch, viele Schreibarbeit zu
vermeiden, wenn die Eingabesyntax von LilyPond sich verändert
-(siehe auch @ruser{Updating old files}). Wenn nur eine einzige
+(siehe auch @ref{Updating old files}). Wenn nur eine einzige
Definition (etwa @code{\dolce}) für alle Dateien verwendet wird
-(vgl. @ruser{Style sheets}), muss nur diese einzige Definition
+(vgl. @ref{Style sheets}), 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 Style sheets
@subsection Style sheets
-Die Ausgabe, die LilyPond erstellt, kann sehr start modifiziert
-werden, siehe @ruser{Tweaking output} für Einzelheiten. Aber wie
+Die Ausgabe, die LilyPond erstellt, kann sehr stark modifiziert
+werden, siehe @ref{Tweaking output} 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 @ruser{Advanced tweaks with Scheme} erklärt.
+wird im Kapitel @ref{Advanced tweaks with Scheme} erklärt.
@lilypond[quote,verbatim,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
@end lilypond
Es treten einige Probleme mit überlappenden Symbolen auf. Sie
-werden beseitigt mit den Tricks aus dem Kapitel @ruser{Moving objects}.
-Aber auch die @code{mpdolce} und @code{tempoMark}-Defintiionen
+werden beseitigt mit den Tricks aus dem Kapitel @ref{Moving objects}.
+Aber auch die @code{mpdolce} und @code{tempoMark}-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
-Defintionen verbleiben auch in der Notendatei und diese @code{#()}
+Definitionen verbleiben auch in der Notendatei und diese @code{#()}
sehen nicht wirklich schön aus. Sie sollen in einer anderen
Datei versteckt werden:
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.ly} nach
-@file{web-publish.ly} und veränderen diese. Weil die Noten
-in einer PDF-Datei auf dem Bilschirm angezeigt werden sollen,
+@file{web-publish.ly} 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
Durch diese Herangehensweise kann auch bei der Erstellung
von nur einer Ausgabeversion Arbeit gespart werden. Ich
-benutze ein halbes Dutzent verschidener Stilvorlagen
+benutze ein halbes Dutzend verschiedener Stilvorlagen
für meine Projekte. Jede Notationsdatei fängt an mit
@code{\include "../global.ly"}, welches folgenden Inhalt hat:
@example
%%% global.ly
-\version "2.11.38"
+\version "2.11.51"
#(ly:set-option 'point-and-click #f)
\include "../init/init-defs.ly"
\include "../init/init-layout.ly"
in vielen Fällen müssen Sie nach der Fehlerquelle
auf die Suche gehen.
-Die besten Hilfmittel sind in diesem Fall das Zeilen-
+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
Zeile finden.
Eine andere nützliche Technik zur Problemlösung ist es,
-@ruser{Minimal examples} zu konstruieren.
+@ref{Minimal examples} zu konstruieren.
@node Minimal examples
Tiefer gehende Information darüber, wie Stimmauszüge und Partituren
erstellt werden, finden sich im Notationshandbuch, siehe
-@ruser{Orchestral music}.
+@ref{Scores and parts}.
Das Setzen der Variablen, die das Verhalten von LilyPond beeinflussen
(@q{properties}), wird im Kapitel
projects / lilypond.git / blobdiff