„Besessen davon, mit Tinte auf dem Papier zu zeichnen“

Was steckt hinter LilyPond?

LilyPond ist nicht einzigartig mit seiner Fähigkeit, Notation zu setzen; ganz im Gegenteil gibt es eine Vielzahl von Notationsprogrammen, und heutzutage wird fast alle neu gedruckte Musik am Computer gesetzt. Das zeigt aber leider auch einen Nachteil: Neue Noten sehen nicht so gut aus wie die alten. Das kann Ihnen jeder Musiker, der klassische Musik spielt, bestätigen.

Was ist der Unterschied zwischen Handarbeit und Maschinenwerk, und woher kommt er? Wie können wir die Situation verbessern? Dieser Aufsatz erklärt Probleme der Musiknotation(sprogramme) und unseren Ansatz, diese Probleme zu beseitigen.

Inhaltsverzeichnis

Einleitung: Warum ist der Computernotensatz nicht gut?
Was stimmt nicht mit den Programmen, oder Warum ist Finale nicht die Sackgasse des Computernotensatzes?
Wie sollte man ein Programm nicht schreiben, oder Ein Notationsprogramm formen
Divide et impera, Ein Entwurf zur automatisierten Notation
Interessant, aber funktioniert das denn auch in der Theorie? Ein praktischer Ansatz, Notation zu erfassen
Notensatz, die Kunst des Notenstechens
Typographie integrieren: Hacker nehmen sich des Notensatzes an
Eine flexible Programmstruktur: Schreiben wir ein Satzprogramm!
Schöne Zahlen oder Wie LilyPond am MissWorld-Wettbewerb teilnimmt
Notationsbenchmark: genügt eine flexible Architektur?
Typographische Eigenschaften einzigartig in LilyPond
Das Eingabeformat: Wie die Musik notiert wird
Schluss

Diesen Aufsatz gibt es auch auf einer Seite.

Warum ist der Computernotensatz nicht gut?

Wir bezeichnen LilyPond gerne als ein ‚automatisiertes Satzprogramm‘. Es setzt Noten automatisch auf eine schöne Art und Weise, ohne dass der Benutzer Expertenkenntnisse vorzuweisen bräuchte.

LilyPond ist nicht einzigartig mit seiner Fähigkeit, Notation zu setzen; ganz im Gegenteil gibt es eine Vielzahl von Notationsprogrammen, und heutzutage wird fast alle neu gedruckte Musik am Computer gesetzt. Das zeigt aber leider auch einen Nachteil: Neue Noten sehen nicht so gut aus wie die alten (etwa vor 1970). Die neuen sehen langweilig und mechanisch aus. Es macht kein Vergnügen, von ihnen zu spielen. Das kann Ihnen jeder Musiker, der klassische Musik spielt, bestätigen.

Um das zu illustrieren, wollen wir einen Blick auf die beiden Beispiele werfen. Beide sind Editionen von J. S. Bachs erster Suite für Violoncello. Die linke Version ist ein wunderschöner Handstich von 1950, die rechte Version ein typischer moderner Computersatz. Nehmen Sie sich einige Sekunden Zeit, die Frage zu beantworten: Welche von beiden Versionen finden Sie schöner, und warum?

Das linke Beispiel sieht elegant aus mit seinen fließenden Linien und seinem dynamischen Bild. Das ist Musik, und sie lebt. Das rechte Beispiel dagegen zeigt die gleiche Musik, wie sie von Bach geschrieben wurde. Seine Musik ist voller Lebendigkeit und fließenden Linien – allein die Partitur zeigt das nicht, sie ist starr und mechanisch. Um noch besser zu verstehen, wie das kommt, wollen wir uns ein vergrößertes Bild der beiden Editionen anschauen:

handgesetzt

mit dem Computer gesetzt

Die Position der Taktlinie ist ein Werbegeschenk. In der neuen Edition befinden sich beide Taktlinien exakt an der gleichen horizontalen Position. Auch die Notenköpfe sind an exakt der gleichen horizontalen Position. Im Vergleich mit dem gesamten Notentext kann man sich schnell davon überzeugen, dass fast alle Taktlinien an der gleichen Position auf der Seite sind, genauso wie die meisten Notenköpfe. Die gesamte Seite ist aufgeteilt als ob alle Objekte durch ein großes Sieb positioniert worden wären, und dadurch kommt der mechanische Eindruck zustande.

Das ist nicht der einzige Fehler in diesem Beispiel, dies ist nicht das einzige Notenblatt mit typographischen Fehlern. Leider ist tatsächlich fast alle heutzutage gedruckte Musik voll von grundlegenden typographischen Fehlern.

Musiker sind üblicherweise zu zu konzentriert, die Musik aufzuführen, als dass sie das Aussehen der Noten studieren könnten; und diese Erbsenzählerei der typographischen Details mag akademisch wirken. Das ist aber nicht gerechtfertigt. Unser Beispielstück hat einen monotonen Rhythmus, und wenn alle Zeilen gleich 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.

Hier haben wir eine übliche Definition des Wortes Typographie gegeben. Layout sollte ansprechend aussehen, und zwar nicht nur um seiner selbst willen, sondern vor allem, um dem Leser zu helfen. Für Aufführungsmaterial wie etwa Notenblätter ist das umso wichtiger: Ein Spieler kann den Noten nur eine begrenzte Aufmerksamkeit schenken. Und je weniger Aufmerksamkeit nötig ist, um die Noten zu erfassen, um so mehr Zeit können sie in die Aufführung selber stecken. So wirkt sich gute Typographie direkt in eine verbesserte Aufführung aus!

Weiter: Was stimmt nicht mit den Programmen, oder Warum ist Finale nicht die Sackgasse des Computernotensatzes?

Was stimmt nicht mit den Programmen?

Durch den Computer hat das Massenpublikum heute Zugang zum Notensatz, aber der Computersatz ist üblicherweise minderwertig. Offensichtlich haben sich die Programmierer keine große Mühe mit Notationsprogrammen gegeben. Um das zu zeigen, haben wir einen Amateur gebeten, ein Musikstück mit einem der beliebtesten „professionellen“ Notationsprogrammen, die heute erhältlich sind, zu setzten. Er benutzte Finale 2003 mit den Standardeinstellungen. Die Musik stammt aus der Sarabande der zweiten Suite für Violoncello von J. S. Bach.

(Finale ist ein registriertes Markenzeichen der Firma MakeMusic! Inc.)

Dieses Beispiel übertrifft noch das vorhergehende mit seinen vielfältigen Satzfehlern: Hier finden sich jetzt ernsthafte Fehler in wirklich jedem Takt. Und das sind Fehler aller Art: Einer ist etwa das seltsam a u s e i n a n d e r g e z o g e n e letzte System. Ein kleinerer Fehler ist das b in Takt 13, das von der vorhergehenden Note verdeckt wird. Hier eine Vergrößerung dieses Taktes:

Die Fehler reichen bis ins kleinste Detail: Unten ist eine sehr starke Vergrößerung des selben Taktes zu sehen. Natürlich sollte der Balken in einem guten Satz nicht rechts über den Hals hinausragen, und die kleinen Bögen sind ein vielsagender Hinweis auf die Versiertheit (oder eben Ignoranz) der Programmierer von Coda Music Technology mit der PostScript-Technologie.

Jetzt könnte man anführen, dass Finale ein graphisches Programm ist und man damit sehr einfach alle Notationselemente herumschieben kann, um die Fehler zu beseitigen, oder plug-ins benutzen kann, die das übernehmen. Das stimmt auf jeden Fall – in der Tat brauchen gute professionelle Notensetzer die meiste Zeit dafür, all die Fehler zu beseitigen, die Finale standardmäßig macht. Aber ist es denn so angenehm, die ganze Zeit nur Fehler zu korrigieren? Für eine gedehnte Zeile ist das ja noch möglich, aber wenn man jeden einzelnen Balken korrigieren muss, der etwas übersteht – und das alles manuell?

Es gibt noch einen weniger offensichtlichen Grund, warum es keine gute Idee ist, alles manuell zu korrigieren. Nehmen wir wieder den Takt 13 von oben. Dieses falsch plazierte b ist ja ziemlich offensichtlich, aber wem ist der Doppelstrich mit den Wiederholungspunkten aufgefallen? Seine Linien sind zu weit auseinder. Und wer hat bemerkt, dass die Achtelpause zu tief saß? Und dass der Stil der letzten Achtelnote zu lang ist?

Nur ein Experte kann diese Feinheiten wirklich wahrnehmen. Üblicherweise aber werden solche Fehler nicht korrigiert und finden sich dann auch noch in der endgültigen Version.

Dieses Beispiel mag konstruiert erscheinen, aber es ist weit davon entfernt. Alle großen Notationsprogramme behaupten, Notensatzstandards einzuhalten, aber uns ist kein einziges über den Weg gelaufen, das auch nur die grundlegendsten Regeln einhalten würde. Alle machen systematisch Fehler. Um die Satzqualität seines eigenen Notationsprogrammes auszuprobieren, muss man nur ein handgestochenes Notenblatt von einem anerkannten Verlag kaufen und versuchen, es mit dem Programm zu kopieren. Dann sollte man beide Versionen vergleichen:

Wie steht es mit dem Layout der Seite? Normalerweise sind Computernoten weiter gesetzt, so dass sie mehr Seiten füllen; das heißt gleichzeitig mehr störendes Blättern.
Wie sehen die Abstände aus? Sind sind sie so fließend und lebendig wie in dem handgestochenen Notenblatt? Bei Zweifeln sollte man beide Versionen mit dem Lineal ausmessen.
Wie sehen beide Versionen im Vergleich aus, wenn man sie auf einem Notenständer aus einem Meter Entfernung betrachtet? Das ist üblich während eines Konzerts. Sind beide Seite gut zu lesen? Fast alle Computernoten sehen irgendwie kränklich aus: Die Notenlinien sind zu dünn und die Symbole sind zu fein. Deshalb sind sie schwer aus einiger Entfernung zu lesen. Die Unterschiede lassen sich am besten mit einem Vergrößerungsglas zeigen.

Weiter: Wie sollte man ein Programm nicht schreiben, oder Ein Notationsprogramm formen.

Wie sollte man ein Programm nicht schreiben

Es währe schön, wenn Notationsprogramme keinen Babysitter bräuchten, der ihnen einen guten Satz beibringt. Unser Ziel mit LilyPond war es, genau so ein System zu schreiben: ein Programm, das schöne Musik („Notenstich“) automatisch produziert.

Auf den ersten Blick scheint es, dass Notation einer direkten Hierarchie folgt. So etwa in dem Beispiel unten, mit zwei System, die Takte beinhalten.

Ist nicht auch Programmieren die Kunst, Hierarchien zu finden und die wirkliche Welt als einen verzweigten Baum darzustellen? Ein naiver Programmierer könnte das obige Beispiel schnell mit einigen geschachtelten Kästen abstrahieren.

Es ist einfach, mit diesem Modell zu programmieren. Es ist klar, wie die Information im Speicher gelagert wird, und Schreibvorgänge können einfach gespiegelt werden. In einer XML-Datei würde es etwa wie folgt aussehen:

  <score>
    <staff>
      <measure id="1">
         <chord length="1/2">
	   <pitch name="c">
         </chord>
         <chord>
	 
	 ....
      </measure>
    </staff>
  </score>

Das ist klar, einfach und sauber. Nach diesem Format werden viele Programme geschrieben. Leider ist es aber auch falsch. Die hierarchische Präsentation funktioniert mit einem Großteil einfacher Musik, zeigt sich aber überfordert mit komplizierterer Notation. Zum Beispiel:

Hier sind einige Annahmen des ersten Beispiels verletzt. Systeme beginnen und enden plötzlich, Stimmen springen zwischen den Systemen hin und her und erstrecken sich über zwei Systeme.

Notation unterscheidet sich von der eigentlichen Musik. Notation ist eine komplizierte Diagrammsprache, die eine oft sehr viel einfachere Musik symbolisiert. Notationsprogramme müssen daher diese Unterscheidung beherrschen.

Weiter: Divide et impera, Ein Entwurf zur automatisierten Notation

Strategieplan

Da Inhalt und Form der Musiknotation sich unterscheiden, müssen wir darauf bei dem Entwurf unseres Programmes acht geben. Die Grundlage unseres Programmes erfolgt also nach diesem Schema:

	←	`{ c'4 d'8 }`
1. Form	2. Übersetzung	3. Inhalt

Am besten können wir das Problem besiegen, indem wir es in Unterprobleme teilen:

Typographie: wohin die Symbole sollen
Notation: welche Symbole benutzt werden
Representation: wie soll die Musik kodiert werden

Schließlich entsteht durch die Unterteilung ein neues Problem:

Architektur: Wie setzt man alles wieder zusammen

Weiter: Interessant, aber funktioniert das denn auch in der Theorie? Ein praktischer Ansatz, Notation zu erfassen

Notation von Musik

Die übliche Notation erfasst etwa 500 Jahre Musikgeschichte. Ihre Anwendung reicht von monophonen Melodien bis zu ungeheurem 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.

Die untersten Plugin-Ebene erstellt die Notenköpfe:

Mit diesem Plugin werden die graphischen Elemente für musikalische Ereignisse dargestellt. Der Schreiber, der die Musik in Graphik umwandelt, ist ein Kopist oder Notenstecher (engl. engraver). Darum wird dieses Plugin Note_head_engraver (Notenkopfstecher) genannt.
Der Staff_symbol_engraver (Notensystemstecher) erstellt die Objekte, das die Notenlinien darstellt.
Der Clef_engraver (Notenschlüsselstecher) sagt dem Note_head_engraver wie hoch jedes Symbol gesetzt werden soll.
Für Fähnchen und Hälse nehmen wir den Stem_engraver (Halsstecher):

Diesem engraver wird jeder Notenkopf mitgeteilt, der vorkommt. Jedes Mal wenn ein (oder mehrer bei einem Akkord) Notenkopf erscheint, wird ein Hals-Objekt erstellt und an den Kopf geheftet.
Balken, Bögen und Akzente werden von eigenen engravern gehandhabt. So wie der stem_engraver erstellen sie Objekte und verbinden sie dann mit den Hälsen, Köpfen usw.:
Vorzeichen, Taktstriche, Taktartangaben und Schlüssel haben alle ihre eigenen engraver.

Der Accidental_engraver ist von ihnen am kompliziertesten. Er muss sowohl die Schlüsselangabe, Notenhöhe, Bögen als auch Taktstriche beachten, damit er die richtige Stelle fü die Vorzeichen entscheiden kann.

Polyphone Notation

Das System, wie es im letzten Absatz gezeigt wurde, funktioniert sehr gut mit monophoner Musik, aber wie geht es mit Polyphonie? Hier müssen sich mehrere Stimme ein System teilen:

In diesem Fall werden das System und die Vorzeichen geteilt, aber die Hälse, Bögen, Balken usw. sind jeder einzelnen Stimme eigen. Die engraver müssen also gruppiert werden. Die fü die Köpfe, Hälse, Bögen usw. werden in einer Gruppe mit dem Namen „Voice context“ (Stimmenkontext) zusammengefasst, die engraver für den Schlüssel, die Vorzeichen, Taktstriche usw. dagegen in einer Gruppe mit dem Namen „Staff context“ (Systemkontext). Im Falle von Polyphonie hat ein Staff context dann also mehr als einen Voice context. Auf gleiche Weise können auch mehrere Staff contexte in einen großen Score context (Partiturkontext) eingebunden werden:

Weiter: Die Kunst des Notenstechens: Wie wurde denn Musik mit der Hand gestochen?

Der Notensatz

Sobald bekannt ist, welche Symbole gedruckt werden müssen, muss entschieden werden, wie sie angeordnet werden, damit das Resultat angenehm wirkt. Diese Kunst nennt man Notensatz oder auch Notenstich. Dieser Begriff stammt aus dem traditionellen Notendruck. Noch etwa bis vor 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 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 vorneherein richtig schneiden musste. Es handelte sich dabei um ein sehr spezialisiertes Handwerk.

Der Notensatz ist ein tranditionelles Handwerk und wurde in der Praxis vermittelt. Um Meister zu werden, musste man ungefähr zehn Jahre Arbeitserfahrung haben.
Fast alles Wissen wurde während der Arbeit vom Meister and den Lehrling weitergegeben. Darum findet sich auch nur wenig Schriftliches über die Regeln des eleganten Notensatzes.
Schließlich muss man beim Notensatz sehr genau die richtigen Abstände und Schwärzung eines Notenblattes auswählen Können. Die Qualität des Resultates musste visuell begutachtet werden. Diese Fähigkeit kann man natürlich kaum in Formatierungsregeln ausdrücken.

Weiter: Stempeln am Bildschirm?. Computerhacker nehmen sich des Notensatzes an

Typographie implementieren

Wie sollen wir also jetzt die Typographie anwenden? Nachdem wir schon die Frage beantwortet haben, was für Notensymbole wir brauchen, haben wir einen ganzen Sack voller loser Elemente, die Notenköpfe, Hälse usw. darstellen.

Wie können wir jetzt auf einmal 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 erleichtert 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 mit den existierenden Programmen. Und mit der Zeit können immer mehr Fälle automatisiert werden, so dass immer weniger Eingriffe von Hand notwendig werden.

Wie aber bauen wir ein solches System? Als wir anfingen, haben wir ein Programm mit C++ geschrieben. Das heißt aber, dass der Funktionsumfang des Programmes vom Anfang an durch die Entwickler festgelegt ist. Das erschien uns nicht ausreichend:

Wenn manches noch von Hand eingestellt werden muss, muss der Benutzer auch Zugang zur Formatierungsmaschinerie haben. Also können die Regeln und Einstellungen nicht beim Kompilieren des Programmes festgelegt werden, sondern sie müssen während des Laufes zugänglich sein.
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.
Schließlich verfeinern wir unseren Formatierungsalgorythmus immer weiter, also müssen die Regeln auch flexibel sein. Die C++-Sprache zwingt zu einer bestimmten Gruppierungsmethode, die nicht den Regeln für den Notensatz entspricht.

Auf jeden Fall brauchten wir also eine flexible Architektur. Sie sollte Formatierungsregeln, typographische Stile und individuelle Formatierungsentscheidungen umfassen.

Weiter: Eine flexible Programmstruktur: Formen, Entwickeln und Abstimmen der Typographieregeln

Eine flexible Programmstruktur

Die Frage nach den Notationszeichen hat uns eine ganze Menge von Objekten geliefert. Die Struktur zur Formatierung der Noten hängt von diesen Objekten ab. Jedes Objekt besitzt einige Variablen:

Variablen kontrollieren die Entscheidungen über das Layout. So haben viele Objekte eine Richtungs-Variable, die das Objekt entweder nach oben oder nach unten (oder nach links und rechts) ausrichten. Im Beispiel sind zwei Akkorde mit Akzenten und Arpeggio. Beim ersten Akkord sind alle Objekte nach unten (oder links) ausgerichtet, beim zweiten nach oben (rechts).

Der Prozess des Notensetzens besteht also darin, Variable zu lesen und zu schreiben.
Einige Variablen haben festgelegte Werte. So ist etwa die Dicke von vielen Linien – ein Charakteristikum des typographischen Stils – von vorneherein festgelegt. Wenn sie geändert werden, ergibt sich ein anderer typographiscer Ausdruck:
Formatierungsregeln sind auch von vorneherein festegelegt. Jedes Objekt hat Variablen, die Vorgänge beschreiben. Diese Vorgänge machen die eigentlich Satzarbeit, und wenn man sie durch andere ersetzt, kann ihr Verhalten verändert werden. Im nächsten Beispiel wird die Regel, mit der die Notenköpfe gezeichnet werden, verändert:

Weiter: Schöne Zahlen oder Wie LilyPond am MissWorld-Wettbewerb teilnimmt

Schöne Zahlen

Wie aber werden nun tatsächlich Entscheidungen über die Formatierung vorgenommen? Oder auch: welcher von drei Werten für den Bogen im Beispiel ist der beste?

Es gibt einige wenige Bücher über die Kunst des Notensatzes. Leider haben sie oft nur Daumenregeln und dazu ein paar Beispiele. Solche Regeln können sehr lehrreich sein, aber mit ihnen kann man natürlich keine Algorithmen für einen Computer erstellen. Wenn man die Regeln aus der Literatur befolgt, ergeben sich Algorithmen, zu denen man noch eine große Anzahl von handgeschriebenen Ausnahmen hinzufügen muss. Die Analyse aller Fälle ist sehr arbeitsintensiv, und oft sind noch nicht einmal alle Möglichkeiten abgedeckt.

Formatierungsregeln am Beispiel definiert.Ausschnitt aus der Art of Music Engraving von Ted Ross.

Wir haben eine sehr viel einfachere und verlässlichere Methode entwickelt, um die beste Formatierungsoption zu ermitteln: ein Notenbildvergleich. Der erfolgt nach dem gleichen Prinzip wie ein Schönheitswettbewerb: für jede mögliche Einstellung erstellen wir eine Hässlichkeitsskala. Dann wird die am wenigsten hässliche Einstellung ausgewählt.

In der ersten Einstellung, zum Beispiel, reicht der Bogen sehr gut an die erste und letzte Note heran. Das ist auch eine sehr wichtige Forderung. Ein anderer Notenkopf wird allerdings sehr nahe gestreift, während die anderen ziemliche große Abstände aufweisen. Also wählen wir für diese Einstellung eine Punktezahl von 15,39.

In dieser Einstellung hat der Bogen zwar den gleichen Abstand zu allen Notenköpfen, aber wir müssen einige Punkte abziehen, weil der Bogen nicht mehr bis zu den Anfangs- und Endnoten reicht. Für die linke Seite ziehen wir 1,71 Punkte ab, für die rechte Seite (die noch weiter vom Notenkopf entfernt ist) 9,37. Zusätzlich steigt der Bogen an, während die Melodie absteigend ist. Das sind nochmal zwei Strafpunkte.

Am Ende ist nur noch das Ende des Bogens weit weg von dem letzten Notenkopf, und diese Einstellung hat 10,04 Hässlichkeitspunkte.

Wenn wir nun alle drei Einstellungen vergleichen, sehen wir, dass die dritte Option die am wenigsten hässliche, oder die schönste ist. Darum wählen wir sie aus.

Das ist eine sehr allgemeine Technik, und sie kann für sehr viele Situationen angewandt werden, etwa beim

Bestimmten der Balkensteigung
Formatieren von angebundenen Akkorden
Formatieren von punktierten Noten,
Zeilenumbruch,
Seitenumbruch usw.

Diese Technik braucht einige Zeit, denn man muss sehr viele Möglichkeiten auswerten, aber es ist den Aufwand wert, denn das Resultat ist sehr viel besser, und die Satzarbeit wird dadurch ganz erheblich erleichtert.

Weiter: Der Mensch ist das Maß der Dinge oder Genügt eine flexible Architektur?

Notationbenchmark

Eine flexible Architektur ist notwendig für guten Notensatz. Aber sie ist leider nicht ausreichend. Nur eine sehr sorgfältige Imitation eines gedruckten Notenblattes kann ein gutes Ergebnis bringen. Zu Anfang schlugen wir vor, den Notensatz eines Programmes mit einem handgravierten Satz zu vergleichen. Mit genau dieser Technik machen auch wir uns daran, LilyPond zu polieren. Es ist sozusagen eine Benchmark-Technik: Die Qualität der Arbeit des Programmes wird im Vergleich mit einer festgelegten Größe gemessen.

Hier sind Teile eines Benchmark-Stückes zu sehen. Zuerst die Vergleichsedition (Bärenreiter BA 350), darunter dann der Satz von LilyPond Version 1.4:

Bärenreiter

LilyPond 1.4

Das Ergebnis von LilyPond ist schon gut zu lesen, und für viele Leute würde es wohl auch ausreichen. Aber der genauere Vergleich mit dem handgravierten Beispiel enthüllt viele Fehler in den Satzdetails:

Viele Symbole sind nicht ausbalanciert. Besonders das Triller-Zeichen ist zu groß.
Hälse und Balken sind alle falsch: die Hälse zu lang und die Balken sollten angeschrägt sein und die Notenlinien exakt überdecken. Die Balken sind auch zu dünn.
Die Aufteilung ist unregelmäßig, einige Takte zu breit, andere zu schmal.

(Und außerdem fehlten einige Noten in der ursprünglichen Version von LilyPond.)

Indem wir uns der relevanten Algorithmen, Einstellungen und Schriftartenformen annahmen, konnten wir das Ergebnis verbessern. Der Satz von LilyPond Version 1.8 findet sich unten. Auch wenn es sich immer noch nicht um einen Klon der Referenzversion handelt, hat der Satz doch schon fast Publikationsqualität.

LilyPond 1.8

Bärenreiter

Ein anderes Beispiel für diesen Benchmark-Test für die Programmversion 2.1x ist ein Schubert-Lied.

Weiter: Einzigartige Eigenschaften, mit denen LilyPond brilliert

Schriftartdesign

Ein wichtiger Faktor für die traditionelle Wirkung, die LilyPonds Notenbild erreicht, ist der Graufaktor der Seite. Durch die Verwendung von dickeren Notenlinien und einer Schriftart, die darauf abgestimmt ist, wirkt der Gesamteindruck sehr viel kräftiger. Das wird sofort deutlich in den folgenden Beispielen:


Henle (2000)	Bärenreiter (1950)	LilyPond (2003)

Ein weiterer typischer Aspekt eines handgravierten Notenbildes ist das allgemeine Design der Zeichen. Sie haben fast nie scharfe Kanten. Das rührt daher, dass scharfe Ecken an den Stempeln sehr schnell schartig werden, wenn man sie in Metall schlägt. Diese rundliche Form wurde auch für die Symbole unserer „Feta“-Schriftart herausgearbeitet.

Abstände

Eins der Probleme, dass von dem oben erwähnten Bach-Stück angeregt wurde, ist die Einstellung der Abstände. Der Formatierer beherrscht den optischen Ausgleich. Das soll des Beispiel unten beleuchten:

In diesem Ausschnitt kommen nur Viertel vor, Noten, die in einem gleichmäßigen Rhythmus gespielt werden. Die Abstände sollten das wiederspiegeln. Leider lässt uns aber das Auge im Stich: es beachtet nicht nur den Abstand von aufeinanderfolgenden 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 unter ohne. In letzterem Fall bilden sich für das Auge bei unten/oben-Folgen Notenklumpen mit schmalen Abständen zwischen den Notenhälsen.

Hilfslinien

Hilflinien sind typographisch schwierig. Sie können leicht mit anderen Zeichen verschmelzen, wie etwa anderen Hilfslienien oder Vorzeichen. Andere Programme lösen dieses Problem, indem sie die Notenzeichen weiter auseinander setzen (so dass sie mehr Platz brauchen), oder indem sie die Hilflinien generell kürzen (wodurch die Lesbarkeit behindert wird).


Henle (2000)	Bärenreiter (1950)	LilyPond (2004)

Notenstecher der alten Schulen würden die Länge der Hilfslinie abhängig von den umgebenden Symbolen anpassen. LilyPond unternimmt das gleiche. Hilfslinien werden verkürzt, so dass sie nicht mit umgebenden Linien zusammenstoßen, und sie werden verkürzt wenn vor der Note ein Vorzeichen steht.

Weiter: Das Eingabeformat oder Wie wird eigentlich gesetzt

Das Eingabeformat

Wie oben besprochen liegt dem Eingabeformat der Inhalt, also die Musik, zu Grunde. Damit aber entsteht ein großes Problem: Wie können wir denn definieren, was Musik eigentlich ist? Wir nähern uns der Lösung von hinten. Anstatt zu definieren, was Musik ist, lassen wir unser Programm als Definition gelten. Wir schreiben ein Programm, das Noten setzen kann, und halten das Format so einfach wie möglich. Wenn das Format nicht mehr abgespeckt werden kann, bleibt nur noch der reine Inhalt übrig.

Die Syntax ist gleichzeitig die Benutzerschnittstelle bei LilyPond, darum soll sie einfach zu schreiben sein; z. B. bedeutet

  c'4 d'8

eine Viertel c' und eine Achtel d', wie in diesem Beispiel:

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 Open oder Symphonien notieren? Diese Struktur wird gewährleistet durch sog. „music expressions“ (Musikausdrücke): indem kleine Fragmente zu größeren kombiniert werden, kann mehr Komplexität ausgedrückt werden. So etwa hier:

c4

Gleichzeitig erklingende Noten werden hinzugefügt, indem man alle in << und >> einschließt.

<<c4 d4 e4>>

Um aufeinanderfolgende Noten darzustellen, werden sie in Klammern gefasst:

{ <<c4 d4 e4>> f4 }

Dieses Gebilde ist in sich wieder ein Ausdruck, und kann daher mit einem anderen Ausdruck kombiniert werden (hier mit einer Halben).

<< { <<c4 d4 e4>> f4 } g2 >>

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 ist es eine Frage des Geschmackes und auch ein Objekt vieler Diskussionen. 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:

Analyse + Darstellung gesamt

6000 Zeilen C++ 61500 Zeilen C++

Analyse + Darstellung	gesamt
6000 Zeilen C++	61500 Zeilen C++

Weiter: So kann es also gehen, ein Schlusswort

Schlusswort

Wir konnten hier zeigen, wie guter Notensatz aussehen sollte und wie wir unser Programm gestaltet haben, damit es dieses Aussehen nachahmt. Wir haben uns viel Mühe gegeben, um es zu programmieren. Dank all der Bemühungen kann nun jeder dieses Programm benutzen, um selber schönen Notensatz zu erhalten.

Als Ergänzung zu diesem Aufsatz können Sie sich die Publikationen anschauen, die zum Thema LilyPond geschrieben worden sind. Besonders hervorzuheben sind die drei Artikel von Andrew Hawryluk über einen Vergleich des Notensatzes von LilyPond und Finale.

Zurück zum Inhalt


Bärenreiter (BA 350, © 1950)	Henle (Nr. 666 © 2000)