Notenschreiben mit LilyPond
Für die Seiten Harmoniemodelle und Passemezzo antico habe ich die meisten Notenbeispiele mit der freien Software LilyPond erstellt. Auf den weiteren Seiten zur Improvisation über harmonische Modelle aus Renaissance und Barock bin ich dann zu meiner gewohnten Software Capella zurückgekehrt. Hier möchte ich meine Erfahrungen mit LilyPond beschreiben.
Dies ist ein sehr subjektiver Bericht: Was ich als problematisch an LilyPond sehe, ist immer in erster Linie mein Problem, nur vielleicht tatsächlich ein Problem des Programmes. Trotzdem möchte ich einen Eindruck davon vermitteln, was einen beim Einstieg in LilyPond erwartet, damit man nicht sofort wieder aufgibt - als Newbie ist es nicht so einfach.
Im Folgenden geht es um
- Gründe für die Arbeit mit LilyPond,
- den Vergleich zwischen konventionellen Notenschreibprogrammen und LilyPond,
- die Komplexität von Noten schreiben an sich,
- das Erlernen der Bedienung von LilyPond,
- weitere Konzepte von LilyPond,
- die Benutzerfreundlichkeit der Hilfedateien und Anleitungen,
- allgemeine Probleme bei Noten für Gitarre,
- Möglichkeiten einfacherer Bedienung von LilyPond und
- eine Zusammenfassung.
Gründe, mit LilyPond zu arbeiten
Die wichtigsten Gründe, die einen zur Nutzung von Lilypond motivieren könnten sind:
- Das Notenbild ist schöner als das anderer Programme,
- es handelt sich um freie Software, und
- man hat mehr Kontolle über das Endprodukt.
Was die Schönheit des erzeugten Notenbildes angeht, ist die Argumentationskette im Wesentlichen folgende: traditioneller Notenstich, wie er im Beispielartikel durch eine Ausgabe der Violoncellosuiten Bachs aus dem Bärenreiter-Verlag von 1950 repräsentiert wird, zeigt deutlichere, schwungvollere Noten und im Gesamtbild weniger regelmäßige Aufteilungen zum Beispiel bei den Taktlängen. Das Bild ist individueller, regt damit die Aufmerksamkeit an und ist somit nicht nur ästhetischer, sondern auch besser zu lesen.
Beim Notenbild, das mit einem der bekannten Computerprogramme erstellt wurde, sind viele Dinge dünner geraten, und die Taktstriche des Präludiums landen alle ziemlich genau in der Mitte des Blattes, sehen also etwas kühl und gleichförmig aus. Das ist auch der Fall, wenn man das Stück im Satz mit Capella betrachtet.
Der Vorteil freier Software liegt auf der Hand: es kümmern sich Leute darum, die motiviert sind, das Produkt stetig zu verbessern und sicher zu halten, und man muss nichts dafür zahlen.
Den Aspekt "Kontrolle", oder die Palette dessen, was Lilypond kann, kann man hier bewundern: es sieht so aus, als gäbe es nichts, was nicht machbar wäre. Und wenn man etwas braucht, was es noch nicht gibt, kann man es selber erstellen, da der Code quelloffen ist.
GUI-Anwendungen verglichen mit LilyPond
Während Capella eine typische GUI - Anwendung ist, also ein Programm, mit dem der Nutzer mittels der graphischen Benutzeroberfläche ("graphical user interface") interagiert, wird LilyPond so beschrieben:
... In einer bestimmten Beziehung ist LilyPond eher eine Programm[ier]sprache als ein
graphisches Notensatzprogramm.
Man schreibt die Noten nicht, indem man Notensymbole von
einer graphischen Leiste zieht und auf einem sich dynamisch immer wieder erneuernden
Notensystem platziert. Anstatt dessen schreibt man Text. Dieser Text wird von LilyPond
interpretiert (oder „kompiliert“) und dabei schön aussehender Notensatz produziert.
Das ist wirklich ein radikal anderes Konzept, als das konventioneller Notenschreibprogramme wie Sibelius, Finale oder kleinerer Mitbewerber wie Capella, allerdings bieten diese doch wesentlich mehr Möglichkeiten als die, Symbole von einer Leiste auszuwählen.
Menü oder Markup
Die hier als "konventionell" bezeichneten Notenschreibprogramme sind menügesteuert. Ähnlich wie in Schreibprogrammen wird ein Teil des Textes ausgewählt, und auf das Ausgewählte wird ein Menübefehl angewendet. Was auch immer vor und hinter der markierten Stelle ist, bleibt von dem Befehl unbehelligt.
Wenn ich den Container für das Bild nicht schließe, gibt es ein schönes Durcheinander auf dieser Seite.
Das ist grundsätzlich anders in einer "markup language" oder "Auszeichnungssprache".
Ein gutes Beispiel dafür ist das hier verwendete HTML. Um einem
ausgewählten Textabschnitt eine bestimmte Formatierung zuzuweisen, muss ich ein
"tag" (= Schild, Anhänger, Etikett) davor setzen, und fast immer auch ein schließendes
"tag" dahinter platzieren.
Damit die Abkürzung HTML so aussieht,
wie sie hier aussieht, schreibe ich <span class="code"> davor
und das schließende </span> dahinter. Die
CSS-Datei meiner Seite sorgt dann für das gewünschte Aussehen.
Vergesse ich, das closing tag zu setzen, wird auch der folgende Text
im geänderten Schriftstil formatiert. Mache ich gravierende Fehler, fällt die Seite komplett
auseinander.
Im Fall eines GUI-Programmes wende ich vorformulierte Befehle auf etwas an, im Falle einer Markup-Anwendung setze ich die Befehle händisch in den Text ein.
Nach dem zweiten Prinzip funktioniert LilyPond. Es gibt Voreinstellungen, die dafür sorgen, dass die Noten grundsätzlich vernünftig aussehen, aber alles, was man irgendwie anders haben möchte, muss man in tags einschließen oder mit bestimmten Befehlen anordnen, die man in der Regel widerrufen muss, wenn wieder ein anderes Aussehen gewünscht wird.
Für alles, was man über die Grundausstattung hinaus haben möchte - Fingersätze, Akkordbuchstaben, Crescendo-Zeichen - muss man die entsprechenden Befehle finden und sich merken. Nichts steht oben in einer Menüleiste. Und man wird sich viele Dinge merken oder irgendwo speichern wollen, weil Noten schreiben als Darstellungsform von Musik die Komplexität und Genauigkeit seiner Beschreibung anders erzeugt, als dies bei Texten mit den Buchstaben eines Alphabets gemacht wird.
Noten schreiben hat viele Strukturebenen
Bestandteile einer Partitur
Ein Musikstück hat Sätze, die sich in Abschnitte einteilen lassen, Überschriften, Dynamik und Agogik-Anweisungen, unterschiedliche Instrumente in verschiedenen Schlüsseln, eventuell transponierend, in Gruppen zusammengefasst... wenn man ein Programm für das Notieren von Musik entwerfen möchte, muss man schon weit ausholen.
Strukturbaum einer Note in Capella
Im Programm Capella kann man sich im Menü Ansicht den Strukturbaum einer Partitur anschauen. Ein Beispiel habe ich hier per Screenshot sichtbar gemacht um anzudeuten, was alles mit einer Note verbunden ist.
1: Über allem steht "score", und darunter zunächst mal Infos zum Dateiformat und der verwendeten Programmversion.
Bei Ziffer 2 beginnt die Abteilung "layout", mit Papiergröße und Seitenrändern. Unter 3 sind die Größen der Notenzeilen, unter 4 die Abstände der Systeme geregelt. Bei 5 ist angezeigt, in welcher Schriftart und -größe Instrumentennamen vor den Notenzeilen geschrieben werden.
Bei Punkt 6 sind die Eigenschaften der Notenlinien gelistet, Schlüssel, ob Taktstriche zwischen Systemen durchgezogen werden oder nicht, zusätzliche Abstände über und unter jeder Notenzeile, Instrumentenname und -abkürzung, Midieinstellungen.
Punkt 7 zeigt den horizontalen Platzbedarf von Noten und die Balkensteigung - auch das kann man einstellen.
Bei Ziffer 8 beginnen die Einstellungen zu "systems". Zunächst wird festgelegt, dass das eingestellte Tempo MM = 120 ist, und dass Namen der Instrumente lang ausgeschrieben werden.
9 gibt an, dass dieses Layout "unbenannt1" heißt, und dass 4/4-Takt eingestellt ist.
Dann beginnen bei 10 die Eigenschaften eines möglichen Liedtextes, Schriftart und -größe, Abstand von der Notenzeile und Abstände zwischen Strophenzeilen, bei 11 werden den Noten nochmals bestimmte Werte zugeordnet, und bei 12 wird es langsam spannend: es gibt einen Akkord (ein Ton ist ein Akkord), der eine Viertelnote dauert, aber keine Dauer hat, weil ich die Note als Vorhalt (klein und ohne Wert) formatiert habe.
Der Akkord hat also (13) bei small den Wert
true und ist außerdem um "-2" auf der x-Achse verschoben. Diese
Verschiebung wird genutzt, um zusammenstoßende Notenköpfe zu trennen.
Bei
14 steht, dass als Artikulation "staccato" eingetragen ist.
Unter 15 ist der Liedtext (dessen Einstellungen bei 10 angegeben sind, z.B. dass er über den Noten steht) "Hu!" zu sehen, und bei 16 beginnen die gezeichneten Objekte.
Dabei handelt es sich zunächst um einen Textfeld, das an bestimmten Koordinaten liegt, eine
Schriftart und -größe hat, und als Inhalt (16) "Struktur!".
Bei
(17) ist das zweite Objekt beschrieben: ein Crescendo-Keil mit
genauen Koordinaten und Linienstärke.
Schließlich bei 18 - tadaa: die Note, um die es geht heißt "G5", und sie hat eine besondere Kopfform: shape="crossDiamond"! - Das ist also die Essenz des ganzen Theaters!
All diese Eigenschaften finden sich in der Menüstruktur von Capella wieder, und das hier sind nur die Grundlagen. Grafiken, Zeichenelemente und über Plugins steuerbare Sondertricks kommen noch dazu.
Übersicht in der Hilfe zu Capella
In der Hilfe zu Capella wird folgende Übersicht gegeben:
- Eine Partitur besteht aus einem oder mehreren Systemen, die automatisch auf Seiten aufgeteilt werden.
- Ein System besteht aus einer oder mehreren Notenzeilen.
- Eine Notenzeile besteht aus einer oder mehreren unabhängigen Stimmen.
- Eine Stimme ist eine Aufreihung von Notenobjekten (u. a. Akkorde, Pausen, Vorzeichnungen, feste Taktstriche).
- Ein Akkord besteht aus einer oder mehreren Noten.
- An jeden Akkord und jede Pause kann ein (oder mehrere) Grafikobjekt des in capella integrierten Zeichenprogramms gehängt werden, das sich bei Änderungen der Partitur mit dem Akkord (bzw. der Pause) mitbewegt.
- Die Notenzeilen aller Systeme werden aus einem gemeinsamen Mustersystem entnommen.
Den Umgang mit diesem komplexen System muss man lernen. Man muss lernen, wo man was einstellt und kämpft sich durch das Handbuch. Man hat aber dabei immer die Erleichterung, dass man die Menüs durchscrollen und so die Suche eingrenzen kann.
In Menüs steht neben Befehlen - wenn vorhanden - eine Tastenkombination, und so merkt man sich
zunehmend häufig gebrauchte Shortcuts wie zum Beispiel strg+shift+h um
zusätzlichen Zeilenabstand hinzuzufügen, was man bei Gitarrennoten häufig braucht, oder
shift+/, was den vorherigen Akkord wiederholt, oder
"<" bzw. ">", die dafür sorgen, dass
der folgende Akkord zum nächsten Wert vergrößert bzw. verkleinert wird. So hat man nach einiger
Zeit das Gefühl, schnell und sicher mit dem Programm arbeiten zu können.
Außerdem ist
Capella im Vergleich zu anderen Notenschreibprogrammen etwas an Schreibprogramme angelehnt.
Während viele Programme, die ich mir angeschaut habe, beim Start eine Zeile mit vier Takten oder
eine ganze Seite mit Zeilen mit je vier Takten vorgeben, und sich dies wenn überhaupt nur mit
großer Überredungskunst ändern lässt, startet man bei Capella beim ersten Ton, die Zeile wird
zunehmend länger, und mit der enter - Taste beginnt man eine neue
Zeile, wie man es von Texten gewohnt ist.
Sich in LilyPond einarbeiten
Die Arbeit mit LilyPond beginnt damit, dass man eine Textdatei erstellt, die man mit der Endung *.ly abspeichert.
Einen Text-Editor benutzen
Um mit LilyPond Noten zu schreiben, braucht man also einen Text - Editor, und danach die Möglichkeit, den Befehl zum Kompilieren auszuführen.
Als Editor benutzte ich, als ich dies schrieb Atom, den man mit
"Packages" erweitern kann, und für die Arbeit mit LilyPond habe ich erstens
AtLilyPond installiert, ein Package, dass die
Syntax unterschiedlich einfärbt (syntax highlighter), und dann
Lilycompile von A. Meyer, das es erlaubt, per
Tastenkombination direkt in Atom in einem seperaten Tab eine kompilierte Version der
geschriebenen Noten zu bekommen - oder eine Fehlermeldung.
Man lädt also LilyPond
herunter, installiert, und fängt an, indem man die Handbücher durcharbeitet und den Anweisungen
folgt.
Handbücher und Hilfedateien
Beim Versuch, die Handhabung von LilyPond zu erlernen habe ich - das sei mal vorausgeschickt - mich permanent als zu begriffsstutzig, vergesslich und unfähig, Neues zu lernen erlebt. Der Anfang ist einfach genug. Im Prinzip schreibt man:
- Das hier eine LilyPond-Datei,
- hier beginnt eine Partitur,
- hier beginnt ein Notensystem,
- c d e f g,
- hier endet das Notensystem,
- hier endet die Partitur,
- hier endet die LilyPond-Datei,
Man muss alle Systemebenen, die eine Partitur enthält in bestimmte Klammern oder tags einschließen wie bei einer html - Datei. Man muss explizit sagen, dass eine Note in einer Stimme enthalten ist, die in einer Zeile enthalten ist, die in einer Akkolade enthalten ist, die in einer Partitur enthalten ist usw.
Nach dem Kompilieren hat man die Noten "c d e f g" geschrieben. Aber je tiefer man in die Materie eindringt, desto mehr Dinge muss man sich merken. Man kann natürlich Vorlagen benutzen und Dinge kopieren, die bereits funktioniert haben, aber ohne sich einzuarbeiten kommt man nicht weit.
Man klickt zuerst auf der Seite Handbücher,
auf der tatsächlich ein Dutzend Dokumente verlinkt sind, die in "Einleitung", "Regelmäßig
benötigt" und "Seltener benötigt" eingeteilt sind, auf
Texteingabe, um dort gesagt zu bekommen,
dass man bitte sehr die
Einführung
lesen soll. Hier muss man sich zunächst mal an die quasi wissenschaftliche Ästhetik der Seite
gewöhnen, die manchmal fast ausschließlich aus weiterführenden Links besteht.
Nach dem
Klick auf "Grundbegriffe" wechselt die Sprache auf Englisch, was man aber unten in der
Sprachleiste wieder ändern kann, und nach zwei weiteren
Klicks
sieht man die russischen Puppen, die verschachtelten Ebenen, in denen die Noten verpackt sind.
Strukturebenen in LilyPond
Jede Ebene, die geöffnet wird, muss geschlossen werden, und das passiert nicht von alleine. Man muss behalten, wie welche Ebene heißt, was mit einem kleinen und was mit einem großen Buchstaben zu beginnen hat, und welche Begriffe zusammen, aber mit einem oder mehreren internen Großbuchstaben, wie zum Beispiel \autoBeamOff geschrieben werden. Die schiere Menge an zu verdauendem Lerninhalt kann jemanden, bei dem Schule und Studium schon einen Moment her sind ganz schön zur Verzweiflung bringen, denn der kleinste Fehler, selbst eine vergessene Leertaste, kann das erfolgreiche Kompilieren verhindern.
Klammern für den Zusammenhalt
Gleichzeitige Ereignisse
In LilyPond gibt es viele Ebenen und viele Arten von Verschachtelung, die mit unterschiedlichen Klammern eingefasst werden. Außer in den geschweiften Klammern {...} werden simultan stattfindende Dinge in diesen Klammern <<...>> eingefasst.
Nach der Zeile \score mit der sich öffnenden geschweiften Klammer öffnen sich die ersten spitzen Klammern, die Gesang und Klavier zusammenfassen. Hinter \new Staff = "singer" öffnen sich die zweiten, dann folgt der Inhalt an Noten samt Text für "singer", diese Ebene spitzer Klammern wird geschlossen, dann folgt \new PianoStaff = "piano", worauf sich wieder spitze Klammern öffnen, die nach den zwei "Inhaltszeilen" geschlossen werden, und dann werden die nach der ersten Zeile geöffneten spitzen Klammern geschlossen, und schließlich die geschweifte Klammer der ersten Zeile.
Sobald man beginnt, ein Stück zu schreiben, muss man entscheiden, wie viele Takte man in einer Zeile der Textdatei unterbringen will. Schreibt man einen Takt pro Zeile, wird die Datei deutlich länger als in Noten, vor allem, wenn man sich 64 Takte für vier Stimmen vorstellt! Eine Textdatei, die keinen textlichen Inhalt, sondern Buchstaben, Ziffern und Markup-Befehle enthält, ist nicht wirklich augenfreundlich.
Die erste Stimme des dritten Teils von Terzis Passemezzo antico als Beispiel. Der Eintrag "%4" am Zeilenende ist meine Notiz für "hier endet Takt 4" (Das Prozentzeichen ist das Zeichen für einen Kommentar, der beim Kompilieren der Noten nicht berücksichtigt wird.). In den ersten Zeilen steht immer nur ein Takt, ich bin aber darin nicht konsequent geblieben.
Akkorde
Akkorde schreibt man mit einfachen spitzen Klammern <...>. Am Anfang des Beispiels steht eine Viertelpause ("r" = rest, die "4" bedeutet Viertelnote oder -pause), der folgende Dreiklang behält den rhythmischen Wert bei, nach dem F-dur-Quartsextakkord steht eine "2", damit er den Wert einer Halben bekommt.
Während diese drei ersten "Arten" von Klammern Dinge "umschließen", und deshalb in genau der
richtigen Reihenfolge wieder geschlossen werden müssen, zeigen die folgenden Arten von Klammern
lediglich an, wo etwas beginnt und endet. Sie werden einfach dort geschlossen, wo der Vorgang
abgeschlossen ist.
Es gibt also zwei verschiedene
Grundkonzepte
von Klammern.
Bindungen, Phrasierungsbögen, Balken
Weitere Anwendungen von Klammern: Runde Klammern (...) werden benutzt, um Bindungen zu zeichnen. Die öffnende Klammer steht direkt nach einer Note, dann folgt eine Leertaste, und die schließende Klammer folgt direkt auf die letzte Note, ebenfalls zwingend gefolgt von einer Leertaste.
Bei Phrasierungsbögen, im Bild gemeinsam mit Bindungen zu sehen, muss vor die öffnenden und schließenden runden Klammern ein Backslash gesetzt werden. Haltebögen oder Ligaturen werden erstellt, indem man einfach eine Tilde an einen Tonbuchstaben anhängt. Dass Ligaturen, Bindungen (die in Gitarrennoten Aufschläge beziehungsweise Abzüge bedeuten) und Phrasierungsbögen nicht dasselbe sind, sollte man als Musiker wissen, wie sie in Lilypond erzeugt werden, muss man sich merken.
Möchte man die automatische Balkensetzung umgestalten, muss man sich der eckigen Klammern [...] bedienen, die genauso wie die runden Klammern gesetzt werden.
Bei GUI-Notenschreibprogrammen steckt der gleiche Aufwand hinter dem Resultat, nur liegt er nicht in der Verantwortung des Endbenutzers, sondern wird von den Programmierern der Anwendung erledigt. Man muss auch bei Capella erst lernen, wie man Bindungen herstellt, findet sie dann aber in der Gedächtnisstütze "Menü" schnell wieder.
Weitere Konzepte bei LilyPond
Nachdem jetzt geklärt wurde, dass verschieden gestaltete Klammern dafür sorgen, dass die Datei funktioniert, möchte ich weitere grundsätzliche Konzepte von LilyPond vorstellen. Darunter sind Ideen, die spontan als einfach und genial einleuchten, und andere Dinge, die schwieriger zu beherrschen sind.
Relative oder absolute Notation
Man kann in Lilypond Noten absolut oder relativ zu einer vorher angegebenen Tonhöhe eingeben.
Im Beispiel sieht man oben den Text zum Beginn der Melodie von Mozarts A-Dur Klaviersonate in absoluter Notierung. Das erste cis'' wird tatsächlich mit zwei Apostrophen geschrieben, man braucht also viele Apostrophe oder Kommata bei hohen und tiefen Noten.
Unter den Noten steht der Text zur relativen Notierung: \relative c'' bedeutet, dass die Tonbuchstaben relativ zu c'' zu interpretieren sind. Die Apostrophe bei jeder einzelnen Note spart man sich so.
Bei Capella fungieren die Tasten F1 - F4 als Shortcut für die
Oktavbereiche. Wenn man Noten auf der Computertastatur schreibt, muss man hier zwischen
h' und c'' am Beginn des zweiten Taktes ständig
umschalten. Aber das harte Leben wird einem auch erleichtert: Fehler sind schnell korrigiert,
indem man den Cursor vor eine falsche Note setzt, die Taste "o" hält
und dazu Bild aufwärts drückt. Schon ist der Ton oktaviert.
Hat
man den Luxus eines Midi-Keyboards zur Verfügung, braucht man sich über solche Dinge nur
Gedanken zu machen, wenn man den Umfang der Tastatur überschreitet.
In LilyPond ist der
workflow vor allem bei relativer Notation sehr flüssig - bei kleinen Intervallen
muss man gar nichts tun, bei größeren Sprüngen hängt man einen Apostroph oder ein Komma an,
fertig.
Notenfolge
Grundsätzlich nimmt Lilypond bei relativer Notierung an, dass jede folgende Note möglichst nahe an der vorherigen liegt. Schreibe ich f c, erhalte ich eine Quarte abwärts, weil das tiefere c ja näher am Ausgangston liegt. Möchte ich statt dessen eine Quinte aufwärts als Ergebnis, muss ich f c' tippen. Die Septime abwärts von f nach g muss ich so schreiben: f g,. Das ist lernbar, erfordert aber ständige Aufmerksamkeit, nicht zuletzt bei Akkorden.
Beim Transponieren muss man aufpassen. Die Übergänge von einer Oktave in die nächste können verschoben werden, und plötzlich tauchen kuriose Oktavverschiebungen auf. Das Beispiel zeigt die ersten acht Takte des Passemezzo von Bianchini, nachdem ich in Frescobaldi den Befehl "Alles um einen Ganzton nach oben" eingegeben hatte. So darf man das offenbar nicht machen! (Die Mididatei zu diesem Beispiel klang großartig!)
Sprachwahl
Am Anfang jeder LilyPond-Datei muss man angeben, in welcher
Sprache
man die Noten eingeben möchte. Die Default-Einstellung ist holländisch, dabei schreibt man die
Noten c, cis, ces, aber leider heißt unser
h auf holländisch b (glückliche Nachbarn!). Das
war mir zu gewöhnungsbedürftig.
Mit der englischen Noteneingabe habe ich ein persönliches
Problem, das aber vielleicht verbreiteter ist, denn es gibt einen Grund: man schreibt
c, cs, cf für c, c sharp, c flat. "C flat",
das ich so im Kopf ausspreche, würde ich automatisch aber so schreiben:
cb. Der Grund sind die vielen Akkordbuchstaben, die ich in meinem
Leben geschrieben habe. Ich habe mich immer wieder bei tiefalterierten Noten vertippt, und dann
den Fehler gesucht.
Stimmenverteilung
Setzt man mehrere Stimmen in einem Notensystem, muss man Hälse und Balken richtig und optisch gut lesbar verteilen. Die Grundregel ist, dass Hälse von Noten, die auf der mittleren Linie und darunter liegen, nach unten zeigen. Sie wird je nach Bedarf außer Kraft gesetzt.
In LilyPond gilt die Konvention, dass zum Beispiel im vierstimmigen Satz die erste und die dritte Stimme Hälse nach oben, und die zweite und die vierte Stimme Hälse nach unten haben. Für die Außenstimmen ist das schön, für die Mittelstimmen aber durchaus gewöhnungsbedürftig, denn diese Regelung zwingt einen, die zweite Stimme eines Stückes als dritte zu notieren und umgekehrt. Es wird sogar geraten, als zweite Stimme den Bass zu notieren, den Alt als dritte und den Tenor als vierte Stimme.
Möchte man die Halsrichtung für einige Noten ändern, helfen Befehle wie \override Stem.neutral-direction = #up oder \consists "Melody_engraver" \override Stem.neutral-direction = #'().
Die Zugehörigkeit zu einer Stimme bedeutet auch, dass ihre Töne horizontal um einen bestimmten Wert verschoben werden. Wenn man die Halsrichtung an einer Stelle ändert, ändert man diese Eigenschaft nicht mit.
Hier liegt also ein weiteres Grundkonzept vor, das man automatisch nutzt, das man aber außer Kraft setzen kann, wenn man meint, eine bessere Idee zu haben.
In Capella richtet man zusätzliche Stimmen in einem Notensystem ein, und gibt ihnen die
zusätzliche Eigenschaft "Oberstimme", "Unterstimme" oder "Hauptstimme". Bei letzterer gilt die
normale Halsregel mit der mittleren Linie. Dies scheint mir als Konzept auch nicht schlecht
überlegt zu sein.
Die Stimmen werden nach Zeilenumbruch natürlich übernommen, und man kann
sowohl per Menü als auch per Tastenkürzel (i + Pfeiltaste) Hälse
schnell "umlegen".
Unterteilte Balken
Es folgt ein Beispiel für ein Problem, das anscheinend völlig abgelegen ist, mich aber wegen meines Planes mit den Lautenstücken sofort beschäftigt hat. Weiter unten im Abschnitt "Benutzerfreundlichkeit" werde ich es noch einmal breittreten.
Wenn man lange Reihen von Zweiunddreißigsteln schreibt, möchte man diese oft der Übersicht halber unterteilen. Nach einem betreffenden Eintrag in den Hilfedateien habe ich lange gesucht, denn dieses Problem wird nicht bei den Grundkonzepten behandelt. Gefunden habe ich keinen direkten Link, sondern nur einen Eintrag bei den "snippets", den Schnipseln, die man sich zum copypasten zurechtbasteln muss.
Alle Textzeilen hinter dem Prozent - Zeichen "%" sind Kommentare, die nur der Erläuterung dienen, die restlichen Angaben aber sind notwendig, um die 32tel in Gruppen von vier oder zwei Noten zu formatieren.
So einfach die Grundidee ist, Noten als Textdatei zu schreiben, ahnt man doch hier, dass teilweise ganz schön viel Text erforderlich ist.
In Capella bekommt man mit der Tastenfolge Alt+t - b - Alt+u oder Alt+F10 die Unterteilungen dort, wo der Cursor steht. Die Länge von Balken wird im Menü Format - Systeme von "nur Fähnchen" über "kleine Balkengruppen" bis "Ganztaktbalken" voreingestellt.
Oktavierung
Ein weiteres Beispiel für lange Markup-Befehle: die Oktavierung im Bass im dritten Takt des
Passemezzo mit ottava bassa - Zeichen von
Vallet sieht man
im Notenbeispiel. Die Befehle vor und hinter der Note im roten Kasten erleichtern das Lesen der
Textdatei nicht:
\set Staff.ottavation = #"8" \set Voice.middleCPosition = #(+ 1 7) a,2. \unset
Staff.ottavation \unset Voice.middleCPosition |.
In Capella setze ich einfach ein Grafikobjekt, allerdings bewirkt dieses nicht, dass der Ton nach unten oktaviert klingt. Aussehen und Klang differieren. Mit verschiedenen Tricks komme ich aber zu einer Bild- und einer Mididatei. Man muss ab und zu wissen, wie man schummelt.
Musikalische Ausdrücke verschachteln
Ein besonderes Abenteuer in LilyPond ist die Möglichkeit, Stückteile aufzuschreiben, und dann in
einer Partitur unter einem vorher vergebenen Namen einzutragen. Das heißt "Nesting Music
Expressions", was so viel wie "Musikalische Ausdrücke verschachteln" bedeutet.
Ein
einfaches Beispiel dafür ist der
Blues in A,
bei dem in der Textdatei oben die Noten für
riffA, riffD und riffE aufgeschrieben sind. Dann folgen nach
\new Staff << die Angaben zu Notensystem, Schlüssel, Tonart,
Taktart, relativer Tonhöhe, und Wiederholungszeichen. In den geschweiften Klammern steht statt
Notenbuchstaben nur noch, welches Riff geschrieben werden, und wo ein Zeilenumbruch (
\break) stattfinden soll.
Das Verfahren ist enorm praktisch und Platz sparend, wenn man den Überblick behält.
Hier sieht man den Beginn eines Chorals, bei dem oben zunächst die Noten der vier Stimmen aufgeschrieben wurden. Dann folgt der Text, die Partitur wird eröffnet, eine Chorakkolade wird gesetzt, ein Notensystem für Sopran und Alt wird geöffnet, die oben notierten Stimmen werden eingesetzt, dann werden die Strophen 1 - 4 dem Sopran zugeordnet, das Notensystem wird geschlossen, und das für Tenor und Bass folgt. Wenn man keine schließende Klammer vergisst, hat man perfekte Noten, wobei es schwieriger wird, den Überblick zu behalten, wenn man mehr als zwei Takte schreibt.
Benutzerfreundlichkeit
Meine Kritik muss sich mit der Zugänglichkeit der Handbücher und Hilfedateien beschäftigen.
Das Programm LilyPond an sich hat ja gar keine Benutzerfreundlichkeit: man öffnet einen
Texteditor, benennt eine Datei mit der Endung ".ly" und kompiliert das Ergebnis, um eine PDF,
eine Vektorgrafik oder eine Midi-Datei zu bekommen. Alles, was das "Wie" beim Erstellen einer
Notendatei betrifft, muss man sich aus den Handbüchern und Hilfedateien aneignen. Alles, was man
vergisst, muss man dort suchen.
Eine Sache fand ich besonders störend: man muss viele besondere Formatierungen an- und abschalten, kann sich aber in den Handbüchern nicht darauf verlassen, dass beide Befehle an einer Stelle erklärt werden. Die Verfasser gehen eher davon aus, dass der Lernende alles Bisherige verstanden und behalten hat, und damit weiß, wo er suchen muss oder was das strukturelle Problem ist.
Man muss verstanden haben, welche Ebenen es gibt, welche man gerade bearbeitet, und wie die Befehle zum Beeinflussen einer Eigenschaft lauten. Der \set - Befehl ist für andere Dinge zuständig, als der \override - Befehl, und ihre Gegenspieler heißen auch unterschiedlich.
Im Notenbeispiel sorgt der Befehl \autoBeamOff nach dem ersten Takt
dafür, dass die Noten nicht mehr verbalkt werden, und der entsprechene Befehl
\autoBeamOn vor den letzten zwei Noten setzt die automatische
Balkensetzung wieder in Kraft.
Die sprachliche Logik von "Off" und "On" als Gegenspieler
ist ja bestechend, aber - so einfach funktioniert es nicht immer.
Wenig Hilfe
Wenn Hilfe-Dateien wenig helfen, fühlt man sich allein gelassen und verfällt leicht in die "Ich verstehe diesen Kram einfach nicht - Depression".
Es gibt Foren, in denen Fragen diskutiert werden, und eine Mailing-list, der man beitreten kann. Dort kann man Fragen eingeben und bekommt wohl auch schnell Antworten - ein Prozedere, das für Informatikstudenten sehr selbstverständlich zu sein scheint. Ich wollte aber zunächst sehen, was ich allein schaffe.
Dabei war des öfteren mein Problem, dass mir nicht immer klar war, ob ich eigentlich gerade über ein musikalisches, oder über ein Informatik-Problem nachdachte. Nachdem ich einen Befehl zum Beeinflussen des Notenbildes gefunden hatte, habe ich nach dem Gegenbefehl an gleicher Stelle gesucht. Das war ein Fehler: ich hätte auf die Meta-Ebene zurückkehren müssen, die beschreibt, wie ein bestimmter Typus von Befehl in LilyPond grundsätzlich rückgängig gemacht wird. Womit noch nicht immer heraus ist, welche Zusätze er für ein bestimmtes Ergebnis benötigt. Das findet man eventuell bei den "Snippets", Beispielen für Sonderfälle.
HTML
Auch wenn man HTML schreibt, darf man ja die schließenden tags nicht vergessen, aber die
große Erleichterung hier ist eben, dass es jedes mal gleich funktioniert: du hast einen
Container für ein Wort in blau geöffnet? - Mach ihn wieder zu!
</blue>
Natürlich weiß man nicht immer, wie das tag für
ein Video heißt, wie man dessen Größe oder Hintergrund beeinflusst und muss dann suchen, aber -
geschlossen werden sie alle mit der gleichen Bezeichnung und den Zeichen "eckige Klammer auf,
Slash, eckige Klammer zu".
Unterschiedliche Kategorien
Je tiefer man in die Lilypond einsteigt, desto mehr Konzepte scheint es zu geben, die das Behandeln unterschiedlicher Probleme erlauben. Mit "assoziativen Listen", "Abständen und Maßen" oder "reinen und unreinen Containern", unterschiedlichen Konzepten für das Steuern des Ergebnisses, habe ich mich noch gar nicht beschäftigt. Dass diese Dinge in LilyPond existieren bedeutet allerdings, dass der Benutzer irgendwann, wenn er ein spezifisches Problem hat, erst mal lernen muss, dass jemand für dieses Problem eine Kategorie und eine spezifische Bezeichnung gefunden hat. Dann muss man sich deren Handhabung erarbeiten.
Möchte man zum Beispiel veränderte Notenköpfe haben, findet man dazu leicht diese Seite. Aber es gibt auch die "Stempel - Eigenschaft", mit der man anscheinend die Größe eines Notenkopfes manipulieren kann. Auf der Seite über Notenköpfe sucht man allerdings die Vokabel "Stempel" oder "stencil" vergeblich.
Irrwege
Mein Beispiel für eine lang dauernde Suche seien noch einmal die unterteilten Balken. Das ist offenbar ein absolutes musikalisches Randproblem (Tatsächlich enthält z.B. Bachs Manuskript des Adagio der ersten Sonate für Violine solo keine unterteilten Balken; wenn man eine Peters-Edition von Beethovens Klaviersonaten durchblättert, findet man sie sehr wohl.) - für mein Vorhaben, Lautenstücke mit Diminuitionen zu übertragen, war es eine der ersten Fragen. Transkriptionen solcher Stücke sehen ohne unterteilte Balken eben nicht schöner aus als konventionelle Capella-Dateien. Es geht ja, nur wie? Ich versuche, meine Irrwege wiederzugeben.
Die Beispiele behandeln die ersten Takte der diminuierten Fassung des Passemezzo antico von Adrian Le Roy. Beispiel 1 zeigt die 32telkette am Ende des ersten Taktes ohne Unterteilung der Balken.
Bild 2 liefert den Code zu den vorstehenden Noten. Sie stehen in der dritten Stimme der Partitur. An der ersten Note, der Achtel punktiert c, ist die Überschrift "plus diminué" befestigt, ansonsten ist der Text ohne Finessen.
Bild 3 enthält eine Trennung der Balken innerhalb der vierten Zählzeit nach einer Achtel. Ich wollte aber nicht eine Trennung, sondern eine Unterteilung der Balken.
Der Text dazu steht in Bild 4: Die von AtLilyPond in Atom automatisch rot angezeigten eckigen Klammern in der letzten Zeile sorgen für die Trennung der Balken.
In Bild 5 bin ich fast am Ziel: ich habe meine Balkenteilung am Ende des ersten Taktes, aber jetzt werden die Balken immer nach einer Achtel unterbrochen, was in der ersten Takthälfte von Takt 3 dann doch zuviel des Guten ist!
Verantwortlich dafür sind in Bild 6 die Befehle in den Zeilen 3, 4 und 5, die wahrscheinlich genau so komplex wie nötig sind, aber eben ganz schön weit schweifend. Ich habe sie auch nicht wirklich verstanden, sondern als "snippet" kopiert und herum probiert. Sie setzen ab hier die Unterteilung der Balken für den Rest der Partitur. Wie stellt man das wieder ab?
In Bild 7 ist das gewünschte Resultat endlich erreicht: die Balken werden in Takt 3 am Anfang durch den Befehl \unset subdivideBeams wieder verbunden, und in der zweiten Takthälfte mittels \set subdivideBeams = ##t (Darauf muss man erst mal kommen!) unterteilt, aber für eine halbe Note zusammengefasst, wie man in Bild 8 sehen kann.
Ich vermute, dass ich das Ganze nicht wirklich richtig gemacht habe. Aber nachdem ich eine funktionierende Lösung gefunden hatte, habe ich nicht weiter geforscht. Irgendwann war mir näher, mit meiner Seite weiter zu kommen.
Die Erläuterungen zu unterteilten Balken findet man, wie bereits erwähnt, nicht über ein verlinktes Suchergebnis, sondern indem man diese Seite der Dokumentation über Balken durchliest, also eher versteckt. Das lag letztlich daran, das der entsprechende Abschnitt (noch) nicht auf deutsch vorlag. Rückwirkend muss ich mich also schuldig bekennen: wenn ich zunächst den Begriff auf englisch gesucht und dann weiter geforscht hätte, wäre ich vielleicht schneller zum Ziel gekommen. Die Internet-Suche ist ein mächtiges Instrument, das aber sehr abhängig davon ist, wie geschickt sich der Suchende anstellt.
Was das rückgängig Machen des Befehls angeht, bin ich wirklich fast an meine Grenzen gestoßen: Es ist in den Hilfeseiten zu LilyPond eben nicht so, dass Befehl und "Anti-Befehl" an einer Stelle erklärt werden, oder zumindest ein Link vorhanden ist, sondern man muss sich fragen "Was tue ich gerade? - Ich wende einen \set - Befehl an." Also suche ich nicht nach "Wie widerrufe ich unterteilte Balken?", sondern nach "Wie widerrufe ich \set?"
Wenn man diese Seite über den Befehl \set in aller Ruhe durchliest, wird einem klar, dass man wirklich gezwungen ist, die Strukturen des Programmes zu verstehen, bis dahin, dass sich ein Befehl hierarchisch auf bestimmte Ebenen bezieht, er also eventuell nichts bewirkt, weil man ihn im falschen Kontext gesetzt hat.
Allgemeine Probleme bei Gitarrennoten
Es ist generell nicht einfach, Noten für Laute in Gitarrennotation aufzuschreiben. Tatsächlich wird in vielen Ausgaben eine Akkolade mit Violin- und Bassschlüssel benutzt. Die Konvention, Stücke für Gitarre in einem System aufzuschreiben führt bei mehrstimmiger Musik immer zu Problemen. Hälse von Mittelstimmen stören, Sekundreibungen müssen seitlich versetzt werden, eigentlich nötige Pausen lässt man weg oder macht sie unsichtbar (wenn man mit Computern arbeitet, kann man Zeichen nicht einfach weglassen) - es ist immer schwierig, den Notentext lesbar zu halten.
Im Passemezzo antico von Terzi sieht man, dass LilyPond die Noten eines vierstimmigen Satzes grundsätzlich horizontal um eine bestimmte Entfernung gegeneinander versetzt. Bei den einfachen Sätzen von Ortiz habe ich diese Automatik mit dem Befehl \override NoteColumn.force-hshift = #0 abgeschaltet; eigentlich sähe das Notenbild aus wie hier die Recercada Segunda. Das schien mir für so einen homorhythmischen Satz aber so übersichtlich, dass es schon wieder unübersichtlich wurde.
In Capella setzt man den Cursor vor eine Note, hält die Taste "j" und verschiebt die Note mit
den Pfeiltasten nach Belieben. Man kann also das Versetzen der Noten leicht auf die
neuralgischen Punkte beschränken. Natürlich kann man das auch über das Menü und für mehrere
Noten einer Stimme gleichzeitig machen.
Das Problem ist in beiden Fällen das gleiche: es
gibt zu wenig Platz, man bräuchte eigentlich oft zwei
Systeme, und
die Stücke, die ich transkribiert habe verlangen einem ständig Entscheidungen ab in Richtung "Zu
welcher Stimme gehört diese Phrase? Sollte ich diese Pausen sichtbar oder unsichtbar
formatieren? Eigentlich muss dieser Hals nach oben, kann ich ihn hier nach unten klappen?" etc.
Noten, wie die Stückanfänge von Susato im verlinkten Abschnitt sind auch in LilyPond hurtig geschrieben; vier Stimmen in einem System hingegen sind auch in Capella nicht einfach.
Tolle und merkwürdige Ideen
Die ganze Idee von LilyPond ist toll. Wie großartig sie ist, merkt man erst, wenn man sich in den tweaks oder bei den snippets umschaut. Dass man mit bloßem Text derartig verrückte graphische Dinge beschreiben kann! Hier beginnt aber irgendwann die Grenze zu dem Gebiet, wo der Leser (ich zumindest) extrem gefordert wird. Zum Beispiel ist diese Grundsatzerklärung zum Thema "grob interface" nicht ganz einfach, hier wird munter mit Begriffen um sich geworfen, die man eher mit Informatik als mit Musik assoziiert.
Die nötige Präzision der markup language ist für den normalen Nutzer irgendwie auch ein Pferdefuß. Man kann die Position eines Fingersatzes oder sonstigen Textelementes immer irgendwie beeinflussen. Aber wenn man von seiner konventionellen Lieblingsanwendung gewohnt ist, einfach den Cursor in einer Zeile zu platzieren, die TAB-Taste zu drücken, das erste Grafikelement damit markiert zu haben und dieses dann mit den Pfeiltasten punktgenau verschieben zu können, fühlt man sich bei LilyPond doch ein bisschen gezwungen, Dinge zu tun, für die Computer doch eigentlich erfunden worden waren. Die Software sollte mir doch Arbeitsschritte abnehmen?
Erleichterte Bedienung von LilyPond
Es gibt verschiedene Möglichkeiten, sich die Benutzung von LilyPond etwas zu erleichtern. Ein attraktives Programm ist Frescobaldi, eine Anwendung, die einen Text-Editor mit syntax-highlighting, ein Fenster mit einer graphischen Vorschau und eine direkte Möglichkeit, erstellte Mididateien abzuspielen vereint. Außerordentlich praktisch ist die Möglichkeit, mit der Maus auf ein Textelement zu zeigen und damit die entsprechende Stelle in der Notengrafik angezeigt zu bekommen und umgekehrt. Das ist eine Labsal, denn in langen Dateien kann die Fehlersuche sonst ganz schön schwierig sein!
Das Abspielen von Mididateien ist nicht leicht ans Laufen zu bringen; eine Eingabe über
Midikeyboard gibt es wohl nicht (Ach, in Capella kann man zwei Hände voll Noten gleichzeitig
schreiben!).
Insgesamt ist Frescobaldi also eine etwas anders aussehende, und
auch etwas mehr an eine konventionelle Software erinnernde Anwendung. Ich habe spät angefangen,
sie zu benutzen, bin aber für bestimmte Arbeitsprozesse wieder zu
Atom und LilyCompile zurückgekehrt.
Zusammenfassung
Wenn ich Noten mit einem Computer schreiben möchte, muss ich wissen, dass auf der einen Seite ein Notenbild, und ganz am anderen Ende Einsen und Nullen sind. Dazwischen greife ich ein, und manipuliere die Einsen und Nullen über mehrere Sprachebenen. Die Frage ist immer wieder: Wie weit zwingt ein Programm den Nutzer, sich der Maschinenseite der Einsen und Nullen anzunähern?
Für mich ist zum Beispiel die Entwicklung bei den unterschiedlichen Versionen des Betriebssystems "Windows" immer mehr dahin gegangen, es dem Nutzer bequemer zu machen, und ihn dabei für immer dümmer zu halten. Die zeitweise Abschaffung des Shortcuts Alt+Enter zum Aufrufen der Eigenschaften einer Datei oder eines Ordners im Explorer ist ein Beispiel: Wozu braucht man das denn? Wozu braucht man überhaupt den Explorer? Wir geben den Nutzern große bunte Kacheln, auf die sie klicken können!
Programme wie LilyPond halten einen im Gegensatz dazu zu extremer Mündigkeit an. Du willst einfach nur eben größere Abstände zwischen zwei Notenzeilen, dich interessiert nur, wie man es macht, und in der nächsten Zeile soll es wieder weg sein, weil weniger Noten auf Hilfslinien vorkommen? Vergiss es! Entweder du bist bereit zu lernen, welche Ebene deines vorgestellten Notenblattes du gerade bearbeitest, oder...
Es gibt Leute wie den User Interface Designer Bret Victor, die viel darüber nachdenken, wie man zwischen Mensch und Maschine vermitteln kann. Programmierer sind Menschen, die mehr von den Strukturen verstehen und sich gedanklich "dichter" an die Ebene der Einsen und Nullen heran denken können. Sie verstehen mehr von der Materie, und Nicht-Programmierer können viel von ihnen lernen. Aber man muss immer im Auge behalten, wie viel von den Programmstrukturen man zu wie großen Zeitanteilen gewöhnlichen Nutzern aufbürdet.
Könnte man parallel eine "Hilfe für Dummies" zu Lilypond schreiben? Könnte man, graphisch anders aufbereitet, mehr "unwissenschaftliche" Hinweise einbauen, wo man sich möglicherweise vergallopiert, wo man Problemlösungen besser auf einer Meta-Ebene suchen sollte? Wenn man überall "Gegenbefehle" verlinken wollte, wäre das sicher eine Heidenarbeit, aber - die LilyPond Handbücher sind ja jetzt schon umfangreich!
Nicht alle Menschen sind gleich intelligent, oder verfügen über die gleiche Art analytischer Intelligenz, möchten aber vielleicht trotzdem diese herausfordernde Software benutzen.
