X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=Documentation%2Fde%2Fuser%2Fworking.itely;h=3803169ee8b2b5041fd38e49bef0c21c1f5c5925;hb=5c14a087ca6cbd665fd631452b7b1283ba0387c3;hp=f780ed2309b88f472b9cadc1a200500222a9d634;hpb=54e99fe904e58c598106270edfc3b6435109ed95;p=lilypond.git

diff --git a/Documentation/de/user/working.itely b/Documentation/de/user/working.itely
index f780ed2309..3803169ee8 100644
--- a/Documentation/de/user/working.itely
+++ b/Documentation/de/user/working.itely
@@ -1,59 +1,59 @@
 @c -*- coding: utf-8; mode: texinfo; -*-
 @c This file is part of lilypond.tely
 @ignore
-    Translation of GIT committish: 2655939401240c8261f87583aeda760b8cf52d7e
+    Translation of GIT committish: 550152ed5d5015d13abf2af83b2e040f996a66a4
 
     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.11.61"
+
 @node Working on LilyPond projects
 @chapter Working on LilyPond projects
 
 Dieses Kapitel erklärt, wie bestimmte häufige Probleme zu 
-lösen oder ganz zu vermeiden sind. Wenn Sie schon 
+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
-* Suggestions for writing LilyPond files::  
-* Saving typing with identifiers and functions::  
-* Style sheets::                
-* Updating old files::          
-* Troubleshooting (taking it all apart)::  
-* Minimal examples::            
+* Suggestions for writing LilyPond input files::  
+* When things don't work::      
+* Scores and parts::            
 @end menu
 
 
-@node Suggestions for writing LilyPond files
-@section Suggestions for writing LilyPond files
+@node Suggestions for writing LilyPond input files
+@section 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 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 
+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 
+@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 vesteht man auf den ersten Blick, 
+@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ändernungen 
+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 Hanbarbeit. LilyPond-Dateien können 
+bestimmte Änderungen brauchen Handarbeit.  LilyPond-Dateien können 
 strukturiert werden, damit sie einfacher aktualisierbar sind.
 @end itemize
 
@@ -61,38 +61,39 @@ strukturiert werden, damit sie einfacher aktualisierbar sind.
 * General suggestions::         
 * Typesetting existing music::  
 * Large projects::              
+* Saving typing with variables and functions::  
+* Style sheets::                
 @end menu
 
 
 @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 
+in jede Datei}.  Beachten Sie, dass in allen Vorlagen die Versionsnummer  
+@code{\version "2.11.61"} 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 
+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 
+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 
-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 
-einfachen Stücken reicht es vielleicht ein- oder zweimal, in sehr
-komplexer Musik sollte man sie vielleicht in jeden Takt einfügen.
+@item @strong{Benutzen Sie Überprüfungen}: @ruser{Octave checks}, und
+@ruser{Bar and bar number checks}.  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 
+@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.
 
@@ -104,20 +105,20 @@ 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.
+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 
+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{Saving typing with identifiers and functions} 
+Noten.  Siehe auch @ref{Saving typing with variables and functions} 
 und
 @ref{Style sheets}.
 
@@ -134,19 +135,19 @@ LilyPond-Eingabe einer gedruckten Partitur):
 
 @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 
+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 
+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 plaziert.
+Zeilenumbrüche platziert.
 
 @end itemize
 
@@ -154,34 +155,34 @@ Zeilenumbrüche plaziert.
 @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 
+während die @code{violine}-Definition sich wahrscheinlich mit einer 
 neuen Programmversion nicht verändern wird.
 
 @example
-violin = \relative c'' @{
+violine = \relative c'' @{
 g4 c'8. e16
 @}
 ...
 \score @{
   \new GrandStaff @{
     \new Staff @{
-      \violin
+      \violine
     @}
   @}
 @}
 @end example
 
 @item @strong{Trennen Sie Einstellungen von den Noten}.  Diese 
-Empfehlung wurde schon im Kapitel @ref{General suggestions} gegeben, 
-aber für große Projekte ist es unumgänglich. Muss z. B. die 
+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, 
 @code{violin}, bleiben unberührt.
@@ -197,8 +198,8 @@ g4\fdannp c'8. e16
 @end itemize
 
 
-@node Saving typing with identifiers and functions
-@section Saving typing with identifiers and functions
+@node Saving typing with variables and functions
+@subsection Saving typing with variables and functions
 
 @cindex Variable
 @cindex Bezeichner
@@ -251,11 +252,11 @@ violin = \relative c'' {
 @end lilypond
 
 Die Variablen haben in diesem Beispiel deutlich die 
-Tipparbeit erleichtert. Aber es lohnt sich, sie zu 
+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, 
+Variablen.  Es ist sehr viel komplizierter zu lesen, 
 besonders die letzte Zeile. 
 
 @example
@@ -270,10 +271,13 @@ violin = \relative 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).
+was nach dem @code{padtext =} kommt).
 
 LilyPond kennt aber auch nicht-statische Substitutionen (man 
 kann sie sich als Funktionen vorstellen).
@@ -294,25 +298,25 @@ padText =
 }
 @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 @ref{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 
-verändert werden, wenn sich die Syntax ändert. Alle Verwendungen 
+verändert werden, wenn sich die Syntax ändert.  Alle Verwendungen 
 des Befehles beziehen sich dann auf die neue Definition.
 
 @node Style sheets
-@section Style sheets
+@subsection Style sheets
 
-Die Ausgabe, die LilyPond erstellt, kann sehr start modifiziert 
-werden, siehe @ref{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 
+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 
+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.
 
 @lilypond[quote,verbatim,ragged-right]
@@ -335,13 +339,13 @@ tempoMark = #(define-music-function (parser location markp) (string?)
 
 Es treten einige Probleme mit überlappenden Symbolen auf. Sie 
 werden beseitigt mit den Tricks aus dem Kapitel @ref{Moving objects}.
-Aber auch die @code{mpdolce} und @code{tempoMark}-Defintiionen 
-können verbessert werden. Sie produzieren das Ergebnis, das 
+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önen. 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 
+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
@@ -393,17 +397,17 @@ tempoMark = #(define-music-function (parser location markp) (string?)
 }
 @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 
-soll über dem Schlüssel erscheinen, nicht über der ersten Note. Und 
+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.ly}-Datei hiermit:
+vornehmen.  Ersetzen Sie die @file{definitions.ly}-Datei hiermit:
 
 @example
 %%%  definitions.ly
@@ -464,12 +468,12 @@ tempoMark = #(define-music-function (parser location markp) (string?)
 }
 @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ä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
@@ -531,7 +535,7 @@ tempoMark = #(define-music-function (parser location markp) (string?)
 
 In der Notendatei muss jetzt nur noch @code{\include "definitions.ly"}
 durch @code{\include "web-publish.ly"} ausgetauscht werden. 
-Das könnte man natürlich noch weiter vereinfachen. Also 
+Das könnte man natürlich noch weiter vereinfachen.  Also 
 eine Datei @file{definitions.ly}, die nur die Definitionen 
 von @code{mpdolce} und @code{tempoMark} enthält, eine Datei 
 @file{web-publish.ly}, die alle die Änderungen für den 
@@ -548,15 +552,15 @@ Der Anfang der @file{music.ly}-Datei würde dann so aussehen:
 @end example
 
 Durch diese Herangehensweise kann auch bei der Erstellung 
-von nur einer Ausgabeversion Arbeit gespart werden. Ich 
-benutze ein halbes Dutzent verschidener Stilvorlagen 
-für meine Projekte. Jede Notationsdatei fängt an mit 
+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.ly"}, welches folgenden Inhalt hat:
 
 
 @example
 %%%   global.ly
-\version "2.11.15"
+\version "2.11.61"
 #(ly:set-option 'point-and-click #f)
 \include "../init/init-defs.ly"
 \include "../init/init-layout.ly"
@@ -565,27 +569,35 @@ für meine Projekte. Jede Notationsdatei fängt an mit
 @end example
 
 
+@node When things don't work
+@section When things don't work
+
+@menu
+* Updating old files::          
+* Troubleshooting (taking it all apart)::  
+* Minimal examples::            
+@end menu
+
 @node Updating old files
-@section Updating old files
+@subsection Updating old files
 
-Die Syntax von LilyPond verändert sich ab und zu. Wenn LilyPond 
+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 
+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 @ref{Updating files with convert-ly}.
-
-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 becoming @code{ragged-right}),
-aber einige Veränderungen sind zu kompliziert. Die 
-Syntax-Veränderungen, 
-die das Programm nicht berücksichtigt, sind im Kapitel  @ref{Updating 
-files with convert-ly} aufgelistet.
+vereinfacht: @code{convert-ly}.  Einzelheiten zur Programmbenutzung 
+finden sich in @rprogram{Updating files with convert-ly}.
+
+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{Updating files with
+convert-ly} aufgelistet.
 
 Zum Beispiel wurden in LilyPond 2.4 und früheren Versionen 
 Akzente und Umlaute mit LaTeX-Befehlen eingegeben, ein 
@@ -597,27 +609,27 @@ verändern, das muss manuell vorgenommen werden.
 
 
 @node Troubleshooting (taking it all apart)
-@section Troubleshooting (taking it all apart)
+@subsection 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 Hilfsmittel sind in diesem Fall das Zeilen- 
 und Blockkommentar (angezeigt durch @code{%} bzw. 
-@code{%@{ ... %@}}). Wenn Sie nicht bestimmen können, 
+@code{%@{ ... %@}}).  Wenn Sie nicht bestimmen können, 
 wo sich das Problem befindet, beginnen Sie damit, große 
-Teile des Quelltextes auszukommentieren. Nachdem Sie 
+Teile des Quelltextes auszukommentieren.  Nachdem Sie 
 einen Teil auskommentiert haben, versuchen Sie, die Datei 
-erneut zu übersetzen. Wenn es jetzt funktioniert, muss 
+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,
+In Extremfällen bleibt nur noch solch ein Beispiel übrig:
 
 @example
 \score @{
@@ -633,10 +645,10 @@ In Extremfällen bleibt nur noch solch ein Beispiel übrig,
 @noindent
 (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 
+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:
 
@@ -658,11 +670,11 @@ Eine andere nützliche Technik zur Problemlösung ist es,
 
 
 @node Minimal examples
-@section Minimal examples
+@subsection 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 
+möglich ist.  Diese Beispiele sind sehr viel einfacher zu 
+verstehen als die langen Originaldateien.  Minimalbeispiele 
 werden benutzt, um
 
 
@@ -670,13 +682,13 @@ werden benutzt, um
 @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.
+Schnipselsammlung} hinzuzufügen.
 @end itemize
 
-Um ein Beispiel zu konstruieren, dass so klein wie möglich ist, 
-gibt es eine einfache Regel: Alles nicht Notwendige entfernen. 
+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 
+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.
 
@@ -684,18 +696,148 @@ 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 @}}
+@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
 
 
+@node Scores and parts
+@section 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
+
+