Entwicklung einer DSL zur Komposition von Jazz

Bachelorarbeit
Felix Jensen
Entwicklung einer DSL zur Komposition von Jazz-Musik
Fakultät Technik und Informatik
Studiendepartment Informatik
Faculty of Engineering and Computer Science
Department of Computer Science
Felix Jensen
Entwicklung einer DSL zur Komposition von Jazz-Musik
Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung
im Studiengang Bachelor of Science Angewandte Informatik
am Department Informatik
der Fakultät Technik und Informatik
der Hochschule für Angewandte Wissenschaften Hamburg
Betreuender Prüfer: Prof. Dr. Sarstedt
Zweitgutachter: Prof. Dr. Fohl
Eingereicht am: 15. März 2016
Felix Jensen
Thema der Arbeit
Entwicklung einer DSL zur Komposition von Jazz-Musik
Stichworte
Domänenspezifische Sprache, DSL, Jazz, Notation, Musik
Kurzzusammenfassung
Während für klassische Musik zumeist eine sehr präzise Notationsform gewählt wird, werden
im Jazz häufig nur wenige Aspekte eines Stücks notiert. Die in diesem Genre üblichen Notationsformen sind für das Medium Papier ausgelegt und sind für Rechner schwer einzulesen,
obwohl diese bei der Komposition sehr hilfreiche Werkzeuge sein können. Daher soll in dieser
Arbeit ein System zur Notation von Musikstücken und der Interaktionen mit ihnen vorgestellt
werden, dessen Fokus auf Jazz-Musik liegt.
Felix Jensen
Title of the paper
Development of a DSL for Jazz-Music Composition
Keywords
domain-specific language, DSL, Jazz, notation, music
Abstract
While the usual approach to music notation in the classical context is very detailed, in jazz
music the notation is often much less precise. The common ways of notation in this genre are
designed to be written on paper and are hard to read for computers, even though they could
be a very helpful tool for composition. That is why this paper presents a system for notation
of musical pieces in the genre of jazz and for interaction with them.
Inhaltsverzeichnis
1. Einleitung
1.1. Motivation und Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
2. Grundlagen
2.1. Musikalische Grundbegriffe . . . . . . . . .
2.1.1. Stammtöne . . . . . . . . . . . . . .
2.1.2. Tonleitern . . . . . . . . . . . . . . .
2.1.3. Das Ionische System . . . . . . . . .
2.1.4. Akkorde . . . . . . . . . . . . . . . .
2.1.5. Skalentheorie und Stufendreiklänge
2.2. Musiknotation . . . . . . . . . . . . . . . . .
2.2.1. Moderne westliche Notenschrift . . .
2.2.2. Akkordsymbolschrift . . . . . . . . .
2.2.3. Leadsheet . . . . . . . . . . . . . . .
2.2.4. Notation mit Stufenakkorden . . . .
2.3. Domain-Specific Languages . . . . . . . . .
2.3.1. Interne DSL . . . . . . . . . . . . . .
2.3.2. Externe DSL . . . . . . . . . . . . . .
2.4. Grammatik . . . . . . . . . . . . . . . . . . .
2.5. Von der Eingabe zur Datenstruktur . . . . .
2.5.1. Syntax-Directed Translation . . . . .
2.5.2. Parsebaum . . . . . . . . . . . . . . .
2.5.3. Abstract Syntax Tree . . . . . . . . .
2.5.4. Semantic Model . . . . . . . . . . . .
2.5.5. Compiler und Interpreter . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
4
4
5
6
7
7
9
9
11
12
12
13
14
15
15
15
16
17
18
3. Analyse
3.0.1. Anforderungen .
3.1. Vorhandene Lösungen .
3.1.1. Notationsbeispiel
3.1.2. Lilypond . . . . .
3.1.3. Sonic Pi . . . . .
3.1.4. iReal Pro . . . . .
3.2. Fazit . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
20
20
21
24
26
28
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
4. Entwurf
4.1. Konzept . . . . . . . . . . . . . . . . . . . .
4.2. Anwendungsfälle . . . . . . . . . . . . . .
4.2.1. Notation eines Musikstückes . . .
4.2.2. Laden eines Musikstückes . . . . .
4.2.3. Speichern eines Musikstückes . . .
4.2.4. Abspielen eines Musikstückes . . .
4.3. Datenmodell . . . . . . . . . . . . . . . . .
4.3.1. Semantic Model . . . . . . . . . . .
4.3.2. Datenmodell des Softwaresystems
4.4. Grammatikentwurf . . . . . . . . . . . . .
4.4.1. Struktur der Sprache . . . . . . . .
4.4.2. Titel, Autor und Geschwindigkeit .
4.4.3. Tonart . . . . . . . . . . . . . . . .
4.4.4. Akkorde . . . . . . . . . . . . . . .
4.4.5. Progressions . . . . . . . . . . . . .
4.4.6. Figures . . . . . . . . . . . . . . . .
4.4.7. Structure . . . . . . . . . . . . . . .
4.4.8. Rhythm . . . . . . . . . . . . . . .
4.5. Systemkontext . . . . . . . . . . . . . . . .
4.6. Systemstruktur . . . . . . . . . . . . . . .
4.7. Komponenten . . . . . . . . . . . . . . . .
4.7.1. Song . . . . . . . . . . . . . . . . .
4.7.2. REPL . . . . . . . . . . . . . . . . .
4.7.3. Parser . . . . . . . . . . . . . . . .
4.7.4. Player . . . . . . . . . . . . . . . .
4.8. Fazit . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
32
32
33
34
35
36
37
38
39
39
40
40
40
41
41
41
42
42
43
44
44
45
49
51
51
5. Implementierung und Auswertung
5.1. Programmiersprache und Bibliotheken . . . . . . . . . . . . . . . . . . . . .
5.2. Modellierung in funktionaler Programmierung . . . . . . . . . . . . . . . . .
5.3. Audioausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4. DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5. Stand der Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6. Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.1. Improvisation und Komposition im Einklang . . . . . . . . . . . . .
5.6.2. Eine Notenschrift mit musiktheoretischer Basis . . . . . . . . . . . .
5.6.3. Ein ausgewogenes Verhältnis von Informationsdichte und Lesbarkeit
5.6.4. Unterstützung bei Notation und Improvisation durch den Computer
5.7. Verbesserungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.1. DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.2. System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
52
53
54
54
54
54
55
55
55
56
56
56
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
6. Fazit
57
A. Anhang
58
Literaturverzeichnis
59
vi
1. Einleitung
1.1. Motivation und Zielsetzung
Ein großer Bestandteil des Alltags vieler Musiker ist das Lesen und Notieren von Musik. In
der klassischen Musik sind Stücke oft akribisch bis ins letzte Detail ausnotiert, was es den
Interpreten ermöglicht, sie mit allen Nuancen nachzuspielen. In anderen Musikrichtungen
wird es mit der Notation nicht so genau genommen. Ein besonderes Beispiel ist der Jazz.
Die Jazz-Musik lebt in ihrem Wesen von Veränderung und Individualität. Die Improvisation
ist ein wesentlicher Bestandteil, der einen großen Teil des Jazz ausmacht. Gleichzeitig hat
er ein breites Fundament an theoretischen Grundlagen, die dem Musiker beim Musizieren
helfen können. Aber bei aller Freiheit kommt der Jazz dennoch nicht ohne die Musiknotation
aus. Dabei die gleiche Notationsform wie die klassischen Musik zu nutzen würde ihm aber
nicht gerecht werden. Daher wird hier oft eine andere Form gewählt, beispielsweise die des
Leadsheets.
In der heutigen Zeit sind Computer in jedem Haushalt zu finden und Kommunikation findet
häufig darüber statt. Dagegen wurden die meisten bekannten Notationsformen noch vor den
ersten Rechnern erfunden. Sie sind darauf ausgelegt, gut auf Papier notiert und gelesen zu
werden. So können sie von einem Rechner nur schwierig eingelesen und interpretiert werden.
Die Verwendung eines Computers könnte bei der Notation und Arbeit mit einem Musikstück
aber auf verschiedene Art hilfreich sein.
Das Ziel dieser Arbeit ist daher die Entwicklung eines Systems zur Notation von Jazz-Musik,
in dessen Zentrum eine Domain-Specific Language (engl. Domänenspezifische Sprache, DSL)
steht. Beim Entwurf der Sprache sollen die wesentlichen Eigenschaften des Jazz beachtet
werden. Darüberhinaus soll die interaktive Arbeit mit einem notierten Musikstück möglich
sein und die enthaltenen Informationen des Stücks zum Abspielen genutzt werden können.
Damit soll erreicht werden, dass die notierte Musik als Basis zur Improvisation dienen kann.
Das Ziel der Arbeit ist nicht, eine vollständige Abbildung aller möglichen Objekte der
musikalischen Domäne in eine Sprache zu bringen, sondern eine elegante Lösung für die in
1
1. Einleitung
der Jazz-Musik wesentlichen Elemente zu finden. Auch eine harmonische Analyse soll hier
nicht durchgeführt werden.
1.2. Gliederung der Arbeit
In Kapitel 2 werden zunächst einige musikalischen Grundbegriffe erläutert. Anschließend werden verschiedene Formen der Musiknotation besprochen. Außerdem erfolgt eine Einführung
in Domain-Specific Languages.
Kapitel 3 beginnt mit einer Beschreibung der Anforderungen an das System. Anschließend
erfolgt eine Überprüfung vorhandener Lösungen. In Kapitel 4 wird ein Konzept für eine Lösung
vorgestellt und anschließend eine Architektur dieser Lösung erstellt.
Als nächstes folgt das Kapitel 5, in dem auf einige Implementierungsdetails eingegangen
wird. Anschließend wird in einer Auswertung ein Vergleich zwischen den Anforderungen
aus der Analyse und dem hier vorgestellten System durchgeführt. Dann werden noch einige
Verbesserungsmöglichkeit vorgestellt. Das Kapitel 6 schließt die Arbeit mit Fazit ab.
2
2. Grundlagen
2.1. Musikalische Grundbegriffe
Im folgenden werden einige Grundbegriffe der Musik erläutert, die zum Verständnis dieser
Arbeit benötigt werden. Die hier beschriebenen Informationen basieren auf den Werken Neue
Jazz-Harmonielehre von Frank Sikora (Sikora, 2012), sowie Die neue Harmonielehre von Frank
Haunschild (Haunschild, 1998).
2.1.1. Stammtöne
In der Musiktheorie werden Töne in sieben Stammtöne (A, B, C, D, E, F, G) gegliedert. Diesen
Stammtönen sind Frequenzen zugeordnet. Bei der Verdoppelung der Frequenz wird von einer
Oktave gesprochen. Die Oktave eines Tons hat denselben Namen, wobei die einzelnen Oktavräume zur Differenzierung vorangestellte Beiwörter besitzen. Die Oktavräume gehen vom Ton
C aus und haben von tiefer Tonhöhe ausgehend die Namen Subkontra-Oktave, Kontra-Oktave,
große Oktave, kleine Oktave, und ein- bis fünfgestrichene Oktave. (vgl. Grabner, 2011, S. 7)
Im deutschen wird das B mit H bezeichnet. Da sich die Arbeit aber auf Jazz bezieht und es dort
üblich ist, die internationale Schreibweise zu verwenden, wird hier ebenfalls die internationale
Schreibweise verwendet.
Der Tonabstand zwischen den einzelnen Stammtönen ist unterschiedlich. Die kleinstmögliche Tonabstand wird Halbtonschritt genannt. Zwischen den Tonschritten A-B, C-D, D-E, F-G
und G-A beträgt der Tonabstand jeweils einen Ganzton, zwischen B und C, sowie E und F
einen Halbton. Mit Hilfe von Versetzungszeichen können Stammtöne um einen Halbtonschritt
erhöht (durch ein „]“), bzw. erniedrigt (durch ein „[“) werden. Dadurch ergibt sich ein gesamtes
Tonspektrum von zwölf Tönen (A, A], B, C, C], D, D], E, F, F], G, G]).
Der Abstand zwischen zwei Tönen wird als Intervall bezeichnet. Dieser Abstand wird
in Halbtönen gemessen, wobei jedes dieser Intervalle einen festgelegten Namen hat. Eine
Auflistung der Intervalle mit ihren Namen ist im Buch Die neue Harmonielehre von Frank
Haunschild zu finden. (Haunschild, 1998, S.34)
3
2. Grundlagen
2.1.2. Tonleitern
Eine Menge von Tönen innerhalb einer Oktave kann als Tonleiter bezeichnet werden. Die Folge
jedes einzelnen der zwölf in einer Oktave enthaltenen Töne wird als chromatische Tonleiter
bezeichnet. Reiht man die Stammtöne zu einer Folge auf, so erhält man von C ausgehend
die siebentönige C-Dur-Tonleiter, von A ausgehend die A-Moll-Tonleiter. Um die Dur- und
Moll-Tonleiter auf andere Grundtöne zu übertragen, kann man die Skalen als Intervallreihen
darstellen:
dur
moll
1
1
2
2
3
[3
4
4
5
5
6
[6
7
[7
8
8
Tabelle 2.1.: Struktur von Dur- und Moll-Tonleitern als Intervallreihen
In Tabelle 2.1 erkennt man, dass die Intervalle zwischen den einzelnen Stufen in der DurTonleiter unterschiedlich sind als in der Moll-Tonleiter. Nimmt man die hier aufgelisteten
Intervalle und legt diese auf einen Grundton, so erhält man eine Dur- oder Moll-Tonleiter in
der entsprechenden Tonart. (vgl. Sikora, 2012, S. 41ff)
2.1.3. Das Ionische System
In der Jazz-Harmonielehre werden neben den Dur- und Moll-Tonleitern noch weitere Tonleitern
verwendet. Diese wurden von dem mittelalterlichen System der Kirchentonarten abgeleitet
und bilden das Ionische System.
Im Ionischen System werden sieben Modi von einer Dur-Tonleiter abgeleitet. Ausgehend
von der ersten Stufe der C-Dur-Tonleiter erhält man die Ionische Skala C-Ionisch, die der
Dur-Tonleiter entspricht. Ausgehend von der sechsten Stufe erhält man A-Äolisch, was den
gleichen Tönen wie A-Moll entspricht. Außerdem gibt es noch dorisch, phrygisch, lydisch,
mixolydisch und lokrisch (vgl. Haunschild, 1998, S. 69).
Abbildung 2.1.: Modi im Ionischen System
4
2. Grundlagen
Abbildung 2.1 zeigt die unterschiedlichen Modi, die mit dem Tonmaterial von C-Ionisch von
unterschiedlichen Stufen ausgehend möglich sind.
2.1.4. Akkorde
Als Akkord bezeichnet man mehrere gemeinsam klingende Töne. Die einfachste Art eines
Akkords ist ein Dreiklang. Dabei wird von einem Grundton ausgehend eine Note im Terzabstand
hinzugefügt. Fügt man von dieser Note ausgehend eine weitere Terz hinzu, ergibt es einen
Dreiklang. Dabei ist in den Intervallen das Muster Prim - Terz - Quinte erkennbar. Dadurch,
dass es zwei unterschiedliche Arten von Terzen gibt, die große und die kleine Terz, gibt es
somit vier verschiedene Arten von Dreiklängen: Dur, Moll, Übermäßig und Vermindert.
Abbildung 2.2.: Arten von Dreiklängen
Den Akkorden werden je nach Literatur und Musikrichtung unterschiedliche Symbole
zugeordnet. Im Jazz wird vorwiegend folgende Notation verwendet:
Akkordtyp
Dur (major)
Moll (minor)
Vermindert (diminished)
Übermäßig (augmented)
Symbol
C
CCo
C+
Intervallstruktur
1–3–5
1 – [3 – 5
1 - [3 – [5
1 – 3 – ]5
Tabelle 2.2.: Akkordgrundtypen
Fügt man diesen Dreiklängen jeweils eine weitere Terz hinzu, so erhält man eine Reihe von
Vierklängen. Eine Ausnahme ist der Quartvorhalt (engl. suspended fourth), bei dem die große
Terz durch die reine Quarte ersetzt wird.
Abbildung 2.3.: Vierklänge
5
2. Grundlagen
Akkordtyp
großer Septakkord (major 7)
Dominantseptakkord (dominant)
Mollseptakkord (minor 7)
Moll-Major-7 (minor major 7)
Halbverminderter Septakkord (halfdiminished)
Verminderter Septakkord (diminished 7)
Quartvorhalt (suspended 4)
Symbol
C47
C7
C-7
C-47
Cø7 / C-7([5)
Co 7
C7(sus4)
Intervallstruktur
1–3–5–7
1 – 3 – 5 – [7
1 – [3 – 5 – [7
1 – [3 – 5 – 7
1 – [3 – [5 – [7
1 – [3 – [5 – [[7
1 – 4 – 5 – [7
Tabelle 2.3.: Akkordgrundtypen
Darüber hinaus können mithilfe weiterer Töne viele weitere Akkorde erzeugt werden. Dabei
hat jedes Intervall zum Grundtons des Akkords eine entsprechende Bezeichnung bzw. ein
Symbol.
Intervallname
kleine Sekunde
große Sekunde
übermäßige Sekunde
kleine Terz
große Terz
reine Quarte
übermäßige Quarte
verminderte Quinte
reine Quinte
übermäßige Quinte
kleine Sexte
große Sexte
verminderte Septime
kleine Septime
große Septime
Symbol
[9
9, add9
]9
- oder o
Dur oder +
sus4, 11
]11
[5, bei o enthalten
bei Dur und Moll enthalten
]5, bei + enthalten
[6, [13
6, 13
o7
7
maj7, 47
Tabelle 2.4.: Intervalle und deren Bezeichnung im Akkordsymbol
2.1.5. Skalentheorie und Stufendreiklänge
Bildet man auf den Stufen einer Dur-Tonleiter Dreiklänge, die nur aus den Tönen der jeweiligen
Tonleiter bestehen, so erhält man eine Reihe von leitereigenen Akkorden. Ihnen werden
vom Grundton ausgehend die römischen Zahlen I bis VII zugeordnet. Sie werden auch als
Stufendreiklänge oder allgemeiner als Stufenakkorde bezeichnet.
6
2. Grundlagen
Abbildung 2.4.: Stufendreiklänge der C-Dur-Tonleiter
Die Tabellen 2.2 und 2.3 basieren auf (Sikora, 2012, S.30). Die Tabelle 2.4 basiert auf (Sikora,
2012, S. 32) und (Haunschild, 1998, S. 56).
2.2. Musiknotation
In der Musik gibt es verschiedene Systeme, um Stücke zu notieren. Bei der Notation sind je
nach Musikrichtung unterschiedliche Informationen wichtig. Im folgenden werden einige
übliche Notationssysteme vorgestellt.
2.2.1. Moderne westliche Notenschrift
Die bekannteste Notationsform ist die moderne Notenschrift. In ihr können Musikstücke
sehr präzise aufgezeichnet werden. Ihr Kernelement ist das Notensystem, bestehend aus fünf
Linien, einem Notenschlüssel, sowie weiteren Informationen wie Tempo, Tonart, Taktart und
Dynamik.
Die einzelnen Stammnoten werden abgebildet auf die Linien und dazwischenliegenden
Zwischenräume. Je höher eine Note in diesem System liegt, desto höher ist ihr Ton. Die konkrete
Tonhöhe wird durch den Notenschlüssel festgelegt. Die Tonlänge wird durch verschiedene
Notensymbole bestimmt. Eine ganze Note wird mittels eines leeren Kreises dargestellt und sie
hat den Notenwert von vier Viertelnoten.
Eine halbe Note erhält zusätzlich einen Strich. Ihr Notenwert entspricht zwei Viertelnoten.
Bei einer Viertelnote wird der Kreis zusätzlich gefüllt.
7
2. Grundlagen
Abbildung 2.5.: Moderne westliche Notation
In Abbildung 2.5 sieht man zwei Notensysteme, die mit einer Klammer verbunden sind. So
werden üblicherweise Klaviernoten notiert. Das obere der Systeme enthält die Noten für die
rechte Hand, das untere die für die linke. Die Tonhöhe des Notensystems wird durch einen
Notenschlüssel festgelegt. Im oberen System wird der Violinschlüssel (1) verwendet, der besagt,
dass die zweite Linie von unten auf den Ton g’ festgelegt wird. Im unteren System wird der
Bassschlüssel (2) genutzt. Hier ist die vierte Linie von unten mit dem Ton f definiert.
Hinter dem Notenschlüssel folgt die Angabe der Vorzeichen. Auf der F-Linie befindet sich
ein ] (3). Es sorgt dafür, dass alle f-Noten automatisch zu f] werden. Diese Angabe deutet
zudem auf daraufhin, dass das Stück in der Tonart G-Dur ist.
Nach der Angabe der Vorzeichen folgt die Taktart, in diesem Fall ein Viervierteltakt (4).
Jeder Takt enthält vier Viertelnoten, wobei der Akzent auf dem ersten liegt, und ein weiterer
etwas schwächerer auf der dritten.
Das Tempo wird oberhalb des Notensystems angegeben (5). Neben einer meist italienischen
Tempobezeichnung gibt es in modernen Stücken oft eine genauere Angabe in Beats per Minute
(BPM). In diesem Fall hat das Lied 120 Viertelnoten pro Minute.
Im unteren Notensystem ist eine Folge von Viertelnoten notiert (6). Es handelt sich um
einzelne Töne, die nacheinander gespielt werden. im oberen Notensystem sind ausschließlich
Akkorde notiert. Der erste Akkord (7) ist ein G6 in der 1. Umkehrung, bestehend aus den Noten
b, d, e und g.
Über dem Notensystem ist außerdem noch der Titel (8) und der Komponist (9) des Stücks
angegeben.
8
2. Grundlagen
Neben den oben angegebenen Informationen können noch viele weitere Parameter angegeben werden, wie beispielsweise Dynamik, Taktart- und Tempoänderungen, Haltebögen und
andere Hinweise, die der Komponist für wichtig hält. So ist es möglich, ein Lied genauso zu
notieren, wie es gespielt werden soll.
2.2.2. Akkordsymbolschrift
Während die Notenschrift für die Notation klassischer Musik sehr gut geeignet ist, werden
in vielen moderneren Musikrichtungen, wie dem Blues oder Jazz, Improvisationen wichtiger.
Des weiteren gibt es hier häufig begleitende Spuren, die primär aus dem Notenmaterial eines
Akkords zur Zeit bestehen. Hier wäre die konventionelle Notenschrift zu einschränkend und
zu aufwändig zu lesen und schreiben. Stattdessen verwendet man eine Akkordsymbolschrift.
Hierin werden den einzelnen Akkordtypen Symbole zugeordnet: Ein Akkordsymbol besteht aus
dem Grundton des Akkords (groß geschrieben), gefolgt von einem oder mehreren Symbolen.
Akkordsymbole werden über das Notensystem an der Position geschrieben, an der der
Akkord gespielt werden soll. Dabei reicht auch bei einer Folge von mehreren Takten desselben
Akkords das einmalige Notieren des Akkordsymbols aus. (vgl. Sikora, 2012, S. 29ff)
Je nach Literatur werden für Akkordtypen unterschiedliche Symbolalternativen verwendet.
Abbildung 2.6.: Beispiel eines Notation in Akkordsymbolschrift
In Abbildung 2.6 ist beispielhaft die Notation eines Stücks nur mit Akkordsymbolen gezeigt.
2.2.3. Leadsheet
Das Leadsheet verbindet die Akkordsymbolschrift mit der konventionellen Notation. Dabei
wird nur die Melodie eines Stückes in Notenform notiert. Die verwendete Akkordfolge wird
9
2. Grundlagen
zusätzlich über die Takte geschrieben. Da Leadsheets auch als Improvisationsgrundlage dienen,
sind die Informationen bewusst vage gehalten. Dies bedeutet, dass sowohl Melodie als auch
Akkordfolge vereinfacht dargestellt sein kann (vgl. Sikora, 2012, S. 64).
Abbildung 2.7.: Leadsheet-Notation
Im Abbildung 2.7 ist das Beispielstück in Leadsheet-Notation angegeben. Die Begleitung
wird mithilfe der Akkordsymbolnotation über den Takten angegeben. Im Notensystem ist
eine Melodie in einer simplen Form angegeben. Die konkrete Spielart der Begleitung ist frei
wählbar, solange die angegebenen Akkorde gespielt werden.
10
2. Grundlagen
2.2.4. Notation mit Stufenakkorden
Nutzt man nur leitereigene Akkorde, ist es möglich, diese mittels der jeweiligen Stufe zu
notieren. In dieser Notationsart werden die Stufenakkorde der Stufentheorie mit der Akkordsymbolschrift verbunden. Beispielsweise würde in der Tonart C-Dur der Akkord C4 als I4
oder 14 notiert werden.
Abbildung 2.8.: Notation mit Stufenzahl der Akkorde
Ein Vorteil dieser Notation ist, dass man Akkordfolgen unabhängig von einer konkreten
Tonart notieren kann. Dies ermöglicht die Analyse auf einer abstrakteren Ebene.
11
2. Grundlagen
2.3. Domain-Specific Languages
In diesem Abschnitt sollen die wichtigsten für diese Arbeit relevanten Grundlagen zum Thema
Domain-Specific Languages beschrieben werden. Der Abschnitt basiert auf dem Werk DomainSpecific Languages von Martin Fowler Fowler (2010).
Eine domain-specific language (DSL) oder domänenspezifische Sprache ist eine Programmiersprache, die auf ein bestimmtes Anwendungsfeld ausgerichtet ist. Martin Fowler beschreibt
in dem Buch Domain-Specific Languages vier Eigenschaften von DSLs:
• Computer programming language: Eine DSL ist eine für Menschen verständliche Sprache,
die dazu genutzt wird, einen Computer dazu anzuleiten, etwas zu tun.
• Language nature: Die Ausdruckskraft einer Sprache kommt nicht nur von einzelnen
Ausdrücken, sondern auch aus dem Zusammenhang mehrerer Ausdrücke.
• Limited expressiveness: Im Gegensatz zu einer general-purpose programming language (GPL, engl. universell einsetzbaren Programmiersprache) unterstützt eine DSL nur
diejenigen Funktionalitäten, die in dem jeweiligen Einsatzfeld benötigt werden.
• Domain focus: Der Fokus einer DSL liegt auf einer kleinen Domäne. Sie sollte nicht mehr
als diese Domäne abbilden.
DSLs werden als Werkzeug eingesetzt, um eine Problemdomäne verständlich beschreiben
zu können. Da sie nur die Probleme einer Domäne enthalten, können Experten dieser Domäne
sie ohne besonderes Zusatzwissen bedienen. Es wird zwischen internen und externen DSL
unterschieden.
2.3.1. Interne DSL
Eine interne DSL ist eine Sprache, die innerhalb eine vorhandene universell einsetzbare Programmiersprache eingebettet ist. Sie nutzen eine Untermenge der Funktionalität der Wirtssprache. Somit ist ein gültiges Programm einer internen DSL auch ein gültiges Programm ihrer
Wirtssprache. Die interne DSL sieht ihrer Wirtssprache oft nur noch bedingt ähnlich, da die
für die Wirtssprache charakteristischen Kontrollstrukturen häufig nicht mehr sichtbar sind.
Ein Vorteil in der Nutzung einer internen DSL ist, dass der Implementationsaufwand im
Vergleich zu einer externen DSL geringer ist, da kein Parser entwickelt werden muss. Innerhalb
eines Softwaresystems kann die Verwendung einer DSL in bestimmten Einsatzgebieten den
12
2. Grundlagen
Code besser lesbar machen. Ein Beispiel für eine interne DSL ist Rake1 , ein Build-ManagementWerkzeug, dass als Wirtssprache Ruby verwendet.
Abbildung 2.9.: Ein Beispiel einer DSL zur Musiknotation in einem Lisp-Dialekt
Abbildung 2.9 stellt eine mögliche interne DSL in einem Lisp-Dialekt dar. Die für Lisp
charakteristische Klammersetzung muss weiterhin durchgeführt werden, aber die einzelnen
Elemente der Sprache sind auch für Benutzer lesbar, die keine Erfahrung mit Lisp haben.
2.3.2. Externe DSL
Eine externe DSL ist eine DSL, die von anderen Sprachen unabhängig ist. Die Syntax kann
somit von den Entwicklern frei gewählt werden. Ein in einer DSL entwickeltes Programm wird
üblicherweise von der Parserkomponente eines Softwaresystems eingelesen und dort dann
weiterverarbeitet. Da im Vergleich zur internen DSL die Wirtssprache fehlt, müssen alle für die
Sprache gewünschten Funktionalitäten selbst implementiert werden. Dafür ist die Syntax dann
befreit von den Einschränkungen der Wirtssprache. Im Beispiel der Lisp-DSL in Abbildung 2.9
1
https://github.com/ruby/rake
13
2. Grundlagen
könnten so zum Beispiel die Klammern wegfallen. Auch für die Akkordsymbole könnte eine
geeignetere Notation gewählt werden.
2.4. Grammatik
Eine formale Grammatik ist eine Form zur Beschreibung der Struktur einer Programmiersprache. Sie beschreibt lediglich die syntaktischen Regeln der Sprache. Eine kontextfreie Grammatik
besteht aus einer Menge von Ersetzungsregeln, und einem Startsymbol und jeweils einer Menge
von Terminalsymbolen und Nichtterminalsymbolen. Eine Ersetzungsregel besteht aus einer
linken Seite und einer rechten Seite. Die linke Seite enthält genau ein Nichtterminalsymbol,
die rechte Seite beschreibt mögliche Ersetzungen. Dies können weitere Nichtterminale oder
Terminale sein.
Zur Darstellung einer kontextfreien Grammatik wird zumeist die erweiterte Backus-NaurForm (EBNF) verwendet. Sie erlaubt die Notation der Ersetzungsregeln. (vgl. Grune u. a., 2000,
S. 34-40)
Abbildung 2.10.: Darstellung einer Grammatik zur Notation von Akkordfolgen in der EBNF
Abbildung 2.10 zeigt eine simple Grammatik zur Notation von Akkordfolgen, notiert in
der EBNF. In Zeile 2 wird eine Ersetzungsregel beschrieben, die den Aufbau eines Akkords
definiert. ein Akkord besteht aus einem Grundton, gefolgt von einem optionalen Dreiklangsymbol. Der Grundton wiederum besteht aus einem Ton und einem Versetzungszeichen. Ein
Fragezeichen bedeutet, dass das vorstehende Symbol optional ist. Zeile 6 erläutert, dass ein
Versetzungszeichen entweder eine Raute oder ein b sein kann. Diese Alternative wird durch
den senkrechten Strich markiert.
Zeile 1 sagt aus, dass eine Akkordfolge aus einem Akkord gefolgt von beliebig vielen weiteren
Akkorden bestehen kann. Wenn ein oder beliebig viel mehr von einem Symbol kommen soll,
14
2. Grundlagen
kann auch das Plus verwendet werden. Symbole in Anführungszeichen sind Terminalsymbole,
die anderen sind Nichtterminalsymbole.
Eine für die dargestellte Grammatik gültige Eingabe könnte folgendermaßen aussehen: C+
D#-.
2.5. Von der Eingabe zur Datenstruktur
Im folgenden wird der Ablauf von der Eingabe eines Programms bis zur fertig eingelesenen
Datenstruktur beschrieben. Zur Veranschaulichung werden die einzelnen Schritte anhand des
Beispiels C+ D#- mit Grafiken versehen.
2.5.1. Syntax-Directed Translation
Eine EBNF kann dazu benutzt werden, mithilfe eines Parsergenerators einen Parser zu erzeugen.
Dies wird syntax-directed translation (engl., Syntaxgesteuerte Übersetzung) genannt.
Vor dem Parse-Vorgang steht die Lexikalische Analyse, die von einem Lexer durchgeführt
wird. Er liest einen eingehenden Text ein und erkennt Grundelemente der Sprache, wie Operatoren, Schlüsselwörter und Bezeichner. Anschließend reicht er sie weiter an den Parser.
Dieser wandelt anhand seiner Grammatik die Folge von Schlüsselwörtern in eine neue Struktur
um, sofern die Syntax korrekt ist. Diese Struktur wird dann verwendet, um eine zur Sprache
gehörende semantische Analyse durchzuführen und entsprechende Aufgaben durchzuführen.
2.5.2. Parsebaum
Das Ergebnis eines Parse-Vorgangs ist ein Parsebaum (engl. Parsetree). Er stellt die Eingabe als
Baum dar, wobei jedes Element dem entsprechenden Grammatiksymbolen zugeordnet ist. Ein
Parsebaum ist zur weiteren Verarbeitung der Eingabe nützlich, ist in der Regel aber für die
semantische Analyse noch nicht optimal geeignet.
15
2. Grundlagen
Abbildung 2.11.: Parsebaum für die Grammatik von Akkordfolgen
Ein Beispiel für einen Parsebaum ist in Abbildung 2.11 zu sehen. Als Blätter sind einzelne Teile
der Eingabe zu erkennen. Ihre Elternknöten entsprechen den in der Grammatik vorgegebenen
Übergangsregeln.
2.5.3. Abstract Syntax Tree
Ein Abstrakter Syntaxbaum (AST, engl. Abstract Syntax Tree) ist eine weitere Darstellung der
Eingabe als Baum. Er wird aus einem Parsebaum erzeugt, in dieser umgeformt wird. Dabei
werden für die weitere Verarbeitung unnötige Knoten entfernt. Auch können Strukturen
verändert und so vereinheitlicht werden. Es ist nicht unüblich, dass vom Weg vom Parsebaum
zur entgültigen Repräsentation mehrere Zwischenformate verwendet werden.
16
2. Grundlagen
Abbildung 2.12.: Ein möglicher AST für die Grammatik von Akkordfolgen
In der Abbildung 2.12 sieht man, wie im Vergleich zum Parsebaum einige Knoten entfernt
wurden. Die Entscheidung, welche Knoten behalten, welche verworfen und welche verändert
werden sollen, ist je nach Sprache und Nutzen unterschiedlich und muss individuell getroffen
werden.
2.5.4. Semantic Model
Ein Semantic Model (engl., semantisches Modell) ist eine Darstellung der Domäne als Datenstruktur. Es wird dazu verwendet, den Sachverhalt in einer GPL darzustellen. Es wird nach
dem Parsen aus dem AST befüllt. Anschließend kann eine semantische Prüfung durchgeführt
werden, um sicherzustellen, dass die Eingabe auch semantisch korrekt ist.
Der Aufbau des Semantic Models ist abhängig von der zukünftigen Verwendung. Es kann
schon vor der Grammatik erstellt werden, sollte spätestens aber parallel zur Grammatik entwickelt werden.
17
2. Grundlagen
Abbildung 2.13.: Semantic Model zur Darstellung von Akkordfolgen
Das Semantic Model für die Beispielgrammatik ist in Abbildung 2.13 zu sehen. Es zeigt den
Aufbau der Thematik, wie es in objektorientierter Programmierung implementiert werden
könnte.
2.5.5. Compiler und Interpreter
Ein Compiler ist ein Programm zur Übersetzung der Eingabe in einer Sprache in eine ausführbare Form. Das Resultat ist also ein ausführbares Programm in einer anderen Sprache. Ein
Interpreter liest ebenfalls die Eingabe ein, führt sie aber sofort aus. Bei beiden muss neben der
syntaktischen Analyse auch eine semantische Analyse erfolgen, um die Gültigkeit der Eingabe
sicherzustellen.
Auch wenn die Benutzung der beiden Programme unterschiedlich ist, so kann häufig trotzdem dieselbe Komponente zum Einlesen genutzt werden. Ein Vorteil eines Compilers ist, dass
durch die Umwandlung in eine andere Sprache eine große Anzahl von Optimierungen möglich
ist. Der Interpreter dagegen läuft innerhalb einer Laufzeitumgebung und ist daher langsamer.
Dafür kann er sich die von der Laufzeitumgebung angebotenen Funktionalitäten zunutze
machen.
18
3. Analyse
Dieses Kapitel befasst sich mit der Analyse der eingangs genannten Problemstellung. Dabei sollen zunächst einige Anforderungen vorgestellt werden, die im Vordergrund zur Bewertung und
Entwicklung einer Lösung stehen. Anschließend werden vorhandene Lösungen auf Eignung
für die Problemstellung untersucht.
3.0.1. Anforderungen
Um den Rahmen des zu entwickelnden Systems festzulegen, wurden einige Anforderungen
erarbeitet, die hier vorgestellt werden sollen. Sie dienen als Grundlage zur Bewertung von
vorhandenen Lösungen und zur Erstellung eines Entwurfs.
Sikora schreibt in seinem Buch Neue Jazz-Harmonielehre, dass eine Notenschrift die Musik
reflektieren müsse, die sie darzustellen versucht (Sikora, 2012, S. 29). Im Jazz sind die Anforderungen an eine Notationssprache anders als in der klassischen Musik, da hier Improvisation
und Komposition in einem besonderen Verhältnis zueinander stehen. Die klassische Notation
ist sehr präzise, während es im Jazz improvisatorischen Freiraum geben muss.
Bei der Entwicklung einer DSL soll einen Sachverhalt in eine für den Computer verständliche
Form zu bringen. Auch hier ist eine hohe Präzision notwendig, damit die Eingabe vom Computer
so interpretiert wird, wie sie gemeint ist. Die in dieser Arbeit zu entwickelnde Lösung soll die
für den Jazz so wichtige Kombination von Improvisation und Komposition ermöglichen, ohne
dabei in eine sehr förmliche und techniknahe Syntax zu rutschen. Stattdessen soll die Notation
auf den musiktheoretischen Grundlagen des Jazz aufbauen.
Die Notationsform eines Musikstücks muss eine Reihe verschiedener Informationen beinhalten, damit es vom Leser verstanden und interpretiert werden kann. Dazu gehören zum Beispiel
Tempo, Tonart, Titel und natürlich die Akkordfolge. Je nach Umfang des Stücks können aber
auch Strukturinformationen von Bedeutung sein, aber auch Dynamik- oder Stilangaben. Im
Gegensatz zu der Fülle an möglichen und benötigten Informationen steht das Bedürfnis, ein
Stück möglichst schnell und knapp notieren zu können. Dies ist schon deshalb von Interesse,
da der kreative Vorgang eines Musikers nicht planbar ist, und spontane Ideen schnell notiert
19
3. Analyse
werden müssen, damit sie nicht vergessen werden. Dabei soll die Syntax trotzdem lesbar und
verständlich sein.
Während die Notation eines Musikstücks auf dem Papier nur die Interpretation des geschriebenen durch einen Musiker zulässt, bietet die Eingabe in einen Computer mehr Möglichkeiten.
Die Notation eines Musikstücks ist schließlich auch in der Regel nicht Notation der Notation wegen, sondern hat den Zweck der Speicherung oder Weitergabe des Liedes, oder auch
als Grundlage zur Improvisation und Weiterentwicklung. Die Fähigkeiten eines Computers
können hier auf verschiedene Arten zur Unterstützung bei der Erarbeitung und Interpretation
eines Stückes angewendet werden. Eine besonders interessante Art der Unterstützung sieht
der Autor dabei im Abspielen des Stückes. Sie hilft bei der Notation, indem durch Anhören der
geschriebenen Musik geprüft werden kann, ob das Ergebnis erreicht wurde, was dem Musiker
vorschwebt. Darüber hinaus kann dann die notierte Musik zur Begleitung für die Improvisation
dienen.
Daraus lassen sich einige Kernanforderungen ableiten, die im folgenden zur Besprechung
vorhandener Lösung und zum Entwurf einer eigenen Lösung genutzt werden:
• Improvisation und Komposition im Einklang
• eine Notenschrift mit musiktheoretischer Basis
• ein ausgewogenes Verhältnis von Informationsdichte und Lesbarkeit
• Unterstützung bei Notation und Improvisation durch den Computer
3.1. Vorhandene Lösungen
Im Folgenden sollen einige vorhandenen Lösungen für die oben genannte Problemstellung
auf die in Abschnitt 3.0.1 genannten Anforderungen hin untersucht werden. Dabei wird die
Lösung jeweils kurz beschrieben. Anschließend wird ein Beispiel der Notation gegeben und
schließlich wird überprüft, ob die Lösung den Anforderungen entspricht.
3.1.1. Notationsbeispiel
Zur Besprechung der Notation wird in jeder der in diesem Kapitel vorgestellten Lösungen ein
Notationsbeispiel gegeben. Um eine gewisse Vergleichbarkeit zu gewährleisten, wird in jedem
Beispiel der in Abbildung 3.1 gezeigte Notenausschnitt nachgestellt. Das Beispiel ist nicht
unbedingt repräsentativ für die Notation ganzer Stücke, die in der Notenschrift über mehrere
20
3. Analyse
Seiten gehen können. Die Angabe einer so umfangreichen Notation würde den Rahmen dieser
Arbeit sprengen.
Abbildung 3.1.: Notationsbeispiel in moderner westlicher Notation
3.1.2. Lilypond
LilyPond1 ist eine Notensatz-Software, deren Ziel es ist, eine möglichst hohe Qualität im
Bereich des Notendrucks zu erreichen. Die Software nutzt dabei zur Eingabe von Musik eine
textbasierte Sprache.
1
http://lilypond.org
21
3. Analyse
Abbildung 3.2.: Beispiel einer modernen Notation in LilyPond mit zwei Notensystemen
Abbildung 3.2 zeigt die Notation der ersten drei Takte des Musikstücks. Die Ausgabe dieser
Notationsart ist eine moderne westliche Notation mit je einer Spur für die linke und die rechte
Hand zum Spiel auf einem Klavier. Zunächst wird ein Part für die rechte Hand definiert. Mithilfe
des Befehls
relative c’ wird festgelegt, dass der Inhalt des folgenden Blockes in geschweiften Klammern
in der Tonhöhe bei c’ liegt. Innerhalb des Blockes werden Noten mit deren Namen notiert.
Hinter dem Notennamen wird mit einer Zahl die Notenlänge bestimmt. Eine 1 steht dabei für
22
3. Analyse
eine ganze Note, eine 2 für eine halbe, und so weiter. Wenn an einer Note keine Notenlänge
angegeben ist, so übernimmt sie den Wert der vorherigen Note.
Im Fall der rechten Hand (Zeilen 2-4) sind ausschließlich Akkorde notiert. Sie werden Diese
werden mithilfe der Zeichen < und > gruppiert. Die Zeichenfolge <b d e g>1 bedeutet somit,
dass hier ein G6-Akkord in der dritten Ableitung notiert ist, der die Dauer einer ganzen Note
hat.
In der linken Hand (Zeilen 6-8) sind ausschließlich einzelne Viertelnoten zu sehen. Während
die Noten zu Beginn im Bereich der Note c liegen, wird in Zeile 7 mit der Eingabe c, die Tonhöhe
um eine Oktave abgesenkt. Das g zu Beginn der Zeile 8 ist trotzdem in derselben Oktave wie
das zu Beginn von Zeile 6. Das liegt daran, dass bei der Wahl der Tonhöhe von der vorherigen
Note ausgegangen und die nähere Oktave verwendet wird.
Im Beispiel sieht man auch den Einsatz von Variablen. Die Spuren der linken und rechten
Hand werden jeweils der Variablen lhMusic bzw. rhMusic zugeordnet. Diese Variablen werden
später innerhalb des score-Blocks mittels \lhMusic und \rhMusic verwendet.
Innerhalb des score-Blocks wird ein PianoStaff mit zwei Staffs definiert. Innerhalb dieser Staffs werden Tempo und Tonart festgelegt und anschließend mithilfe der Variablen die
jeweiligen Noten eingefügt.
Abbildung 3.3.: Beispilnotation eines Leadsheets in Lilypond
23
3. Analyse
LilyPond unterstützt neben der Erzeugung klassischer Notation auch die Ausgabe als Leadsheets. In Abbildung 3.3 ist die Notation eines Leadsheets zu sehen. Im chords-Block wird die
Akkordnotation festgelegt. Hierfür gibt es neben der oben bereits genannten Form für Akkorde
noch den sogenannten chord mode. In diesem ist es möglich, eine besondere Syntax für Akkorde
zu verwenden. Wie im Beispiel zu sehen, wird hinter dem Grundton des Akkords mithilfe eines
Doppelpunktes ein Akkordtyp angehängt, in diesem Fall die 6 für einen Sextakkord. Zusätzlich
zu dem ersten Akkordtyp können mit einem Punkt separiert weitere Töne hinzugefügt und
mit einem ^ entfernt werden.
Die beiden Notationsformen sind strukturell unterschiedlich. Dies wird dadurch ermöglicht,
dass LilyPond fehlende Befehle zur Strukturierung automatisch hinzufügt.
Die Noteneingabe in LilyPond ist mit etwas Übung und mithilfe der umfangreichen Dokumentation2 in angemessener Zeit zu erledigen. Neben den hier genannten Notationsformen,
bietet die Sprache weit mehr, vor allem in Bezug auf Notensatz. Der kreative Prozess zur
Schaffung der Musik ist bei LilyPond zeitlich vor der Notation einzuordnen. Die Notation wird
mittels Symbolen für Akkorde und Töne durchgeführt, womit die Nähe zur Theorie gegeben
ist. Es gibt keine Möglichkeit zur Improvisation oder zum Abspielen der Noten, aber sie können
in andere Formate exportiert werden und so in anderen Programmen geöffnet werden. Eine
direkte Unterstützung bei der Notation oder Komposition ist dabei aber nicht gegeben. Die
Kernkompetenz von LilyPond liegt im Notensatz.
3.1.3. Sonic Pi
Sonic Pi3 ist ein Live Coding Synthesizer, der als Eingabesprache eine interne DSL in der
Programmiersprache Ruby verwendet. Das Ziel dieser Software ist, eine Plattform zum Lernen
von Programmierung und Musik zu bieten und gleichzeitig mächtig genug zu sein, um als
Instrument für professionelle Musiker zu dienen.
Bei Sonic Pi liegt die Erzeugung von elektronischer Musik im Vordergrund, die bevorzugt als
improvisierter Auftritt erfolgt. Die Struktur eines Stücks wird in der Regel nicht explizit notiert,
sondern ergibt sich während des Auftritts durch Veränderungen im Quellcode. Dabei könnte
ein Stück damit beginnen, dass eine Bassdrum einen Takt definiert. Anschließend könnte eine
harmonische Untermalung auf Basis einer E-Moll-Tonleiter erfolgen, deren Abfolge mithilfe
eines Zufallsgenerators gesteuert wird.
2
3
http://lilypond.org/doc/v2.18/Documentation/web/index.html
http://sonic-pi.net
24
3. Analyse
Ein weiteres Element könnte eine ebenfalls zufallsgenerierte Melodie sein. Abschließend
werden nacheinander die Melodiespur, die Harmoniespur und die Bassdrum ausgeschaltet und
das Lied beendet.
Um eine solche Folge zu erstellen, wird für jede der Spuren eine Endlosschleife in einem eigenen Thread erzeugt, in der Töne abgespielt und anschließend eine bestimmte Zeit geschlafen
wird. Wenn eine Spur ausgeschaltet werden soll, muss die Endlosschleife im Code terminiert
werden. Anschließend wird dieser Part des Quellcodes neu evaluiert und nach dem nächsten
ausführen der Schleife wird sie verlassen.
Abbildung 3.4.: Sequenzielle Notation in Sonic Pi
Eine Notation, die der westlichen Notation mehr ähnelt, sieht man in Abbildung 3.4. In den
ersten Zeilen wird das Tempo auf 120 BPM gesetzt, anschließend werden einige Variablen für
die einzelnen Tonlängen definiert. In Zeile 7 wird ein neuer Thread erzeugt, der den folgenden
Block ausführt. Mithilfe der sleep und der play_chord-Funktionen ist es möglich, das Abspielen
der Töne zeitlich zu platzieren. Zeilen 9 bis 11 beschreiben den ersten Takt.
Die sleep-Aufrufe entsprechen jeweils einer Pause. play_pattern_timed erwartet zwei Listen,
wobei die erste die zu spielenden Töne enthält und die zweite Pausenwerte enthält, die jeweils
zwischen den Tönen eingehalten werden. Sonic Pi hat für die gängigsten Töne Symbole definiert
25
3. Analyse
(z. B. :C4), welche auch von den Funktionen verstanden werden. Diese Symbole stehen für
Ganzzahlen, die den Midi4 -Noten des Tons entsprechen. Da es keine vordefinierten Symbole
für erhöhte oder erniedrigte Töne gibt, wird hier für den Ton D] der Notenwert von :D4 um
eins erhöht.
Zur Darstellung von Akkorden nutzt Sonic Pi Funktionen. Die Funktion chord(tonic, name)
erwartet einen Grundton und Akkordtypen. Für die üblichsten Akkordtypen gibt es Symbole
(z. b. :major), komplexere können mittels eines Strings notiert werden. Anders als in LilyPond
sind diese Akkordtypen jedoch fest vorgegeben; einzelne Töne hinzufügen oder entfernen
geht über diese Syntax nicht. Da Akkorde allerdings als Listen von Tönen zu verstehen sind,
kann man diese nachträglich manuell bearbeiten oder sich eigene Akkorde definieren.
Ähnlich wie die chord-Funktion gibt es auch eine Funktion scale(tonic, name), die anhand
eines Grundtons und eines Skalennamens eine Tonleiter als Liste von Tönen zurückgibt. So ist es
beispielsweise möglich, eine zufallsgenerierte Tonfolge innerhalb einer Tonleiter abzuspielen.
Da Sonic Pi eine interne DSL in Ruby verwendet, ist es möglich, alle üblichen Features der
Programmiersprache zu verwenden. Somit ist es auch möglich, eigene Funktionen zu schreiben,
und so die Funktionalität und Lesbarkeit nach eigenen Wünschen zu erweitern.
Sonic Pi ist für Musiker ohne Programmiererfahrung nur mit sorgfältiger Einarbeitung
nutzbar. Die Software enthält ein eingebautes Hilfesystem, das ein umfangreiches Tutorial, eine
Reihe von Beispielen und eine Sprachreferenz enthält. Neben einigen Funktionen für Akkorde
und Skalen bietet Sonic Pi nur wenige Schnittpunkte zur klassischen Notation. Dafür ist es
möglich, die Mächtigkeit einer Programmiersprache zu nutzen, womit eine sehr dynamische
und kreative Komponier- und Notationsform möglich ist.
Eine schnelle Notation ist für den geübten Nutzer in einer individualisierten Umgebung
möglich, erfordert allerdings Erfahrung in der Programmierung. Das technische Umfeld der
Sprache birgt die Gefahr, dass sich der Nutzer in der komplexen Syntax verliert, statt sich mit
den musikalischen Aspekten zu befassen. Durch die Möglichkeit, Tonleitern, Akkorde und
Tonfolgen abspielen zu können, kann man diese als Grundlage für Improvisation, wie auch als
Unterstützung bei der Notation nutzen.
3.1.4. iReal Pro
iReal Pro5 ist ein Werkzeug zur Begleitung eines Musikers beim Üben und zum Improvisieren.
Die Software besteht im wesentlichen aus einer Liste von Liedern und einer Abspielkomponente,
4
5
Musical Instrument Digital Interface. Ein Protokoll zum Austausch von musikalischen Steuerinformationen.
http://irealpro.com
26
3. Analyse
mit der man das Lied in verschiedenen Stilen, Tempi und Tonarten spielen kann. Es ist auch
möglich, die Instrumentierung zu beeinflussen.
Abbildung 3.5.: Die Notationsoberfläche von iReal Pro
Neben den voreingestellten Liedern gibt es auch die Möglichkeit, eigene Lieder zu notieren.
Die Notation erfolgt dabei in einer graphischen Notationssprache. Abbildung 3.5 zeigt die
Benutzeroberfläche, die zur Notation verwendet wird. Auf der rechten Seite ist das zu bearbeitende Dokument. Hier können in einer Art Raster Symbole platziert werden. Die Symbole
werden mittels Klicken auf das jeweilige Icon links an der aktuellen Stelle eingefügt. Neben
Symbolen, die aus der westlichen Notation bekannt sind, gibt es noch einige, die für Anweisungen an die Abspielkomponente benötigt werden. Für Akkorde gibt es ein Textfeld, in das man
die Akkorde notieren kann. Außerdem ist hier ein Auswahlmenü, dass nach Eingabe eines
Grundtons alle möglichen Akkorde anzeigt.
27
3. Analyse
Weitere Informationen, die zur Erstellung eines Liedes nötig sind, sind Titel, Komponist und
Tonart, die in die entsprechenden Felder auf der linken Seite des Editors eingetragen werden.
Mit dem Style-Feld kann ein Stil des Players ausgewählt werden.
Erstellte Lieder werden von der Community über ein Forum geteilt. Neben einem eigenen
Dateiformat können sie auch als PDF, Audiodatei oder MusicXML exportiert werden. Außer
der zur Notation verwendeten Ansicht gibt es noch die Möglichkeit, die Noten in anderer
Form darzustellen. Für Nutzer von Klavier, Gitarre und Ukulele gibt können die Akkorde
mit Griffbrett- bzw. Tastaturdiagrammen angezeigt werden. Außerdem gibt es die Number
Notation, in der die Akkorde in der Stufe der Tonleiter notiert werden.
Die Notation eines Liedes in iReal Pro ist relativ schnell erledigt, die Sprache ist größtenteils
selbsterklärend. Eine Möglichkeit zur Notation von Melodien gibt es nicht. Die Abspielkomponente ermöglicht ein sofortiges Anhören der notierten Akkordfolge und lädt zur Improvisation
ein. Die Anzahl der möglichen Abspielstile ist jedoch relativ klein, eine eigene Veränderung
dieser Stile ist nicht möglich. Die Notation als Text und außerhalb der Software ist nicht
möglich.
3.2. Fazit
In diesem Kapitel wurden zunächst einige Anforderungen an mögliche Lösungen vorgestellt.
Diese Anforderungen lassen sich in den folgenden Stichpunkten zusammenfassen.
• Improvisation und Komposition im Einklang
• eine Notenschrift mit musiktheoretischer Basis
• ein ausgewogenes Verhältnis von Informationsdichte und Lesbarkeit
• Unterstützung bei Notation und Improvisation durch den Computer
Anschließend wurden drei verschiedene vorhandene Lösungen besprochen. In Abschnitt
3.1.2 wurde LilyPond vorgestellt, eine Notensatzsoftware mit mächtiger Texteingabesprache zur
Notation. Ihre Stärken liegen im Notensatz, Unterstützung bei Komposition oder Improvisation
gibt es keine. Dafür ist die Syntax der eigentlichen Musiknotation gut lesbar, wenn auch die
Strukturierung zu Verwirrungen führen kann.
Abschnitt 3.1.3 zeigte mit Sonic Pi eine interne DSL in Ruby, die als Kernkompetenz Livecoding hat. Außerdem hat sie als Ziel, Grundlagen in Musikerzeugung und Programmierung
zu vermitteln. Sie macht es relativ leicht, algorithmische Musik zu machen. Wenn man Programmierung beherrscht, hat man ein mächtiges Werkzeug. Das Abspielen der Noten ist eine
28
3. Analyse
zentrale Funktionalität der Software. Die Nähe der Syntax an allgemeiner Programmierung
kann allerdings abschreckend wirken.
Zuletzt wurde in Abschnitt 3.1.4 die Software iReal Pro vorgestellt. Sie bietet eine Abspielkomponente mit verschiedenen Stilrichtungen und der Möglichkeit, das Tempo, die Instrumentierung und die Tonart zu ändern. Die Lieder werden in einer graphischen Akkordnotation
niedergeschrieben. Dadurch, dass es sich um eine graphische Sprache handelt, ist der Benutzer
auf die Anwendung einer Maus gebunden, dafür muss er sich aber keine Syntax merken. Die
Flexibilität der unterschiedlichen Abspielstile ist eingeschränkt, da es nicht sehr viele gibt und
sie nicht angepasst werden können.
29
4. Entwurf
Aus den in Kapitel 3 beschriebenen Anforderungen und den dort vorgestellten vorhandenen
Lösungen kann ein Konzept für ein Notationssystem erstellt werden, das im folgenden vorgestellt werden soll. Anschließend werden die wichtigsten Anwendungsfälle beschrieben. Zum
Verständnis der Strukturen wird dann das Datenmodell des Systems beschrieben. Daraufhin
werden die Designentscheidungen in Bezug auf die Grammatik erklärt. Dann folgt ein Blick
auf den Systemkontext und die Systemstruktur, gefolgt von einer genaueren Untersuchung
der zu entwickelnden Komponenten.
4.1. Konzept
Das folgende Konzept hat zum Ziel, die bereits vorgestellten Anforderungen zu erfüllen. Der
Name des Systems lautet Jazzler.
In der Jazz-Musik spielen Improvisation und Komposition eine ebenbürtige Rolle. Dies soll
von dem hier vorgestellten System berücksichtigt werden, indem die Notation auf Akkordfolgen beschränkt ist. Melodien sind zwar ein Teil der Jazzmusik, können aber zugunsten der
Improvisation in den Hintergrund treten.
Es soll sich bei der DSL um eine textliche Form handeln. Dies liegt darin begründet, dass
eine textuelle Sprache schnell zu nutzen ist, wenn die Syntax gut verständlich ist. Außerdem
kann die Notation so auch ohne die notwendige Software erfolgen. Die Wahl fällt zudem auf
die Form einer externen DSL. Dies hat den Grund, dass die Syntaxelemente einer Wirtssprache
ablenkend wären und die Ästhetik beeinflussen würden.
Die Notation der Musik soll auf Basis musiktheoretischer Grundlagen erfolgen. Dies soll
durch die Verwendung einer Akkordsymbolnotation erfolgen, die den existierenden Notationsformen ähnelt. Dadurch kann das vorhandene Wissen genutzt werden, um in geeigneter Form
Akkordfolgen zu notieren. Die Akkorde sollen zudem in römischen Zahlen notiert werden,
die ihre Stufe in der Tonleiter darstellen. Dies ermöglicht eine Sicht auf die musikalischen
Zusammenhänge und ermöglicht die schnelle Änderung der Tonart ohne du Nutzung eines
Transponierungswerkzeugs.
30
4. Entwurf
Die Strukturierung eines Liedes kann je nach Art recht kompliziert werden und Wiederholungen beinhalten. Um die Syntax einfach zu halten und die Struktur leicht sichtbar zu machen,
soll in der Notation ein Element zur Strukturierung vorhanden sein. Akkordfolgen sollen in
verschiedene Figuren aufgeteilt werden, die anschließend in einer Liedstruktur in eine Abfolge
gebracht werden sollen. Dies ermöglicht auch, den Aufbau eines Stücks schnell zu ändern,
ohne die konkreten Akkordfolgen bearbeiten zu müssen.
Die Notation der Musik soll durch eine interaktive Umgebung unterstützt werden. Dazu
wird als Benutzerschnittstelle eine REPL (Read-eval-print Loop) verwendet. Sie liest Befehle
ein, wertet sie aus und gibt ein Ergebnis zurück. Sie wird dazu genutzt, nach und nach ein
Musikstück zu erstellen und mit diesem zu interagieren. Neben der Funktionalität zur Notation
des Stückes soll es eine Möglichkeit zum Abspielen des notierten Liedes geben. Das ermöglicht
die Überprüfung der Stückes, wie auch die Improvisation auf dessen Grundlage. Eine Skizze
der Oberfläche ist in Abbildung 4.1 zu sehen.
Abbildung 4.1.: Ansicht der REPL-Oberfläche mit einigen Beispieleingaben
Um das Stück und dessen Interpretation weiter zu präzisieren, soll es möglich sein, den
Rhythmus festzulegen. Lieder haben oft eine weitgehend einheitliche Form des Rhythmus
über viele Takte hinaus, während einige wenige Takte rhythmische Veränderungen enthalten.
Die rhythmische Notation soll daher an verschiedenen Stellen möglich sein: Auf Ebene des
gesamten Liedes, im Rahmen einer Akkordfolge und für einzelne Takte. Um das Abspielen
von Anfang an zu ermöglichen, sollen im Fall fehlender Elemente im Lied auf Standardwerte
zurückgegriffen werden.
Ein Zweck der Notation ist die Speicherung einer Idee oder eines Liedes. Dafür soll eine
Speicherfunktion eingebaut werden, die die Musik als Klartext in eine Datei ablegt und bei
31
4. Entwurf
Bedarf wieder lädt. Der Text soll dabei der Syntax der Grammatik entsprechen, was die Notation
eines Liedes außerhalb der REPL ermöglicht.
4.2. Anwendungsfälle
Im folgenden Abschnitt werden die wesentlichen Anwendungsfälle des zu beschreibenden
Systems beschrieben.
4.2.1. Notation eines Musikstückes
Die Notation eines Musikstückes besteht aus mehreren Schritten. Die wesentlichen Informationen über ein Stück umfassen Titel, Komponist, Tonart, Figuren und Struktur des Stückes, sowie
Rhythmusinformationen auf verschiedenen Ebenen. Da die Abläufe in diesen verschiedenen
Formen der Eingabe sehr ähnlich sind, wird hier nur ein Anwendungsfall beschrieben, der
exemplarisch für die anderen steht.
32
4. Entwurf
Titel:
Notation einer Akkordfolge als Figur
Akteur:
Musiker
Ziel:
Notation einer Akkordfolge als Figur
Auslöser:
Der Musiker hat eine Akkordfolge, die er notieren und als Figur speichern möchte.
Vorbedingungen:
Das System ist gestartet.
Nachbedingungen:
Die Akkordfolge ist als Figur in einem Lied im System geladen.
Erfolgsszenario:
1. Der Musiker gibt in der Syntax der Sprache eine Akkordfolge als Figur ein.
2. Das System prüft die Befehlsstruktur und prüft, ob es sich um einen Befehl der REPL
oder der Sprache handelt.
3. Das System liest die Eingabe ein und prüft die Syntax anhand der Sprache.
4. Das System speichert die Figur und die Akkordfolge in einer Liedstruktur.
5. Das System überprüft die Liedstruktur auf semantische Korrektheit.
6. Das System übernimmt die Liedstruktur als Basis für weitere Eingaben.
Erweiterungen:
2a. Falls ein Fehler in der Befehlsstruktur auftritt, wird ein entsprechender Fehler angezeigt
und der Befehl verworfen.
3a. Falls ein Fehler in der Syntax auftritt, wird dieser dem Musiker angezeigt und die
Befehlsausführung abgebrochen.
5a. Falls die Liedstruktur ungültig ist, wird der Fehler dem Benutzer angezeigt und die
Liedstruktur verworfen.
Tabelle 4.1.: Anwendungsfall: Notation einer Akkordfolge als Figur
4.2.2. Laden eines Musikstückes
Der folgende Anwendungsfall beschreibt das Öffnen eines Musikstückes aus einer Datei.
33
4. Entwurf
Titel:
Laden eines Musikstückes
Akteur:
Musiker
Ziel:
Laden eines Musikstückes aus einer Datei in das System
Auslöser:
Musiker hat eine Datei, die ein Lied enthält und möchte dies ins System laden.
Vorbedingungen:
System ist gestartet und hat kein Lied geladen. Die Datei enthält Lieddaten.
Nachbedingungen:
Das Lied ist im System geladen.
Erfolgsszenario:
1. Der Musiker führt unter Angabe eines Dateipfades und eines Dateinamens den Ladebefehl aus.
2. Das System prüft die Befehlsstruktur.
3. Das System öffnet die Datei und liest sie ein.
4. Das System erzeugt aus den gelesenen Daten eine Liedstruktur.
5. Das System überprüft die semantische Korrektheit der Liedstruktur.
6. Das System zeigt dem Musiker die Liedstruktur an.
Erweiterungen:
2a. Falls ein Fehler in der Befehlsstruktur auftritt, wird ein entsprechender Fehler angezeigt
und der Befehl verworfen.
3a. Falls ein Fehler beim Lesen der Datei auftritt, wird er dem Benutzer angezeigt und der
Ladevorgang abgebrochen.
5a. Falls die Liedstruktur ungültig ist, wird der Fehler dem Benutzer angezeigt und die
Liedstruktur verworfen.
Tabelle 4.2.: Anwendungsfall: Laden eines Musikstückes
4.2.3. Speichern eines Musikstückes
Die Speicherung eines Liedes in einer Datei wird im folgenden beschrieben.
34
4. Entwurf
Titel:
Akteur:
Ziel:
Auslöser:
Vorbedingungen:
Nachbedingungen:
Erfolgsszenario:
Speichern eines Musikstückes
Musiker
Festschreiben eines Musikstückes auf ein Speichermedium
Musiker hat eine Musikstück im System notiert und möchte dies speichern.
Das System ist gestartet und hat eine Liedstruktur geladen.
Das Musikstückes ist auf einem Speichermedium gespeichert.
1. Der Musiker führt unter Angabe eines Dateipfades und eines Dateinamens den Speicherbefehl aus.
2. Das System prüft die Befehlsstruktur.
3. Das System erstellt eine Datei mit dem Dateinamen unter dem gegebenen Dateipfad und
schreibt die Informationen des Musikstückes in diese Datei.
4. Das System informiert den Benutzer über den Erfolg des Speicherns.
Erweiterungen:
2a. Falls ein Fehler in der Befehlsstruktur auftritt, wird ein entsprechender Fehler angezeigt
und der Befehl verworfen.
3a. Falls ein Fehler beim Speichern der Datei auftritt, wird er dem Benutzer angezeigt und
der Speichervorgang abgebrochen.
Tabelle 4.3.: Anwendungsfall: Speichern eines Musikstückes
4.2.4. Abspielen eines Musikstückes
Zum Abspielen eines Musikstückes mithilfe des Systems sind die im folgenden Anwendungsfall
aufgelisteten Schritte notwendig.
35
4. Entwurf
Titel:
Abspielen eines Musikstückes
Akteur:
Musiker
Ziel:
Abspielen eines im System geladenen Musikstückes
Auslöser:
Der Musiker hat ein Musikstück im System notiert und möchte es abspielen.
Vorbedingungen:
Das System ist gestartet und hat eine Liedstruktur geladen.
Nachbedingungen:
Das System hat das Musikstück abgespielt.
Erfolgsszenario:
1. Der Musiker führt den Abspielbefehl aus.
2. Das System prüft die Befehlsstruktur.
3. Das System erzeugt anhand der geladenen Liedstruktur eine Abfolge von Abspielinformationen.
4. Das System sendet die Abspielinformationen an die Abspielkomponente.
5. Die Abspielkomponente spielt das Lied ab.
Erweiterungen:
2a. Falls ein Fehler in der Befehlsstruktur auftritt, wird ein entsprechender Fehler angezeigt
und der Befehl verworfen.
3a. Falls nicht alle für das Abspielen notwendigen Informationen in der Liedstruktur enthalten sind, verwendet das System dafür Standardwerte.
Tabelle 4.4.: Anwendungsfall: Laden eines Liedes
4.3. Datenmodell
Zur Entwicklung eines Softwaresystems ist die Modellierung eines Datenmodells sinnvoll.
Im Fall von Jazzler setzt sich diese aus zwei wesentlichen Teilen zusammen: Das für die
Speicherung eines Musikstückes notwendige Semantic Model, und der Aufbau generellen
Software.
36
4. Entwurf
4.3.1. Semantic Model
Abbildung 4.2.: Semantisches Datenmodell für ein Musikstück
Für die Darstellung des Semantic Model wurde ein UML-Klassendiagramm gewählt. Das
Kernstück ist der Song. Dieser enthält neben Informationen wie Titel, Komponist und Abspieltempo auch die Tonart (Key), welcher aus einem Grundton und einer Modus besteht. Alle
möglichen Figures werden in einer Liste gehalten. Mit dem Feld Structure wird der Ablauf des
Liedes beschrieben, der durch eine Reihe von Figures realisiert wird. Die Figures müssen im
Song erstellt worden sein, bevor sie in der Structure benutzt werden können.
Eine Figure stellt ein Liedsegment dar. Sie besteht aus einem Namen und einer Progression.
Ein Beispiel für eine Figure könnte ein Refrain sein. Die Progression stellt eine Reihe von
aufeinanderfolgenden Takten dar, die hier als Bar gespeichert werden. Ein Bar wiederum hat
eine Taktnummer und eine Anzahl von Akkorden.
Ein Akkord besteht aus root, quality, interval und fifth. Root ist dabei der Grundton, quality
entspricht der Bezeichnung eines Dreiklangs. Das interval-Feld wird für die Darstellung eines
37
4. Entwurf
Vierklangs verwendet. Das Feld fifth enthält Informationen, ob die Quinte erhöht oder vermindert ist, oder durch eine sus4 ersetzt werden soll. Ein C-7[5-Akkord wird folgendermaßen
aufgeteilt: Root ist das C; quality entspricht dem -, also minor; interval enthält ein Symbol für
ein dom7 und fifth enthält die Information, dass die Quinte vermindert ist.
Ein Rhythmus-Objekt kann sowohl zu einer Figure, als auch zu einer Bar, als auch zum
gesamten Lied gehören. Beim Abspielen kann auf jeder Ebene geprüft werden, ob ein Rhythmus
vorhanden ist. Ansonsten wird auf der nächst höheren Ebene nachgeschaut.
4.3.2. Datenmodell des Softwaresystems
Abbildung 4.3.: Datenmodell der REPL
Abbildung 4.3 zeigt das Datenmodell des Systems. Die REPL enthält neben einigen Feldern
für Rückgaben eine StateMachine. Sie enthält einen aktuellen State und eine aktuelle Transition,
sowie eine Liste von allen möglichen States. Ein State ist ein Zustand der StateMachine, hat
einen Namen und wird durch eine Funktion realisiert. Außerdem hat sie eine Anzahl von
möglichen Transitions. Eine Transition ist ein Zustandsübergang. Sie hat einen Namen und
einen Zielzustand. Außerdem enthält die REPL einen Song. Dieser entspricht dem in Abschnitt
4.3.1 vorgestellten Semantic Model.
38
4. Entwurf
4.4. Grammatikentwurf
Zur Beschreibung der für die Notation eines Stückes verwendete Sprache, soll im folgenden
Abschnitt ein Überblick über die Grammatik erfolgen. Nach einer kurzen Übersicht der Struktur
folgen genauere Erklärungen zu einzelnen Bestandteilen der Sprache.
Bei dem Entwurf der Grammatik wurde wert darauf gelegt, dass eine gewisse Abstraktion
angewendet wird, die dazu führt, dass eine Wiederholung derselben Elemente selten auftritt,
wodurch Änderungen leichter durchzuführen sind und die Liedstruktur von einer gehobenen
Position dargestellt wird.
4.4.1. Struktur der Sprache
Bevor die einzelnen Elemente der Sprache im Detail besprochen werden, folgt hier eine kurze
Übersicht der Sprachstruktur.
Zunächst gibt es Befehle für das Notieren von Autor und Titel, sowie Geschwindigkeit und
Tonart des Stücks. Um Akkordfolgen zu notieren, gibt es Progressions. Sie werden mit einer
Klammernotation angegeben und stellen eine Abfolge von Akkorden auf verschiedenen Stufen
dar. Die Akkorde innerhalb der Progressions werden mittels einer Akkordsymbolnotation
notiert.
Progressions werden bei der Definition von Figures verwendet. Diese geben einer Progression
einen Namen und sind verwendbar in der Festlegung der Struktur eines Musikstückes. Damit
aus einer Sammlung von Figures ein Stück wird, kann eine Structure definiert werden. Sie legt
den Ablauf des Musikstückes und damit eine Reihenfolge der Figures fest.
Mithilfe eines Rhythmus-Blockes kann eine Progression, ein Takt oder auch das gesamte
Stück mit einer rhythmischen Präferenz versehen werden. Rhythmusblöcke werden mit geschweiften Klammern notiert. Die Trennung von rhythmischen und harmonischen Werten hat
die Absicht, dass die jeweiligen Werte so in andere Zusammenhänge gebracht werden können.
39
4. Entwurf
Abbildung 4.4.: Sprachbeispiel
Ein Beispiel für ein in dieser Sprache notiertes Musikstück ist in Abbildung 4.4 zu sehen. Es
beginnt mit der Notation von Titel, Komponist und Geschwindigkeit des Stückes. Anschließend
wird die Tonart festgelegt und der allgemeine Rhythmus des Stückes auf vier Anschläge der
Länge einer Viertelnote definiert. In den Zeilen 7 und 8 werden jeweils eine Figure erzeugt. In
der letzten Zeile wird die Struktur des Liedes festgelegt.
4.4.2. Titel, Autor und Geschwindigkeit
Um den Titel des Stücks festzulegen, gibt es das Keyword Title:, auf das ein String folgen muss.
Ähnlich steht es um den Komponisten, der mit dem Keyword Composer: und einem String
definiert wird. Die Geschwindigkeit des Stücks kann mit dem Schlüsselwort Tempo: und einem
darauffolgenden Integer-Wert gesetzt werden.
4.4.3. Tonart
Die Tonart besteht aus einem Grundton und einem Modus. Zum Festlegen der Tonart gibt es
das Keyword Key:. In Abbildung 4.4 wird gezeigt, wie die Tonart auf G-Dur festgelegt wird. Da
die Anzahl der möglichen Modi sehr groß ist, wird sich in dieser Arbeit auf die Tonleitern des
Ionischen Systems, sowie Dur und Moll beschränkt.
4.4.4. Akkorde
Die Modellierung der Akkorde ist aufgrund der großen Flexibilität der üblichen Akkordsymbole
etwas aufwändiger. Ein Akkordsymbol besteht üblicherweise aus einem Grundton, gefolgt von
40
4. Entwurf
einem Teil, der im englischen chord quality genannt wird. Darauf folgt eine Intervallnummer,
zuletzt eine Veränderung der Quinte oder eine sus4.
Um eine leichte Änderung der Tonart zu ermöglichen, wird anstelle des Grundtons die
römische Zahl der Stufe des Akkords in der Tonleiter verwendet.
Die hier verwendete Akkordschrift bildet nicht alle möglichen Akkorde ab, da nur eine
Intervallnummer notiert werden kann. In Jazz kommen jedoch auch komplexere Akkorde vor.
Um den Umfang der Arbeit nicht zu sprengen, wird hier auf eine genauere Darstellung der
Akkorde verzichtet.
4.4.5. Progressions
Akkordfolgen werden hier Progressions genannt. Um Progressions zu notieren, soll es möglich
sein, mehrere Takte zu notieren und dabei kein starres Format zu fordern. Außerdem müssen
sowohl Takte mit nur einem Akkord notiert werden können, als auch Takte, die einen oder
mehrere Akkordwechsel enthalten. Um dies zu ermöglichen, wird die Akkordfolge von eckigen
Klammern umschlossen. Innerhalb dieser Klammern können Takte notiert werden. Wenn ein
Takt mit nur einem Akkord gefüllt wird, so kann er mit der Notation des Akkords notiert
werden. Wenn mehrere Akkorde im Takt enthalten sind, so wird der Takt mittels eines weiteren
eckigen Klammernpaares dargestellt, in das beliebig viele Akkorde eingefügt werden können.
4.4.6. Figures
Die Notation eines Stücks erfolgt in Figures. Diese Figures ähneln Variablen einer Programmiersprache. Die Syntax der Figures lautet Figurename = Progression. Der Figurename besteht
dabei aus einem Großbuchstaben, gefolgt von beliebig vielen Kleinbuchstaben. Leer- oder
Sonderzeichen sind nicht erlaubt. Durch den Einsatz von Figures ist es möglich, wiederholte Liedsegmente nur einmal notieren zu müssen. Außerdem bietet es eine Möglichkeit der
Strukturierung des Stücks.
4.4.7. Structure
Die Struktur eines Liedes besteht aus einer Folge von Figures. Sie wird als Structure bezeichnet.
Zur Notation wird das Structure-Keyword angegeben. Danach können Figurenames angegeben
werden, wobei die Reihenfolge die Struktur des Liedes festlegt. Jede Figure kann auch mehrmals
vorkommen.
41
4. Entwurf
4.4.8. Rhythm
Zum Abspielen des Liedes ist es notwendig, eine Form des Rhythmus zu definieren. Ansonsten
müsste eine von dem System definierte Form gewählt werden. Um eine zufriedenstellende
Lösung zu erreichen, ist die Platzierung des Rhythmus-Elements wichtig.
Für die grundsätzliche Syntax der Rhythmuselemente ist die Wahl auf die geschweiften
Klammern gefallen. Sie umschließen eine Folge von Brüchen, die der Länge eines Anschlags
entsprechen.
Diese Form eines Rhythm-Blocks bietet die Möglichkeit, den Rhythmus an verschiedenen
Stellen zu definieren. Zum einen kann als Fallback-Lösung für den gesamten Song der Block
mit dem Keyword Rhythm: angegeben werden. Am Ende einer Figure kann ebenfalls ein
solcher Rhythm-Block angehängt werden, was den Rhythmus auf die Progression dieser Figure
anwendet, nicht aber auf andere Progressions des Liedes. Außerdem kann ein solcher Block
innerhalb einer Progression nach einem Takt verwendet werden, um den Rhythmus nur dieses
Taktes zu beeinflussen. Die verschiedenen Anwendsungsformen des Rhythm-Blocks sind in
Abbildung 4.5 zu sehen.
Abbildung 4.5.: Verschiedene Verwendungsformen des Rhythm-Blocks
4.5. Systemkontext
Abbildung 4.6 zeigt das Systemumfeld. Der Benutzer gibt Musikdaten in das System ein. Zum
Abspielen sendet das System Abspielinformation an SuperCollider1 . Bei SuperCollider handelt
es sich um ein System zur Audiosynthese und algorithmischen Musikerzeugung. Dies spielt
dann die Musik ab.
1
https://supercollider.github.io
42
4. Entwurf
Abbildung 4.6.: Kontextsicht des Systems
4.6. Systemstruktur
Die Architektur der Software setzt sich aus einigen Komponenten zusammen. Sie ist in Abbildung 4.7 zu sehen. Die zentrale Komponente ist die REPL-Komponente. Sie stellt die Schnittstelle
zum Benutzer bereit und beinhaltet die weitere Ablaufsteuerung. Sie benötigt die Parserkomponente, um eingehende Befehle zu übersetzen und die Player-Komponente, um die Möglichkeit
zum Abspielen bereitzustellen. Die Song-Komponente wird von allen Komponenten verwendet.
Sie enthält das Semantic Model und somit die Datenstruktur, die im Zentrum der Anwendung
steckt.
In der Parser-Komponente ist die Grammatik definiert. Hier werden Programme der DSL
eingelesen und über verschiedene Transformationen ins Format des Semantic Models gebracht.
Die Player-Komponente übersetzt die interne Datenstruktur des Musikstücks in eine sequenzielle Form und sendet sie über eine Schnittstelle an SuperCollider.
Die Song-Komponente enthält ein Datenmodell zur Verarbeitung von Musikstücken. Es
bietet die Möglichkeit, Attribute eines Musikstückes zu setzen und auszulesen. Darüberhinaus
kann hier die semantische Korrektheit des Stückes überprüft werden.
43
4. Entwurf
Abbildung 4.7.: Bausteinsicht des Systems
4.7. Komponenten
Die im vorherigen Abschnitt vorgestellten Komponenten des Systems sollen im folgenden
detailliert besprochen werden. Zunächst wird die Song-Komponente beschrieben, anschließend
die REPL, dann der Parser und zuletzt die Abspielkomponente.
4.7.1. Song
Die Song-Komponente besteht aus einem Song-Objekt, dass Möglichkeiten zur Speicherung
von Song-Informationen bietet. Außerdem wird hier die semantische Korrektheit geprüft.
Abbildung 4.8 zeigt diese Komponente.
Diese Komponente ist größtenteils eine passive Datenstruktur. Da sie jedoch eine zentrale
Rolle in allen Bereichen der Anwendung spielt, wurde sie als eigene Komponente modelliert.
Bei einer eventuellen Weiterentwicklung des Systems können hier weitere Funktionalitäten
44
4. Entwurf
eingebaut werden, die Auswertungen und weitere musikalische Unterstützung ermöglichen
könnten.
Abbildung 4.8.: Bausteinsicht der Song-Komponente
4.7.2. REPL
Die REPL-Komponente ist das zentrale Stück der Ablaufsteuerung des Systems. Sie empfängt
Eingaben vom Benutzer, wertet die Befehle aus und zeigt dem Benutzer Ausgaben an. Die Komponente besteht aus mehreren Elementen. Bevor aber der Aufbau der Komponente vorgestellt
wird, soll der strukturelle Ablauf mithilfe eines Zustandsautomaten beschrieben werden.
45
4. Entwurf
Abbildung 4.9.: Zustandsautomat der REPL
Abbildung 4.9 zeigt das Zustandsdiagramm der REPL. Beim Start wird zunächst der Zustand
init durchlaufen. In diesem werden zum Start notwendige Aktionen ausgeführt. Eine Willkommensmeldung wird ausgegeben. Anschließend wechselt der Automat in den ready-Zustand.
Bei erfolgreichem Ausführen der Befehle load und new wird der Zustand verlassen und zum
song-Zustand gewechselt. Dieser bietet Funktionen zum Abspielen, Speichern und Verändern
eines Liedes. Beim Schließen des Liedes wird zurück in den ready-Zustand gewechselt. In beiden Zuständen gültig sind die help-Befehle, die einen Hilfetext anzeigen, sowie die quit-Befehle,
die zum Zustand exit führen. Hier wird dafür gesorgt, dass die REPL sauber herunterfährt.
Anschließend beendet der Automat.
Jeder Zustand des Systems erwartet gewisse Eingaben durch den Benutzer. Dieselbe Eingabe
kann in unterschiedlichen Zuständen verschiedene Auswirkungen haben, da die Abwicklung
der Eingabe durch den jeweiligen Zustand erfolgt.
Die Wahl der Architektur für einen Zustandsautomaten kommt daher, dass so die Flexibilität
der Anwendung erhöht wird. Unterschiedliche Zustände können unterschiedliche Arbeitsschritte abbilden. So könnte das Abspielen beispielsweise auch in einem anderen Zustand
erfolgen, wenn die Komplexität der Abspielkomponente größer wird. In diesem Stadium der
Anwendung wurde sich dagegen entschieden, da der Aufwand des Zustandswechsels für den
Benutzer im Verhältnis zum Mehrwert eines eigenen Zustandes zu groß ist.
46
4. Entwurf
Abbildung 4.10.: Bausteinsicht der REPL-Komponente
Als Basis der REPL wird ein Zustandsautomat verwendet. Die StateMachine bietet einen
abstrakten Zustandsautomaten. Er enthält einen Systemkontext, in dem der Zustand des
Systems gespeichert ist. Dazu gehört die Song-Struktur, sowie Informationen, die zur Ausgabe
bestimmt sind, Result und Error. Ein Result ist eine Ausgabe des Systems an den Benutzer.
Beim Befehl help beispielsweise wäre der Hilfetext das Result. Wenn bei der Bearbeitung eines
Befehls ein Fehler auftritt, so wird er in Error gespeichert. Die Trennung von Result und Error
ermöglicht eine unterschiedliche Verarbeitung und Ausgabe.
Neben dem Kontext hat die StateMachine einen aktuellen State, der für die Abwicklung der
eingehenden Befehle zuständig ist. Jeder Zustand kann in der StateMachine einen Zustandswechsel bewirken. Dazu hat sie eine Liste von Transitions, die von einem Zustand zu einem
anderen Zustand führen. Die Übergänge sind dabei genau definiert.
Das Systemmodul bietet eine Konfigurationsstelle und dient zum Starten der REPL. In ihr
werden die für den Zustandsautomaten benötigten Maps definiert. Die Funktionen, die für
47
4. Entwurf
die Zustände verwendet werden, sind im Modul States definiert. Jeder der Zustände erwartet
gewisse Befehle. Die Befehle für den Song-Zustand werden im SongState bearbeitet. Dieses
Modul hat eine Funktion command, die einen String erwartet. Je nach Inhalt des Strings
wird eine Funktion aufgerufen, die den Befehl weiterverarbeitet. Handelt es sich um einen
gültigen Befehl, so gibt es eine spezielle Funktion dafür, ansonsten wird die Funktion unknown
aufgerufen, die für die Ausgabe eines Fehlers sorgt. Die oben genannten Befehle können
keine direkten Ausgaben erzeugen. Stattdessen werden die Ausgaben in der Datenstruktur
gehalten und in der Zustandsfunktion ausgegeben. Funktionen für diese Art von Ausgaben und
zur Durchführung von Zustandsübergängen werden im Context definiert. Zum erleichterten
Wechsel der konkreten Ein- und Ausgabe-Implementation wurde ein IO-Modul konzipiert, das
eine Schnittstelle für die wichtigsten Les- und Schreibfunktionen anbietet.
Abbildung 4.11.: Laufzeitsicht der REPL-Komponente
Abbildung 4.11 zeigt den groben Ablauf der Verarbeitung eines Befehls in der REPL-Komponente.
Die Zustandssteuerung ist dabei außen vor gelassen. Der SongState erhält eine neue Nachricht,
diesem Fall den String help. Er gibt den Aufruf an SongCommands weiter. Hier wird er analysiert und die passende Funktion help aufgerufen. Diese analysiert den Aufruf auf Parameter
und belegt im Context-Objekt das Result-Feld mit einem Hilfetext. Dieses Context-Objekt wird
über SongCommands und SongState zurück an die StateMachine gegeben.
48
4. Entwurf
4.7.3. Parser
Abbildung 4.12.: Bausteinsicht der Parser-Komponente
Die Parser-Komponente ist zuständig für das Parsen der Grammatik der DSL und der Transformation der daraus resultierenden Baumstrukturen in die Song-Struktur. Zur Generierung
der notwendigen Parse-Funktionen wird die Instaparse-Bibliothek verwendet. Sie benötigt
dafür eine Grammatik in der Form einer EBNF, die im Parser definiert wird.
Zur Transformation der von den Parse-Funktionen ausgegeben Datenstrukturen in die
eigene, bietet der Transformer eine Funktion an. System verbindet den Ablauf vom Parsen und
Transformieren und bietet eine Schnittstelle nach außen an.
49
4. Entwurf
Abbildung 4.13.: Laufzeitsicht eines Parse-Vorgangs
In der Abbildung 4.13 ist eine Laufzeitsicht des Parsevorgangs zu sehen. Der Benutzer der
Komponente ruft auf dem ParserSystem die Funktion parse mit einem String als Parameter
an. Das ParseSystem delegiert den Aufruf an den Parse, der Anhand des Strings und seiner
Grammatikregeln einen Parsebaum generiert. Er gibt diesen Parsebaum zurück ans ParserSystem, das mit der Funktion transform den Parsebaum an den Transformer weiterreicht. Dieser
erstellt anhand einer Reihe von Transformationsregeln aus dem Parsebaum ein Song-Objekt.
Dieses wird dem Benutzer zurückgegeben.
Die Arbeit der Parser-Komponente ist hier vorbei. Der Benutzer hat anschließend die Möglichkeit, das Song-Objekt mithilfe der check-Funktion auf semantische Korrektheit zu überprüfen.
50
4. Entwurf
4.7.4. Player
Abbildung 4.14.: Bausteinsicht der Player-Komponente
Die Schnittstelle der Player-Komponente bietet lediglich eine Funktion an: play-song. Diese
nimmt eine Song-Struktur an. Anschließend fügt sie mithilfe der OvertoneFormatter-Funktion
add-notes zu jedem Akkord im Lied Notenwerte in Midi-Form hinzu. Außerdem wird der
im Lied festgelegte Rhythmus auf die einzelnen Takte angewendet. Damit werden die Takte
vervollständigt. Mithilfe der Funktion song->seq wird eine Liste von Takten erstellt. Diese
wird dann durchlaufen. Die einzelnen Akkorde werden dann zum Abspielen angemeldet. Das
Abspielen geschieht asynchron.
4.8. Fazit
In diesem Kapitel wurde gezeigt, wie aus den in der Analyse erarbeiteten Anforderungen ein
Entwurf für das Notationssystem Jazzler erstellt wurde. Im Zentrum lag dabei die Erstellung
einer Sprache zur Notation von Musikstücken und die Architektur eines interaktiven Systems
zur Eingabe und Nutzung der durch die Sprache erzeugten Musikstücke.
51
5. Implementierung und Auswertung
In diesem Kapitel werden einige Entscheidungen für die Implementierung besprochen. Anschließend wird eine Bewertung des Systems getroffen.
5.1. Programmiersprache und Bibliotheken
Für die Implementierung wurde die Sprache Clojure1 gewählt. Es handelt sich dabei über einen
Lisp-Dialekt, der auf der Java Virtual Machine läuft. Durch besondere Syntax von Clojure, in der
Programmiercode als Listen dargestellt werden, ist die Veränderung von Datenstrukturen sehr
einfach zu erledigen, was die Baumtransformationen erleichtert. Clojure ist eine dynamisch
typisierte funktionale Programmiersprache.
Zur Erzeugung eines Parsers fiel die Wahl auf die Bibliothek Instaparse2 . Zur Definition
von Grammatiken nutzt sie eine EBNF-Syntax. Als Ausgangsformat bietet Instaparse zwei
verschiedene Formate, für die es umfangreiche Bibliotheken zur Transformation. Außerdem
bietet es eine eigene Funktionalität, mit der simple Transformationen einfach möglich sind. In
dieser Arbeit wurde für die Transformation Instaparse verwendet.
5.2. Modellierung in funktionaler Programmierung
In Abschnitt 4.7.2 wurde zur Modellierung der REPL-Komponente ein UML-Klassendiagramm
benutzt. Diese Art von Diagramm wird zur Darstellung von Strukturen in der objektorientierten
Programmierung verwendet. Bei der objektorientierten Programmierung ist ein wichtiger
Aspekt die Verbindung von Zustand und Verhalten in Klassen und Objekten. Dagegen wird bei
der funktionalen Programmierung Verhalten und Daten getrennt.
Zur Implementierung der Architektur wurden daher keine Klassen verwendet. Die meisten
der in den Diagrammen als Klassen dargestellten Elemente wurden stattdessen mithilfe von
Modulen realisiert. So gibt es beispielsweise für die Implementierung des Datentyps Song ein
Modul namens Song. Innerhalb dieses Moduls gibt es eine Funktion zur Erstellung einer neuen
1
2
http://clojure.org
https://github.com/Engelberg/instaparse
52
5. Implementierung und Auswertung
Songstruktur, sowie Funktionen zur Manipulation einer solchen Struktur. Die Datenstruktur
des Songs ist als HashMap realisiert.
Neben den Funktionen, die direkt den Song betreffen, enthält das Modul aber auch Funktionen, die Attribute des Songs betreffen. So gibt es hier auch Funktionen zur Erzeugung von
Akkorden und Akkordfolgen. Die im Diagramm angegebenen Relationen gelten weiterhin.
Eine Besonderheit ist die Implementierung der Zustände und Commands der REPL. Ein
Zustand wird durch eine Funktion repräsentiert, in der der allgemeine Ablauf beschrieben wird.
Zusätzlich hat er eine Reihe von Funktionen, die jeweils einen Command abbilden. Während
die Commands im Klassendiagramm als Klassen dargestellt werden, sind es hier Funktionen,
die für den jeweiligen Befehl verantwortlich sind. Es gibt keine Vererbung, sondern nur eine
strukturelle Ähnlichkeit.
5.3. Audioausgabe
Um das Abspielen der Musik zu ermöglichen, wurde Overtone3 verwendet. Dabei handelt es
sich um eine Clojure-Library, die eine Schnittstelle zu SuperCollider bietet.
SuperCollider bietet eine Sprache zur Definition von Synthesizern und zur programmatischen
Erzeugung von Kompositionen, die eine syntaktische Ähnlichkeit zu der Programmiersprache
C hat. Zum Ausführen der Töne und Kompositionen bietet es darüber hinaus einen Server an,
der mittels einer offenen Schnittstelle Steuerungsbefehle entgegennimmt. Die Library Overtone
ermöglicht es, die SuperCollider-Umgebung unter Nutzung von Clojure-Code anzusprechen.
Zu Overtone gehört auch die Library at-at4 . Mit ihr ist es möglich, die Ausführung von Funktionen zu einem Zeitpunkt in der Zukunft festzulegen. Dies wird in der Player-Komponente
genutzt, um das Abspielen der einzelnen Töne zu realisieren.
Der allgemeine Ablauf des Players ist so aufgebaut, dass beim Ausführen der Abspielfunktion
die relevanten Takte durchlaufen werden. Für jeden Takt wird ein Soundereignis geplant, das
einen Abspielzeitpunkt und eine Dauer erhält. Aufgrund der funktionalen Natur von Clojure
ist es sehr einfach, die konkrete Funktion, die das Soundereignis bei SuperCollider auslöst,
auszutauschen. So ist es möglich, die Abspielkomponente zu ersetzen oder zu erweitern. Es
wäre beispielsweise möglich, nicht nur ein Soundereignis bei SuperCollider auszulösen, sondern
zusätzlich eine Nachricht an eine grafische Oberfläche zu senden, die den aktuell abgespielten
Akkord anzeigt.
3
4
https://github.com/overtone/overtone
https://github.com/overtone/at-at
53
5. Implementierung und Auswertung
5.4. DSL
Für die Realisierung der DSL wurde die Instaparse-Library verwendet. Sie erzeugt anhand einer
in einem EBNF-Format notierten Grammatik eine Parser-Funktion, die dann zum Parsen eines
Programms dieser Sprache verwendet werden kann. Das Ausgabeformat dieses Parsevorgangs
ist eine Baumstruktur, die als Liste von Listen realisiert ist. Darüberhinaus bietet Instaparse eine
Funktion zur Transformation dieser Baumstruktur. Sie nutzt dazu eine Map, in der für jeden
Knoten, der verändert werden soll, eine Funktion eingetragen werden kann. Diese Funktion ist
dann für die Umstrukturierung verantwortlich. Dadurch, dass Clojure sehr gute Unterstützung
zur Umformung von Listen bietet, sind die Transformationsfunktionen sehr kurz und leicht
lesbar.
5.5. Stand der Entwicklung
Die im Rahmen des Entwurfs geplante Anwendung Jazzler wurde zu einem großen Teil
entsprechend der Anforderungen implementiert. Der komplette Featureumfang des Entwurfs
wurde dabei aber nicht erreicht. So sind die Funktionalitäten zum Laden und Speichern eines
Liedes als Datei nicht implementiert worden.
Auch die Verwendung von Rhythmusblöcken ist noch nicht eingebaut, allerdings sind diese
als Prototyp realisiert und im Source Code enthalten.
5.6. Auswertung
Die hier vorgestellte Softwarelösung Jazzler hatte das Ziel, einige Anforderungen zu erfüllen.
Im folgenden soll kurz untersucht werden, wie diese Anforderungen erfüllt wurden.
5.6.1. Improvisation und Komposition im Einklang
Eine Anforderung war, dass der für Jazzmusik typische Zusammenhang von Improvisation und
Komposition beachtet werden soll. Im vorgestellten System sollte diese Anforderung dadurch
gelöst werden, dass eine Melodienotation in der Sprache nicht unterstützt wird. Stattdessen
sollte eine Abspielkomponente die Improvisation ermöglichen. Außerdem sollten Lieder im
Fall fehlender Werte Standardwerte erhalten, die das Abspielen ermöglichen.
54
5. Implementierung und Auswertung
5.6.2. Eine Notenschrift mit musiktheoretischer Basis
Die Notationssprache des Systems sollte nicht die Verbindung zu den musiktheoretischen
Prinzipien und Grundlagen verlieren. Um dieser Anforderung gerecht zu werden, wurde die
Notation der Akkorde durch Akkordsymbole realisiert. Zusätzlich dazu wurden die AkkordGrundtöne durch römische Zahlen dargestellt, was der Stufe des Akkords in der Tonleiter
entspricht. Die Notation der Rhythmuswerte erfolgt durch Bruchzahlen, die entsprechend der
üblichen Notenlängen genutzt werden können.
5.6.3. Ein ausgewogenes Verhältnis von Informationsdichte und Lesbarkeit
Den Informationsgehalt der Sprache hoch zu halten, während die Lesbarkeit erhalten bleibt,
war eine weitere Anforderung. Auf diesen Aspekt sprechen mehrere Elemente der Sprache
an. Zunächst wurden Akkordsymbole ähnlich der Akkordsymbolnotation verwendet. Sie sind
kürzer zu notieren, als unter Angabe der einzelnen Noten, aus denen ein Akkord besteht.
Bei der Notation von Akkordfolgen ist es möglich, Takte mit einem einzelnen Akkord
anzugeben, wenn der Takt nur einen Akkord enthält. Enthält er mehrere Akkorde, so muss
dieser Takt mittels einem Klammerpaar markiert werden. Dabei steht die Notation eines
Akkords nicht für einen Anschlag, sondern notiert nur, dass an dieser Stelle dieser Akkord
gespielt werden soll. Das konkrete Abspielen des Akkords wird erst durch den Rhythmus
festgelegt.
Des weiteren wurde die Gliederung des Liedes in Figures eingeführt. Dies ermöglicht eine
Verringerung der Anzahl zu schreibenden Takte, da mehrfach vorkommende Teile in der
Struktur mehrmals mit dem Figurenamen aufzählen kann.
Bei der Nutzung des Systems ist es nicht nötig, jede einzelne Information über das zu
notierende Stück anzugeben. Fehlende Informationen werden bei der Verwendung durch
Standardwerte ersetzt. Dadurch kann die Notation verkürzt werden.
5.6.4. Unterstützung bei Notation und Improvisation durch den Computer
Die letzte Anforderung sagte aus, dass der Benutzer bei der Notation und der Improvisation
unterstützt werden soll. Dazu fiel die Wahl auf ein interaktives REPL-System, dass die Verwendung von Funktionen ermöglicht. Dies umfasst auch die Abspielfunktion, die aus diesem
REPL-System heraus ausgeführt wird. Weitere unterstützende Funktionen sind durch den
Aufbau des Systems möglich, waren aber nicht Teil der Arbeit.
55
5. Implementierung und Auswertung
5.7. Verbesserungsmöglichkeiten
Neben der bereits genannten nicht fertig implementierten Funktionalitäten bietet das System
noch einige Verbesserungsmöglichkeiten.
5.7.1. DSL
Die DSL ermöglicht primär die Notation von Akkordfolgen. Dabei sind die möglichen Töne an
die im System definierten Tonleitern gebunden. Hier könnte eine Notation der Halbtonschritte
der Tonleiter einen flexibleren Ansatz ermöglichen. Außerdem ist es in Musikstücken nicht
unüblich, die Tonart zu wechseln. Die Möglichkeit des Tonartwechsels würde die Sprache
mächtiger machen.
Als Interessant könnte sich auch die Komposition von Figures aus anderen Figures erweisen.
Auch kann eine Art Variablenkonstrukt ähnlich den Figures für Rhythmusblöcke weitere
Duplikation verringern.
Eine Notationsform für Melodien entspricht zwar nicht den ursprünglichen Anforderungen,
könnte aber bei einer guten Syntax die Sprache sinnvoll erweitern.
Weitere Gedanken sind bei Takten mit mehreren Akkorden nötig. Dabei ist es momentan
schwierig zu erkennen, wie ein solcher Takt abgespielt wird, wenn kein passender Rhythmusblock vorhanden ist. Wie dieses Problem zu lösen ist, lässt sich hier nicht beantworten.
5.7.2. System
Die REPL kann durch weitere Funktionalitäten, wie dem Speichern von Musikstücken und
Hilfsmitteln für das Improvisieren ausgestattet werden. So könnte es beispielsweise eine
Auflistung der geeigneten Töne für den aktuellen Akkord geben.
Eine größere Weiterentwicklung wäre die Umstrukturierung des Systems in eine ClientServer-Architektur. Der Server würde eine zentrale Anmeldestelle für beliebige Clients bieten.
Die Clients könnten verschiedene Formen haben. Zur Nutzung bei der Improvisation könnte
ein Client geeignete Töne Anzeigen, während ein anderer anhand der gegebenen Musikinformationen eine begleitende Basslinie erzeugt und an SuperCollider sendet. Auch könnte ein
Client Signale an digitale Instrumente senden.
56
6. Fazit
Im Rahmen dieser Arbeit wurde Softwaresystem zur Notation von Jazz-Musik konzipiert und
umgesetzt. Es besteht aus einer REPL, einer Komponente zum Abspielen, sowie einer DSL, die
die zentrale Rolle der Anwendung spielt. Das System ist so entworfen, dass Erweiterungen in
der Funktionalität ohne großen Aufwand möglich sind.
Die domänenspezifische Sprache ist darauf ausgelegt, in einer für Musiker lesbaren Form
Musik zu notieren, die als Untermalung für Improvisationen dienen kann. Im Fokus liegt die
Definition von Akkordfolgen im Kontext einer festgelegten Tonleiter. Die Akkordfolgen werden
benannt und können in eine beliebige Reihenfolge gebracht die Liedstruktur definieren. Dazu
ist es möglich, den einzelnen Takten auf verschiedenen Ebenen Rhythmusmuster zuzuweisen,
die beim Abspielen beachtet werden.
Die REPL bietet eine Schnittstelle für den Benutzer, Lieder in der DSL zu notieren und sie
abzuspielen. Dadurch bietet sie die Möglichkeit der Interaktion mit dem zu notierenden Stück.
Die Notation eines Musikstücks ist aufgrund der vielen verschiedenen Notationsarten und
Werkzeuge eine indiviuelle Sache. Die Komposition von Musik ist ein kreativer Prozess und
die Möglichkeit, unterschiedliche Notationswerkzeuge zur Auswahl zu haben, kann eine
positive Auswirkung auf diesen Prozess haben. Und auch die Art der Interaktion mit dem
Notationsmedium kann eine immense Hilfe bei der Komposition und Improvisation sein.
Das hier entwickelte System kann sicherlich keine etablierte Notationsform ersetzen, aber
ein andere Blickwinkel auf dieselbe kann dabei helfen, einen anderen Aspekt dieser Thematik
zu erkennen.
57
A. Anhang
Inhalt der CD:
1. Bachelorarbeit als PDF: Bachelorarbeit Felix Jensen.pdf
2. Quellcode im Ordner jazzler
3. Infotext zum Quellcode: infotext.txt
58
Literaturverzeichnis
[Fowler 2010]
Fowler, Martin: Domain-Specific Languages. First printing. Pearson Educati-
on, Inc, 2010. – ISBN 978-0-321-71294-3
[Grabner 2011]
Grabner, Hermann: Allgemeine Musiklehre. 25. Auflage. Bärenreiter-Verlag
Karl Vötterle GmbH & Co. KG, 2011. – ISBN 978-3-7618-0061-4
[Grune u. a. 2000]
Grune, Dick ; Bal, Henri E. ; Jacobs, Ceriel J. ; Langendoen, Koen G.:
Modern Compiler Design. John Wiley & Sons, Ltd, The Atrium, Southern Gate, Chichester,
2000. – ISBN 978-0-471-97697-4
[Haunschild 1998]
Haunschild, Frank: Die neue Harmonielehre. Erw. und überarb. Neuaufl.
1998. AMA Verlag GmbH, 1998. – ISBN 978-3-7618-0061-4
[Sikora 2012]
Sikora, Frank: Neue Jazz-Harmonielehre. 5. Auflage. Schott Music GmbH &
Co. KG, 2012. – ISBN 978-3-7957-5124-1
59
Hiermit versichere ich, dass ich die vorliegende Arbeit ohne fremde Hilfe selbständig verfasst und
nur die angegebenen Hilfsmittel benutzt habe.
Hamburg, 15. März 2016 Felix Jensen