@c -*- coding: utf-8; mode: texinfo; -*-
@c This file is part of lilypond.tely
@ignore
- Translation of GIT committish: fc6469f52dc27d4b5c22067367878a5c2ff5fb45
+ Translation of GIT committish: 3121682025660b6c85fbf3f22bb9cd8396699ad1
When revising a translation, copy the HEAD committish of the
version that you are working on. See TRANSLATION for details.
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 setzen,
+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.
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
+@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,
über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.
@node General suggestions
@subsection General suggestions
-Hier einige Vorschläge wie Sie Probleme vermeiden oder lösen können:
+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.11.15"} eingetragen ist. Es empfielt sich, in alle
+@code{\version "2.11.38"} eingetragen ist. Es empfielt 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}: @ref{Bar check},
-@ref{Octave check} und
-@ref{Barnumber check}. Wenn Sie hier und da diese Überprüfungen
+@item @strong{Benutzen Sie Überprüfungen}: @ruser{Bar check},
+@ruser{Octave check} und
+@ruser{Barnumber check}. 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. Bei
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.
+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
eines Tages umarrangieren wollen.
@item @strong{Trennen Sie Einstellungen} von den eigentlichen
-Noten. Siehe auch @ref{Saving typing with identifiers and functions}
+Noten. Siehe auch @ruser{Saving typing with identifiers and functions}
und
-@ref{Style sheets}.
+@ruser{Style sheets}.
@end itemize
Sie jedes System, nachdem Sie es fertig kopiert haben. Mit dem
@code{showLastLength}-Befehl können Sie den Übersetzungsprozess
beschleunigen. Siehe auch
-@ref{Skipping corrected music}.
+@ruser{Skipping corrected music}.
-@item Definieren Sie @code{mBreak = @{ \break @}} schreiben Sie
+@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
@node Large projects
@subsection Large projects
-Besonders wenn sie an größeren Projekten arbeiten, ist es
+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 sowenig Struktur wie möglich sein. Die
+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{violin}-Definition sich wahrscheinlich mit einer
neuen Programmversion nicht verändern wird.
@end example
@item @strong{Trennen Sie Einstellungen von den Noten}. Diese
-Empfehlung wurde schon im Kapitel @ref{General suggestions} gegeben,
+Empfehlung wurde schon im Abschnitt @ruser{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 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.
+denn sie vereinfachen die Struktur.
Hier ist das vorangegangene Beispiel ohne
Variablen. Es ist sehr viel komplizierter zu lesen,
besonders die letzte Zeile.
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).
+was nach dem @code{padtext =} kommt).
LilyPond kennt aber auch nicht-statische Substitutionen (man
kann sie sich als Funktionen vorstellen).
}
@end lilypond
-Die Benutzung von Variablen hilft auch viele Schreibarbeit zu
+Die Benutzung von Variablen hilft auch, viele Schreibarbeit zu
vermeiden, wenn die Eingabesyntax von LilyPond sich verändert
-(siehe auch @ref{Updating old files}). Wenn nur eine einzige
+(siehe auch @ruser{Updating old files}). Wenn nur eine einzige
Definition (etwa @code{\dolce}) für alle Dateien verwendet wird
-(vgl. @ref{Style sheets}), muss nur diese einzige Definition
+(vgl. @ruser{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.
@section Style sheets
Die Ausgabe, die LilyPond erstellt, kann sehr start modifiziert
-werden, siehe @ref{Tweaking output} für Einzelheiten. Aber wie
+werden, siehe @ruser{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 @ref{Advanced tweaks with Scheme} erklärt.
+wird im Kapitel @ruser{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 @ref{Moving objects}.
+werden beseitigt mit den Tricks aus dem Kapitel @ruser{Moving objects}.
Aber auch die @code{mpdolce} und @code{tempoMark}-Defintiionen
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önen. Man könnte sie natürlich einfach kopieren
+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{#()}
sehen nicht wirklich schön aus. Sie sollen in einer anderen
}
@end lilypond
-Das sieht schon besser, aber es sind noch einige Verbesserungen
+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
}
@end lilypond
-Das sieht schon besser aus! Aber angenommen ich möchte dieses
-Stück jetzt veröffentlichen. Mein Kompositionsprofessor mag
-die @qq{C}-Taktangaben nicht, aber ich finde sie irgendwie
-schöner. Also kopiere ich die Datei @file{definitions.ly} nach
-@file{web-publish.ly} und verändere diese. Weil die Noten
-in einem Pdf auf dem Bilschirm angezeigt werden sollen,
+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.ly} nach
+@file{web-publish.ly} und veränderen diese. Weil die Noten
+in einer PDF-Datei auf dem Bilschirm angezeigt werden sollen,
bietet es sich auch an, die gesamte Ausgabe zu vergrößern.
@example
@example
%%% global.ly
-\version "2.11.15"
+\version "2.11.38"
#(ly:set-option 'point-and-click #f)
\include "../init/init-defs.ly"
\include "../init/init-layout.ly"
@section Troubleshooting (taking it all apart)
Früher oder später werden Sie in die Lage kommen,
-dass LilyPond ihre Datei nicht kompilieren will. Die
+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 Hilfmittel sin din diesem Fall das Zeilen-
+Die besten Hilfmittel 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
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,
+In Extremfällen bleibt nur noch solch ein Beispiel übrig:
@example
\score @{
(also eine Datei ohne Noten).
Geben Sie nicht auf, wenn das vorkommen sollte. Nehmen
-Sie das Kommentarzeichen on einem Teil wieder weg, sagen
-wir der Bassstimme und schauen Sie, ob es funktioniert.
-Wenn nicht, dann kommentieren sie die gesamte Bassstimme
+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:
Zeile finden.
Eine andere nützliche Technik zur Problemlösung ist es,
-@ref{Minimal examples} zu konstruieren.
+@ruser{Minimal examples} zu konstruieren.
@node Minimal examples
Schnipselsammlung}hinzuzufügen.
@end itemize
-Um ein Beispiel zu konstruieren, dass so klein wie möglich ist,
+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
@itemize
@item Fügen Sie immer einen @code{\version}Befehl ein.
-@item Wenn es möglich ist, benutzen Sie @code{\paper@{ ragged-right=##t @}}
+@item Wenn es möglich ist, benutzen Sie @code{\paper@{ ragged-right = ##t @}}
am Beginn des Beispiels.
@end itemize
-Der Sinn der Minimalbeispiel ist, dass sie einfach lesbar sind:
+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
+@item Benutzen Sie keine @code{\override}-Befehle, wenn sie nicht der
Zweck des Beispieles sind.
@end itemize