From: John Mandereau Date: Sat, 12 Sep 2009 19:00:03 +0000 (+0200) Subject: Merge branch 'lilypond/translation' of ssh://jomand@git.sv.gnu.org/srv/git/lilypond X-Git-Tag: release/2.13.4-1~51 X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=9f113012b3cdfab51066c023e18579e183d1ad94;hp=598e295b35375e23040e61b60c68e75b0b00a7ad;p=lilypond.git Merge branch 'lilypond/translation' of ssh://jomand@git.sv.gnu.org/srv/git/lilypond --- diff --git a/Documentation/de/application.tely b/Documentation/de/application.tely index 6231232350..a651b9597b 100644 --- a/Documentation/de/application.tely +++ b/Documentation/de/application.tely @@ -1,13 +1,13 @@ \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 @@ -23,7 +23,7 @@ @omflanguage German @end ignore -@c Translators: Till Rettig +@c Translators: Till Paala @ifnottex @node Top @@ -162,7 +162,9 @@ Free Documentation License''. @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 @@ -173,9 +175,12 @@ finden sich Kopien dieser und anderer Dokumentationsdateien. @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 @@ -190,8 +195,11 @@ 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 diff --git a/Documentation/de/application/working.itely b/Documentation/de/application/working.itely new file mode 100644 index 0000000000..6c415c2dd6 --- /dev/null +++ b/Documentation/de/application/working.itely @@ -0,0 +1,1239 @@ +@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} diff --git a/Documentation/de/essay.tely b/Documentation/de/essay.tely index 0b8f44085a..1c173ce208 100644 --- a/Documentation/de/essay.tely +++ b/Documentation/de/essay.tely @@ -1,6 +1,6 @@ \input texinfo @c -*- coding: utf-8; mode: texinfo; -*- @ignore - Translation of GIT committish: e9049b4f3899b7006134987004bd18e813b96d27 + 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. @@ -155,7 +155,7 @@ Free Documentation License''. @contents -@c @include essay/engraving.itely +@include essay/engraving.itely @include essay/literature.itely @include fdl.itexi diff --git a/Documentation/de/essay/engraving.itely b/Documentation/de/essay/engraving.itely new file mode 100644 index 0000000000..507b94e8c7 --- /dev/null +++ b/Documentation/de/essay/engraving.itely @@ -0,0 +1,834 @@ +@c -*- coding: utf-8; mode: texinfo; -*- + +@ignore + Translation of GIT committish: 4582b7b24d22b2041bfcba49e716a714effcce92 + + + 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.13.4" + +@node Notensatz +@chapter Notensatz +@translationof Music engraving + +Dieser Abschnitt erklärt die Ziele und die Architektur von LilyPond. + +@menu +* Notensatz:: +* Automatisierter Notensatz:: +* Welche Symbole?:: +* Die Darstellung der Musik:: +* Beispielanwendung:: +@end menu + + +@node Notensatz +@unnumberedsubsec Notensatz +@translationof Engraving + +@cindex Notensatz +@cindex Typographie +@cindex Notengravur +@cindex Gravur, Notensatz +@cindex Plattendruck, Noten + +Die Kunst des Notensatzes wird auch als Notenstich bezeichnet. Dieser +Begriff stammt aus dem traditionellen Notendruck. Noch bis vor etwa 20 +Jahren wurden Noten erstellt, indem man sie in eine Zink- oder Zinnplatte +schnitt oder mit Stempeln schlug. Diese Platte wurde dann mit Druckerschwärze + versehen, so dass sie in den geschnittenen und gestempelten Vertiefungen +blieb. Diese Vertiefungen schwärzten dann ein auf die Platte gelegtes +Papier. Das Gravieren wurde vollständig von Hand erledigt. Es war darum +sehr mühsam, Korrekturen anzubringen, weshalb man von vornherein richtig + schneiden musste. Es handelte sich dabei um ein sehr spezialisiertes Handwerk. + +Heutzutage wird fast alle gedruckte Musik von Computern erstellt. Das +hat einige deutliche Vorteile: Drucke sind billiger als die gravierten +Platten und der Computersatz kann per E-Mail verschickt werden. Leider +hat der intensive Einsatz des Computers die graphische Qualität +des Notensatzes vermindert. Mit dem Computer erstellte Noten sehen +langweilig und mechanisch aus, was es erschwert, von ihnen zu spielen. + + +@c introduce illustrating aspects of engraving, font... +Die Abbildung unten illustriert den Unterschied zwischen +traditionellem Notensatz und einem typischen Computersatz. Das +dritte Bild zeigt, wie LilyPond die Formen des traditionellen +Satzes nachahmt. Das linke Bild zeigt ein eingescanntes b-Vorzeichen +aus einer 2000 herausgegebenen Edition. Das mittlere Bild +zeigt das b-Vorzeichen derselben Musik aus einer handgestochenen +Bärenreiter-Ausgabe. Das linke Bild zeigt die typischen Makel +des Computer-Satzes: Die Notenlinien sind sehr dünn, die Schwärze +des Vorzeichens entspricht den dünnen Linien und hat eine gerade +Form mit scharfen Ecken und Kanten. Im Gegensatz dazu hat das +Bärenreiter-Vorzeichen dicke, geradezu sinnlich rundliche +Formen. Unser Symbol für das Vorzeichen hat neben anderen +auch dieses b als Vorbild. Es ist abgerundet und passt zu unseren +Notenlinien, die sehr viel dicker sind als die der entsprechenden +Computer-Ausgabe. + +@multitable @columnfractions .125 .25 .25 .25 .125 +@item @tab +@ifnotinfo +@iftex +@image{pictures/henle-flat-gray,,4cm} +@end iftex +@ifnottex +@image{pictures/henle-flat-gray,,,png} +@end ifnottex + +@tab +@iftex +@image{pictures/baer-flat-gray,,4cm} +@end iftex +@ifnottex +@image{pictures/baer-flat-gray,,,png} +@end ifnottex + +@tab +@iftex +@image{pictures/lily-flat-bw,,4cm} +@end iftex +@ifnottex +@image{pictures/lily-flat-bw,,,png} +@end ifnottex +@end ifnotinfo +@ifinfo +@image{pictures/henle-flat-bw,,,png} +@image{pictures/baer-flat-bw,,,,png} +@image{pictures/lily-flat-bw,,,png} +@end ifinfo + +@item @tab +Henle (2000) +@tab +Bärenreiter (1950) +@tab +LilyPond Feta-Schriftart (2003) + +@end multitable + + +@cindex Musiksymbole +@cindex Schriftart +@cindex Dichte +@cindex Balance + +@c introduce illustrating aspects of engraving, spacing... +Die Verteilung der Noten innerhalb des Taktes sollte ihrer Dauer +entsprechen. Moderne Partituren zeigen diese Verhältnisse jedoch +mit einer mathematischen Präzision, die nur sehr schlechte +Ergebnisse bringt. Im nächsten Beispiel ist ein Motiv zweimal +gesetzt: einmal mit den exakten mathematischen Längenverhältnissen, dann +mit kleinen Korrekturen. Welches von beiden ist mit dieser Korrektur +gesetzt? + +@cindex Optischer Ausgleich +@c file spacing-optical. +@c need to include it here, because we want two images. +@lilypond +\paper { + ragged-right = ##t + indent = #0.0 +} + +music = { + c'4 e''4 e'4 b'4 | + \stemDown + b'8[ e'' a' e''] + \stemNeutral + e'8[ e'8 e'8 e'8] +} + +\score +{ + \music + \layout { + \context { + \Staff + \override NoteSpacing #'stem-spacing-correction = #0.6 + } + } +} +@end lilypond + +@lilypond +\paper { + ragged-right = ##t + indent = #0.0 +} + +music = { + c'4 e''4 e'4 b'4 | + \stemDown + b'8[ e'' a' e''] + \stemNeutral + e'8[ e'8 e'8 e'8] +} +\score +{ + \music + \layout { + \context { + \Staff + \override NoteSpacing #'stem-spacing-correction = #0.0 + \override NoteSpacing #'same-direction-correction = #0.0 + \override StaffSpacing #'stem-spacing-correction = #0.0 + } + } +} +@end lilypond + +@cindex normale Rhythmen +@cindex normale Abstände +@cindex Abstände, normal +@cindex Rhythmen, normal + +In diesem Ausschnitt kommen nur Viertel vor, Noten, die in einem + gleichmäßigen Rhythmus gespielt werden. Die Abstände sollten das + widerspiegeln. Leider lässt uns aber das Auge im Stich: es beachtet + nicht nur den Abstand von aufeinander folgenden Notenköpfen, sondern + auch den ihrer Hälse. Also müssen Noten, deren Hälse in direkter + Folge zuerst nach oben und dann nach unten ausgerichtet sind, weiter + auseinander gezogen werden, während die unten/oben-Folge engere + Abstände fordert, und das alles auch noch in Abhängigkeit von der +vertikalen Position der Noten. Das obere Beispiel ist mit dieser +Korrektur gesetzt, das untere ohne. In letzterem Fall bilden sich +für das Auge bei unten/oben-Folgen Notenklumpen mit schmalen Abständen +zwischen den Notenhälsen. + +@cindex Typographie + +Musiker sind üblicherweise zu sehr damit beschäftigt, die Musik aufzuführen, +als dass sie das Aussehen der Noten studieren könnten; und diese +Beschäftigung mit typographischen Details mag akademisch wirken. +Das ist sie aber nicht. Unser Beispielstück hat einen +monotonen Rhythmus, und wenn alle Zeilen einförmig aussehen, wird +das Notenblatt zu einem Labyrinth. Wenn der Spieler auch nur +einmal wegschaut oder kurze Zeit unkonzentriert ist, findet er +nicht mehr zurück zu der Stelle, an der er war. + +Der dichtere Eindruck, den die dickeren Notenlinien und schwereren +Notationssymbole schaffen, eignet sich auch besser für Noten, +die weit vom Leser entfernt stehen, etwa auf einem Notenständer. +Eine sorgfältige Verteilung der Zwischenräume erlaubt es, die +Noten sehr dicht zu setzen, ohne dass die Symbole zusammenklumpen. +Dadurch werden unnötige Seitenumbrüche vermieden, so dass man +nicht so oft blättern muss. + +Dies sind die Anforderungen der Typographie: Das Layout sollte +schön sein -- nicht aus Selbstzweck, sondern um dem Leser zu helfen. Für +Aufführungsmaterial ist das umso wichtiger, denn Musiker haben eine begrenzte +Aufnahmefähigkeit. Je weniger Mühe nötig ist, die Noten zu erfassen, desto mehr +Zeit bleibt für die Gestaltung der eigentlichen Musik. Das heißt: Gute +Typographie führt zu besseren Aufführungen! + +Die Beispiele haben gezeigt, dass der Notensatz eine subtile und +komplexe Kunst ist und gute Ergebnisse nur mit viel Erfahrung +erlangt werden können, die Musiker normalerweise nicht haben. +LilyPond stellt unser Bemühen dar, die graphische Qualität +handgestochener Notenseiten ins Computer-Zeitalter zu transportieren +und sie für normale Musiker erreichbar zu machen. Wir haben +unsere Algorithmen, die Gestalt der Symbole und die Programm-Einstellungen +darauf abgestimmt, einen Ausdruck zu erzielen, der der Qualität +der alten Editionen entspricht, die wir so gerne betrachten +und aus denen wir gerne spielen. + + + +@node Automatisierter Notensatz +@unnumberedsubsec Automatisierter Notensatz +@translationof Automated engraving + +@cindex Notensatz, automatisch +@cindex automatischer Notensatz + +Wie sollen wir also jetzt die Typographie anwenden? +Wie können wir erwarten, dass wir in der Lage wären, +ein Programm zu schreiben, dass den Beruf des +Notenstechers ersetzt, wo dieser doch mehr als zehn +Jahre braucht, um ein Meister zu werden? + +Wir können es tatsächlich nicht! Da Typographie allein +durch das menschliche Auge bestimmt ist, kann der Mensch +nicht ersetzt werden. Aber sehr viel mechanische Arbeit +kann automatisiert werden. Indem etwa LilyPond die üblichen +Situationen kennt und bewältigt, können die restlichen +Fehler von Hand beseitigt werden. Das ist schon ein +großer Fortschritt im Vergleich zu den existierenden +Programmen. Und mit der Zeit können immer mehr Fälle +automatisiert werden, so dass immer weniger Eingriffe +von Hand notwendig werden. + + +Als wir anfingen, haben wir LilyPond vollständig in der Programmiersprache C++ +geschrieben. Das hieß, dass der Funktionsumfang des Programms vollständig durch +die Programmierer festgelegt war. Das stellte sich aus einer Reihe von Gründen +als unzureichend heraus: + +@itemize @bullet +@item Wenn LilyPond Fehler macht, muss der Benutzer die +Einstellungen ändern können. Er muss also Zugang zur +Formatierungsmaschinerie haben. Deshalb können die Regeln und +Einstellungen nicht beim Kompilieren des Programms festgelegt +werden, sondern sie müssen zugänglich sein, während das Programm +aktiv ist. + + +@item Notensatz ist eine Frage des Augenmaßes, und damit auch vom + Geschmack abhängig. Benutzer können mit unseren Entscheidungen +unzufrieden sein. Darum müssen also auch die Definitionen des +typographischen Stils dem Benutzer zugänglich sein. + +@item Schließlich verfeinern wir unseren Formatierungsalgorithmus +immer weiter, also müssen die Regeln auch flexibel sein. Die +Sprache C++ zwingt zu einer bestimmten Gruppierungsmethode, +die nicht den Regeln für den Notensatz entspricht. +@end itemize + +@cindex Scheme-Programmiersprache + +Diese Probleme wurden angegangen, indem ein Übersetzer für +die Programmiersprache Scheme integriert wurde und Teile +von LilyPond in Scheme neu geschrieben wurden. Die derzeitige +Formatierungsarchitektur ist um die Notation von graphischen +Objekten herum aufgebaut, die von Scheme-Variablen und -Funktionen +beschrieben werden. Diese Architektur umfasst Formatierungsregeln, +typographische Stile und individuelle Formatierungsentscheidungen. +Der Benutzer hat direkten Zugang zu den meisten dieser Einstellungen. + +Scheme-Variablen steuern Layout-Entscheidungen. Zum Beispiel haben +viele graphische Objekte eine Richtungsvariable, die zwischen +oben und unten (oder rechts und links) wählen kann. Hier etwa +sind zwei Akkorde mit Akzenten und Arpeggien. +Beim ersten Akkord sind alle Objekte nach unten (oder links) + ausgerichtet, beim zweiten nach oben (rechts). + +@lilypond[quote,ragged-right] +\new Score \with { + \override SpacingSpanner #'spacing-increment = #3 + \override TimeSignature #'transparent = ##t +} \relative c' { + \stemDown 4_>-\arpeggio + \override Arpeggio #'direction = #RIGHT + \stemUp 4^>-\arpeggio +} +@end lilypond + +@cindex Formatierung einer Partitur +@cindex Partitur, Formatierung +@cindex Formatierungsregeln + +@noindent +Der Prozess des Notensetzens besteht für das Programm darin, +die Variablen der graphischen Objekte zu lesen und zu +schreiben. Einige Variablen haben festgelegte Werte. So +ist etwa die Dicke von vielen Linien – ein Charakteristikum +des typographischen Stils – von vornherein festgelegt. +Wenn sie geändert werden, ergibt sich ein anderer typographischer Eindruck. + +@lilypond[quote,ragged-right] +fragment = { + \clef bass f8 as8 + c'4-~ c'16 as g f e16 g bes c' des'4 +} +<< + \new Staff \fragment + \new Staff \with { + \override Beam #'beam-thickness = #0.3 + \override Stem #'thickness = #0.5 + \override Bar #'thickness = #3.6 + \override Tie #'thickness = #2.2 + \override StaffSymbol #'thickness = #3.0 + \override Tie #'extra-offset = #'(0 . 0.3) + } + \fragment +>> +@end lilypond + +Formatierungsregeln sind auch vorbelegte Variablen. Zu jedem Objekt gehören +Variablen, die Prozeduren enthalten. Diese Prozeduren machen die eigentliche +Satzarbeit aus, und wenn man sie durch andere ersetzt, kann die Darstellung +von Objekten verändert werden. Im nächsten Beispiel wird die Regel, nach der +die Notenköpfe gezeichnet werden, während des Ausschnitts verändert. + +@lilypond[quote,ragged-right] +#(set-global-staff-size 30) + +#(define (mc-squared grob orig current) + (let* ((interfaces (ly:grob-interfaces grob)) + (pos (ly:grob-property grob 'staff-position))) + (if (memq 'note-head-interface interfaces) + (begin + (ly:grob-set-property! grob 'stencil + (grob-interpret-markup grob + (make-lower-markup 0.5 + (case pos + ((-5) "m") + ((-3) "c ") + ((-2) (make-smaller-markup (make-bold-markup "2"))) + (else "bla"))))))))) + +\new Voice \relative c' { + \stemUp + \set autoBeaming = ##f + \time 2/4 + 4 + \once \override NoteHead #'stencil = #note-head::brew-ez-stencil + \once \override NoteHead #'font-size = #-7 + \once \override NoteHead #'font-family = #'sans + \once \override NoteHead #'font-series = #'bold + 4 + \once \override NoteHead #'style = #'cross + 4 + \applyOutput #'Voice #mc-squared + 4 + << + { d8[ es-( fis^^ g] fis2-) } + \repeat unfold 5 { \applyOutput #'Voice #mc-squared s8 } + >> +} +@end lilypond + + + +@node Welche Symbole? +@unnumberedsubsec Welche Symbole? +@translationof What symbols to engrave? + +@cindex Notensatz +@cindex Typographie +@cindex Stempel +@cindex Matrize +@cindex Engraver +@cindex Plugin + +Während des Notensatzprozesses entscheidet sich, wo +Symbole platziert werden. Das kann aber nur gelingen, +wenn vorher entschieden wird, @emph{welche} Symbole +gesetzt werden sollen, also welche Art von Notation benutzt +werden soll. + +Die heutige Notation ist ein System zur Musikaufzeichnung, +das sich über die letzten 1000 Jahre entwickelt hat. Die +Form, die heute üblicherweise benutzt wird, stammt aus dem +Barock. Auch wenn sich die grundlegenden Formen (also +die Notenköpfe, das Fünfliniensystem) nicht verändert haben, +entwickeln sich die Details trotzdem immer noch weiter, um +die Errungenschaften der Neuen Musik darstellen zu können. Die +Notation umfasst also 500 Jahre Musikgeschichte. Ihre Anwendung +reicht von monophonen Melodien bis zu ungeheuer komplexem Kontrapunkt +für großes Orchester. + +Wie bekommen wir dieses vielköpfige Monster zu fassen? +Unsere Lösung ist es, eine strikte Trennung zwischen der Notation, +also welche Symbole benutzt werden, und dem Satz, also wohin sie +gesetzt werden, zu machen. Um das Problem anzupacken, haben wir +es in kleine (programmierbare) Happen zerteilt, so dass jede Art +von Symbol durch ein eigenes Plugin verarbeitet wird. Alle Plugins + kooperieren durch die LilyPond-Architektur. Sie sind vollständig +modular und unabhängig und können somit auch unabhängig voneinander + entwickelt werden. Der Schreiber, der die Musik in Graphik umwandelt, + ist ein Kopist oder Notenstecher (engl. engraver). Darum werden +die Plugins als @code{engraver} bezeichnet. + +Im nächsten Beispiel wird gezeigt, wie mit dem Plugin für die Notenköpfe, +dem @code{Note_heads_engraver} (@qq{Notenkopfstecher}) der Satz begonnen wird. + +@lilypond[quote,ragged-right] +\include "engraver-example.ily" + +\score { + \topVoice + \layout { + \context { + \Voice + \remove "Stem_engraver" + \remove "Phrasing_slur_engraver" + \remove "Slur_engraver" + \remove "Script_engraver" + \remove "Beam_engraver" + \remove "Auto_beam_engraver" + } + \context { + \Staff + \remove "Accidental_engraver" + \remove "Key_engraver" + \remove "Clef_engraver" + \remove "Bar_engraver" + \remove "Time_signature_engraver" + \remove "Staff_symbol_engraver" + \consists "Pitch_squash_engraver" + } + } +} +@end lilypond + +@noindent +Dann fügt ein @code{Staff_symbol_engraver} (@qq{Notensystemstecher}) +die Notenlinien hinzu. + +@lilypond[quote,ragged-right] +\include "engraver-example.ily" + +\score { + \topVoice + \layout { + \context { + \Voice + \remove "Stem_engraver" + \remove "Phrasing_slur_engraver" + \remove "Slur_engraver" + \remove "Script_engraver" + \remove "Beam_engraver" + \remove "Auto_beam_engraver" + } + \context { + \Staff + \remove "Accidental_engraver" + \remove "Key_engraver" + \remove "Clef_engraver" + \remove "Bar_engraver" + \consists "Pitch_squash_engraver" + \remove "Time_signature_engraver" + } + } +} +@end lilypond + +@noindent +Der @code{Clef_engraver} (@qq{Notenschlüsselstecher}) definiert +eine Referenzstelle für das System. + +@lilypond[quote,ragged-right] +\include "engraver-example.ily" + +\score { + \topVoice + \layout { + \context { + \Voice + \remove "Stem_engraver" + \remove "Phrasing_slur_engraver" + \remove "Slur_engraver" + \remove "Script_engraver" + \remove "Beam_engraver" + \remove "Auto_beam_engraver" + } + \context { + \Staff + \remove "Accidental_engraver" + \remove "Key_engraver" + \remove "Bar_engraver" + \remove "Time_signature_engraver" + } + } +} +@end lilypond + +@noindent +Der @code{Stem_engraver} (@qq{Halsstecher}) schließlich fügt + Hälse hinzu. + +@lilypond[quote,ragged-right] +\include "engraver-example.ily" + +\score { + \topVoice + \layout { + \context { + \Voice + \remove "Phrasing_slur_engraver" + \remove "Slur_engraver" + \remove "Script_engraver" + \remove "Beam_engraver" + \remove "Auto_beam_engraver" + } + \context { + \Staff + \remove "Accidental_engraver" + \remove "Key_engraver" + \remove "Bar_engraver" + \remove "Time_signature_engraver" + } + } +} +@end lilypond + +@noindent +Dem @code{Stem_engraver} wird jeder Notenkopf mitgeteilt, +der vorkommt. Jedes Mal, wenn ein Notenkopf erscheint (oder mehrere bei +einem Akkord), wird ein Hals-Objekt erstellt und an den +Kopf geheftet. Wenn wir dann noch engraver für Balken, Bögen, +Akzente, Vorzeichen, Taktlinien, Taktangaben und Tonartbezeichnungen +hinzufügen, erhalten wir eine vollständige Notation. + + +@lilypond[quote,ragged-right] +\include "engraver-example.ily" +\score { \topVoice } +@end lilypond + +@cindex Polyphonie +@cindex Mehrstimmigkeit +@cindex Notensatz, Mehrstimmigkeit +@cindex Kontexte + +Dieses System funktioniert gut für monophone Musik, aber wie geht +es mit Polyphonie? Hier müssen sich mehrere Stimmen ein System teilen. + +@lilypond[quote,ragged-right] +\include "engraver-example.ily" +\new Staff << \topVoice \\ \botVoice >> +@end lilypond + +In diesem Fall benutzen beide Stimmen das System und die Vorzeichen gemeinsam, +aber die +Hälse, Bögen, Balken usw. sind jeder einzelnen Stimme eigen. Die engraver +müssen also gruppiert werden. Die Köpfe, Hälse, Bögen usw. werden +in einer Gruppe mit dem Namen @qq{Voice context} (Stimmenkontext) +zusammengefasst, die engraver für den Schlüssel, die Vorzeichen, +Taktstriche usw. dagegen in einer Gruppe mit dem Namen @qq{Staff context} +(Systemkontext). Im Falle von Polyphonie hat ein Staff-Kontext dann also +mehr als nur einen Voice-Kontext. Auf gleiche Weise können auch mehrere Staff-Kontexte +in einen großen Score-Kontext (Partiturkontext) eingebunden werden. + + +@seealso +Programmreferenz: @rinternals{Contexts}. + + +@lilypond[quote,ragged-right] +\include "engraver-example.ily" +\score { + << + \new Staff << \topVoice \\ \botVoice >> + \new Staff << \pah \\ \hoom >> + >> +} +@end lilypond + +@node Die Darstellung der Musik +@unnumberedsubsec Die Darstellung der Musik +@translationof Music representation + +@cindex Syntax +@cindex rekursive Strukturen + +Idealerweise ist das Eingabeformat für ein komplexes Satzsystem die +abstrakte Beschreibung des Inhaltes. In diesem Fall wäre das die +Musik selber. Das stellt uns aber vor ein ziemlich großes Problem, +denn wie können wir definieren, was Musik wirklich ist? Anstatt darauf +eine Antwort zu suchen, haben wir die Frage einfach umgedreht. Wir +schreiben ein Programm, das den Notensatz beherrscht und machen das +Format so einfach wie möglich. Wenn es nicht mehr vereinfacht +werden kann, haben wir per Definition nur noch den reinen Inhalt. Unser +Format dient als die formale Definition eines Musiktextes. + +Die Syntax ist gleichzeitig die Benutzerschnittstelle bei LilyPond, +darum soll sie einfach zu schreiben sein; z. B. bedeutet + +@example +c'4 d'8 +@end example + +@noindent +eine Viertel c' und eine Achtel d', wie in diesem Beispiel: + +@lilypond[quote] +{ + c'4 d'8 +} +@end lilypond + +In kleinem Rahmen ist diese Syntax sehr einfach zu benutzen. In +größeren Zusammenhängen aber brauchen wir Struktur. Wie sonst kann +man große Opern oder Symphonien notieren? Diese Struktur wird +gewährleistet durch sog. music expressions (Musikausdrücke): indem +kleine Teile zu größeren kombiniert werden, kann komplexere Musik +dargestellt werden. So etwa hier: + +@lilypond[quote,verbatim,fragment,relative=1] +f4 +@end lilypond + +@noindent +Gleichzeitig erklingende Noten werden hinzugefügt, indem man alle in @code{<<} und @code{>>} einschließt. + +@c < > is not a music expression, +@c so we use <<>> iso. <> to drive home the point of +@c expressions. Don't change this back --hwn. +@example +<> +@end example + +@lilypond[quote,fragment,relative=1] +\new Voice { <> } +@end lilypond + +@noindent +Um aufeinanderfolgende Noten darzustellen, werden sie in geschweifte Klammern gefasst: + +@code{@{@tie{}@dots{}@tie{}@}} + +@example +@{ f4 <> @} +@end example + +@lilypond[quote,relative=1,fragment] +{ f4 <> } +@end lilypond + +@noindent +Dieses Gebilde ist in sich wieder ein Ausdruck, und kann +daher mit einem anderen Ausdruck kombiniert werden (hier mit einer Halben). + +@example +<< g2 \\ @{ f4 <> @} >> +@end example + +@lilypond[quote,fragment,relative=2] +\new Voice { << g2 \\ { f4 <> } >> } +@end lilypond + +Solche geschachtelten Strukturen können sehr gut in einer +kontextunabhängigen Grammatik beschrieben werden. Der Programmcode +für den Satz ist auch mit solch einer Grammatik erstellt. Die Syntax +von LilyPond ist also klar und ohne Zweideutigkeiten definiert. + +Die Benutzerschnittstelle und die Syntax werden als erstes vom Benutzer +wahrgenommen. Teilweise sind sie eine Frage des Geschmackes und werden viel +diskutiert. Auch wenn Geschmacksfragen ihre Berechtigung +haben, sind sie nicht sehr produktiv. Im großen Rahmen von LilyPond +spielt die Eingabe-Syntax nur eine geringe Rolle, denn eine logische +Syntax zu schreiben ist einfach, guten Formatierungscode aber sehr viel +schwieriger. Das kann auch die Zeilenzahl der Programmzeilen zeigen: +Analysieren und Darstellen nimmt nur etwa 10% des Codes ein: + +@node Beispielanwendung +@unnumberedsubsec Beispielanwendung +@translationof Example applications + +@cindex einfaches Beispiel +@cindex Beispiel, einfach + +Wir haben LilyPond als einen Versuch geschrieben, wie man die Kunst des +Musiksatzes in ein Computerprogramm gießen kann. Dieses +Programm kann nun dank vieler harter Arbeitsstunden benutzt werden, +um sinnvolle Aufgaben zu erledigen. Die einfachste ist dabei der +Notendruck. + +@lilypond[quote,relative=1] +{ + \time 2/4 + c4 c g'4 g a4 a g2 +} +@end lilypond + +@noindent +Indem wir Akkordsymbole und einen Text hinzufügen, erhalten wir +ein Lead Sheet. + +@lilypond[quote,ragged-right] +<< + \chords { c2 c f2 c } + \new Staff + \relative c' { + \time 2/4 + c4 c g' g a a g2 + } + \addlyrics { twin -- kle twin -- kle lit -- tle star } +>> +@end lilypond + +Mehrstimmige Notation und Klaviermusik kann auch gesetzt werden. Das +nächste Beispiel zeigt einige etwas exotischere Konstruktionen: + +@lilypond[quote] +\header { + title = "Screech and boink" + subtitle = "Random complex notation" + composer = "Han-Wen Nienhuys" +} + +\score { + \context PianoStaff << + \new Staff = "up" { + \time 4/8 + \key c \minor + << { + \revert Stem #'direction + \change Staff = down + \set subdivideBeams = ##t + g16.[ + \change Staff = up + c'''32 + \change Staff = down + g32 + \change Staff = up + c'''32 + \change Staff = down + g16] + \change Staff = up + \stemUp + \set followVoice = ##t + c'''32([ b''16 a''16 gis''16 g''32)] + } \\ { + s4 \times 2/3 { d'16[ f' g'] } as'32[ b''32 e'' d''] + } \\ { + s4 \autoBeamOff d''8.. f''32 + } \\ { + s4 es''4 + } >> + } + + \new Staff = "down" { + \clef bass + \key c \minor + \set subdivideBeams = ##f + \override Stem #'french-beaming = ##t + \override Beam #'beam-thickness = #0.3 + \override Stem #'thickness = #4.0 + g'16[ b16 fis16 g16] + << \makeClusters { + as16 + + + } \\ { + \override Staff.Arpeggio #'arpeggio-direction =#down + 4\arpeggio + } + >> } + >> + \midi { + \context { + \Score + tempoWholesPerMinute = #(ly:make-moment 60 8) + } + } + \layout { + \context { + \Staff + \consists Horizontal_bracket_engraver + } + } +} +@end lilypond + +Die obenstehenden Beispiele wurde manuell erstellt, aber das ist nicht +die einzige Möglichkeit. Da der Satz fast vollständig automatisch abläuft, +kann er auch von anderen Programmen angesteuert werden, die Musik oder Noten +verarbeiten. So können etwa ganze Datenbanken musikalischer Fragmente automatisch +in Notenbilder umgewandelt werden, die dann auf Internetseiten oder +in Multimediapräsentation Anwendung finden. + +Dieses Benutzerhandbuch zeigt eine weitere Möglichkeit: Die Noten werden als +reiner Text eingegeben und können darum sehr einfach integriert werden +in andere textbasierte Formate wie etwa @LaTeX{}, HTML oder, wie in diesem +Fall, Texinfo. Durch ein spezielles Programm werden die Eingabefragmente durch +Notenbilder in der resultierenden PDF- oder HTML-Datei ersetzt. Dadurch ist +es sehr einfach, Noten und Text zu kombinieren. + diff --git a/Documentation/de/essay/literature.itely b/Documentation/de/essay/literature.itely index 4fdbd4f4f4..65a70f4f61 100644 --- a/Documentation/de/essay/literature.itely +++ b/Documentation/de/essay/literature.itely @@ -1,7 +1,7 @@ @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. @@ -13,7 +13,7 @@ @node Literatur -@appendix Literatur +@chapter Literatur @translationof Literature list Wenn Sie mehr über Notation und den Notenstich erfahren wollen, sind diff --git a/Documentation/de/index.html.in b/Documentation/de/index.html.in index 660fb1c0ba..7798a1c82e 100644 --- a/Documentation/de/index.html.in +++ b/Documentation/de/index.html.in @@ -1,6 +1,6 @@