Bild 37 zeigt schematisch die sieben Bereiche von Musik-Software.
Die Repräsentation von Musik ist ein zentrales Anliegen, seit es die Musik gibt. Waren es im Frühmittelalter die Neumen, so ist die Repräsentationsfrage heute im Rahmen von Software-Formaten behandelt:
| Musik-Repräsentationssoftware gestaltet die Neumen von heute. |
|---|
Wir betrachten zuerst Music N (hier als Lernversion N=0), eine Familie von Repräsentationssprachen, die 1960 durch Max Mathews (Music III) bei Bell Telephone Labs NJ. gestartet wurde, siehe auch Bild 38. Music N ist die Muttersprache bekannter Formate, etwa Csound, Common Lisp Music, NeXT MusicKit, oder IRCAM MAX.
Die Orchestra Language benutzt die Beschreibung, welche wir von Sound-Events früher gegeben hatten (mit Envelope, etc.), ausser dass die (normierte) Envelope und die Wave hier vom Score-File geliefert wird. Die technologische Realisation eines solchen Instrumentes basiert auf Unit Generators, also Einheitsgeneratoren, die (wie in Bild 38, Mitte links gezeigt) zusammengestöpselt werden. Die Software-Beschreibung eines solchen Unit Generators, hier eines Hüllkurven-Generators, ist in Bild 38 unten (b) gezeigt. Dabei bezieht sich der Input auf die normierte Hüllkurve f1 und die Wave f2, welche beide im Score-File, (Bild 38, Mitte rechts), definiert sind. Dabei ist f1 ein Liniensegment und f2 eine Fourier-Synthese-Wave.
Die Score Language beinhaltet neben der Beschreibung der Envelopes und Waves auch die Liste der Sound-Events, welche durch die Parameter p1 bis p7 erfasst werden. Dabei bedeuten
wie wir die Darstellung ja (bis auf die hier nicht wichtigen Filterdaten) kennengelernt hatten.
In der 1987-1994 entwickelten Kompositionssoftware presto®, die in ANSI-C geschrieben ist, heissen die Töne presto-NoteEvents, siehe Bild 39. Presto ist auf dem Internet als Shareware verfügbar. Sie bedeuten aber eher Noten-Events und werden erst durch die Performance-Daten der Tempo-Kurve der Software zu physikalischen Events verwandelt. Wir betrachten hier nur die Daten auf der mentalen Seite. Links im Bild sieht man das SCORE-Datenformat. Diese Partitur besteht aus drei Ketten von Verweisen auf Ereignisse (durch die * gekennzeichnet) Sie startet bei noe_beg, dem ersten Verweis. Dieser zeigt auf eine erste Note (Format NOTE_EVENT, rechts oben in Bild 39). Diese hat die mentalen (!) Parameter Einsatzzeit (time), Tonhöhe (hoehe), Dauer (dauer), Lautstärke (laut), Instrument (sound) sowie zwei Verweise: einen auf die nächste Note (*next) und einen auf die vorangehende Note (*prev). Die Noten sind also miteinander verkettet und können so schnell aufeinander zugreifen in einem syntagmatischen Reigen.
Der zweite Datentyp der SCORE ist die Kette der Instrumentierungs-Events (Mitte rechts Bild 39, Format PERF_EVENT), auch hier mit Verkettungskoordinaten.
Der dritte Datentyp der SCORE ist die Kette der Tempo-Angaben (rechts unten Bild 39, Format TIME_EVENT), die die Koordinaten time (=Einsatzzeit der neuen Tempo-Angabe) und tempo (=neuer Tempowert) sowie die Verkettungsdaten zum nächsten Tempo-Event (*next) und zum vorangehenden Tempo-Event (*prev) enthält.
Dies ist die Definition einer objekt-orientierten Klasse. Die einzelnen fettgedruckten Symbole sind die Attribute, welche eine Klasse definieren, während die vorangestellten Symbole die Sorten der Attribute bezeichnen.
Eine solche Klasse stellt eine Art Raum dar, in welchen sich eine bestimmte Sorte von Objekten bewegen kann. Hier in Bild 40 wird der "Raum" (die Klasse) für die Akkorde bereitgestellt. Punkte in diesem Raum heissen Instanzen oder Objekte und werden durch Angabe bestimmter Werte der Attribute festgelegt. Wir haben z.B. in der dritten Zeile das Attribut (= Instanzvariable) myPitchCount, welches von der Sorte int ist. Das meint: myPitchCount ist eine ganze Zahl (int = Integer) und soll die Anzahl der Tonhöhen eines Akkordes angeben. Die fünfte Zeile double myOnset bezeichnet eine reelle Zahl, nämlich die mentale Einsatzzeit des Akkordes. Usf.
Wichtig ist hier, dass der Akkordbegriff in der Chord-Klasse sehr komplex ist: Wir finden nicht nur Daten zum einzelnen Akkord, sondern auch Hilfsdaten zur harmonischen Analyse, in denen der Akkord vorkommen wird, etwa die Attribute myThirdStreamList oder myRiemannMatrix, welche eine funktionstheoretische Analyse (Riemann-Theorie) des Akkordes mitbeschreiben.
Daraus lernen wir, dass mit fortschreitender Programmierkunst auch die Objekte der Musik immer umfassender beschrieben werden, sei es in ihrem Zusammenhang wie bei presto, sei es in ihren analytischen Nebendaten wie bei der RUBATO-Klasse Chord.
Das vierte Beispiel ist ein am sogenannten Lambda-Kalkül orientierter Entwurf von Orlarey et al. (ICMC 1994) im Sinne einer "Algebra der Musik" (ähnlich wie Paul Hudaks Haskore/Haskell-Sprache, die an der Yale University entworfen wurde und deren Name auf Haskell Curry, einen Pionier des Lambda-Kalküls, zurückgeht -- Stichwort für Informatiker: "Currysierung"), siehe Bild 41.
Für uns ist wichtig, dass in dieser Definition der Begriff der Score implizit verwendet wird. Man kann so also Hierarchien von Scores bauen, startend mit der leeren Score oder mit einem Event.
Auch ein Event ist rekursiv aufgebaut: entweder ein r (eine Pause) oder eine Note, oder ein Event + Modifier.
Die Details sind ziemlich klar, wir geben verschiedene Beispiele an in der Mitte von Bild 41. Unten links im Bild sehen wir auch, wie man ein Notenbeispiel konstruieren kann mit dieser Sprache. Unten rechts wird gezeigt, wie man durch Zusammenbauen von einfachen Blöcken kompliziertere Strukturen erhalten kann.
Obwohl eine solche Sprache durch ihre rekursive Syntax interessantes Potential besitzt, ist sie doch sehr beschränkt, da sie sich letztlich immer aus Notenmaterial aufbauen muss.
Wir werden unten eine allgemeinere Sprache, das PrediBase-Format, kennenlernen, welches in der Software RUBATO benutzt und gegenwärtig an verschiedenen Forschungszentren (Zürich, Berlin, Osnabrück, Mexico City) ausgebaut wird. PrediBase erlaubt es, sowohl mentale als auch physikalische Konstrukte oder auch Prozesse genau zu beschreiben.
Musik-Software ist extrem vielfältig und erfüllt aber darin auch die Grundforderung der aus der modernen Mathematik hervorgegangenen "Yoneda-Philosophie". Ihr zufolge heisst Verstehen, dass man den Gegenstand seines Interesses von allen Perspektiven aus anschauen muss, um dann aus dieser Vielfalt an Perspektiven ein Ganzes des Verstehens zu errichten (siehe G. Mazzola & G.R. Hofmann: Der Music-Designer MDZ71 - Hard- und Software für die mathematische Musiktheorie). Gerade in der Musik ist diese Philosophie von grosser praktischer und theoretischer Bedeutung. Geraint Wiggins et al. betonen gerade die Vielfalt als Charakteristikum der Darstellungsweisen von Musikobjekten:
| In many representation tasks, ambiguity of representation can be a problem, whereas in music, multiple readings of an object can be vital. |
|---|
Wiggins hat die Leistungsart von Musik-SW in einer 2D-Darstellung positioniert, deren Koordinaten da sind:
Die Graphik von Wiggins zeigt Bild 42. Wir sehen, dass MIDI, die verbreitete Sprache für Kommunikation zwischen Computern und Synthesizern, ziemlich schlecht wegkommt. Die Partitur, hier als "Score" bezeichnet, steht in der Mitte des Bildes: Sie liefert weder zuviel an physikalischer Expressivität, noch zuviel an analytischer Einsicht, sondern erscheint hier als neutrale Mitte.
Dies ist nicht nur ein negativer Trend, es ist die typische Verschiebung der Arbeitsstile in Richtung kollaborative Gemeinschaften, welche global aber verteilt zusammenarbeiten. Nicht vergebens spricht man in der modernen Forschungssoziologie von Collaboratories, von verteilten Laboratorien, die dicht vernetzt zusammenarbeiten, siehe die Studie H@E, welche wir anfangs erwähnt hatten.
Ende 1982 und definitiv Jan. 1983 wurde die "MIDI 1.0 Spezifikation" an der NAMM (National Association of Music Merchants) verabschiedet. Interessant ist dabei, dass nun nicht mehr die akademische Audio Engineering Society, sondern ganz pragmatisch die Vereinigung von Musikhändlern das Heft in die Hand genommen hatte! Standardisierung als Angelegenheit der Musikindustrie, nicht der Musikwissenschaft. Darüber nachzudenken lohnt sich...
Das Dokument "MIDI 1.0 Spezifikation" ist die Beschreibung von MIDI. Es ist durch die MIDI Manufacturer's Association erhältlich. Mittlerweile ist man über Version 4.2 (Jan 1993) hinaus, momentant Version 96.1 (96 = Jahr...). Siehe im Internet auch unter http://www.midi.org.
Wir beschreiben im folgenden die MIDI-Kommunikation und die Struktur der MIDI-Messages, also der Botschaften, die via MIDI-Kommunikation ausgetauscht werden können zwischen Computern, zwischen Synthesizern oder zwischen Computern und Synthesizern. Für weitere Details betreffend MIDI sei auf das Buch von Justus Noll: Musik-Programmierung. Addison-Wesley, Bonn 1994, verwiesen.
Charakterisierung der MIDI-Kommunikation (Hardware), siehe Bild 43.
Die MIDI-Kommunikation selber benutzt MIDI-Kabel, welche ausgehende Signale am Port MIDI-Out, eingehende Signale am MIDI-Port MIDI-In und Signale, die einfach durch ein Gerät geschlauft werden, am MIDI-Port MIDI-Thru übertragen. Die Datenübertragung ist seriell, dh. alle Daten werden strikt nacheinander gesendet. Die digitale Datenübertragung sendet mit einer Rate von mit 31'250 Baud (Baud = 1 Bit pro Sekunde) (=1 MegaBaud/32) in Kabeln zu 5mA (es gibt neuerdings auch parallele Übertragung).
Für die Struktur der MIDI-Botschaften oder Messages siehe Bild 44 und Bild 45.
Grundsätzlich besteht jede MIDI-Message aus 10-Bit-Wörtern, d.h. aus Sequenzen von 10 Bits. Das Start- und das Stop-Bit haben immer den Wert 0. Die Übertragung eines Wortes benötigt also 320 μsec, also ca. 1/3 Millisekunde.
Wir werden von jetzt an die Start- und Stop-Bits nicht mehr angeben und nur die inneren acht Bits, also ein Byte, anschreiben.
Eine MIDI-Botschaft besteht aus einem Statusbyte und 2-3 Datenbytes; das Statusbyte beginnt mit dem Bit-Wert 1, die Datenbytes mit dem Bit-Wert 0, siehe Bild 44 oben. Das Statusbyte gibt den Befehlstyp und Adresse des Typs an, während die Datenbytes die Werte angeben, welche die Befehle spezifizieren.
Die Messages sind durch verschiedene Status-Byte-Typen in eine Hierarchie von Botschaften gegliedert, siehe unterer Teil von Bild 44. Die Hierarchie unterscheidet zwischen Channel- und System-Messages. Erstere sind anschaulich gesagt Botschaften, die einzelnen Musikern Befehle erteilen. Jeder Channel ist so etwas wie ein Musiker. Es gibt 16 Musiker, die durch die Werte des zweiten halben Byte im Statusbyte einer Channel-Message numeriert sind. Der "Musiker" kann aber jederzeit sein Instrument wechseln. Ein solcher Instrumentenwechsel wird durch eine Programm Change Message bewirkt. Dies ist der Befehl mit Statusbyte 1100.... in den Channel Voice Messages (untere Liste Bild 44, drittletzte Zeile).
Die Channel Voice Messages betreffen Einzelstimmen, während die Channel Mode Messages das Zusammenspiel der Channels regeln.
Die System Messages betreffen das gesamte System, sie beginnen immer mit einem Statusbyte der Gestalt 1111..., siehe Bild 45. Von den System Messages gibt es drei Typen: System Exclusive, System Common und System Realt Time Messages. Erstere sind reserviert für System-Botschaften, die herstellerspezifisch sind. So kann jeder Instrumentenhersteller seine Spezialitäten einbringen. Die System Common Messages betreffen allgemeine Systemeinstellung wie etwa die Position im gerade ablaufenden Musikstück. Die Realt Time Messages betreffen Zeitinformationen (etwa die Timing Clock, die die Ticks ausgibt).
In der Tat ist die Zeitbehandlung bei MIDI nicht ganz trivial. Es wird eigentlich eine mentale Zeit benutzt, sie wird in Ticks gemessen, welche ein bestimmter Bruchteil einer Viertelnote sind (normal ist es ein 24stel einer Viertelnote, aber das kann stark variieren). Wie lange ein Tick dauert, bestimmt die Tempo-Information. Sie wird jeder MIDI-Datei als sogenannte Meta-Information beigegeben.
MIDI-Dateien speichern die MIDI-Messages eines Musikstücks, damit man dasselbe später wieder spielen (lassen) kann auf MIDI-Geräten, oder auch weiterbearbeiten kann auf dazu geeigneter Software (Sequenzer). Die Standard-MIDI-File-Formate regeln die Syntax dieser MIDI-Dateien. Bild 46 zeigt den Ausschnitt aus einem Musikstück in MIDI-Messages. In der Tabelle (b) sehen wir in der ersten Spalte ein Delta Time. Dies ist immer gerade die Anzahl Ticks von einem Ereignis zum nächsten. In diesem Beispiel wird eine Viertelnote in 480 Ticks aufgeteilt. Die erste 16tel-Note hat einen Befehl Note On: "Fang an zu spielen". Dann steht channel1: der erste Musiker soll spielen. Dann soll die Tonhöhe 52 (Note e) und die Lautstärke 53 (=velocity, ein Wert zwischen 0 und 127) gespielt werden. Nach der ersten 16tel-Note der Partitur (a) erscheint 120 Ticks, also eine 16tel-Note, später ein zweites Ereignis: Spiele jetzt dieselbe Tonhöhe mit velocity = 0: M.a.W.: Beende die erste Note! ("Running Status" sagt einfach, dass das geltende Statusbyte immer dasselbe bleibt bis auf Widerruf, das erspart Übertragungszeit!). Das nächste Delta Time ist 0, also gleichzeitig mit Beenden der ersten Note eine zweite Note der Tonhöhe 55 und Lautstärke 38 anspielen, etc.
| Es soll nicht gedacht, sondern gespielt werden, und zwar ganz schnell und direkt. |
|---|
 ZURÜCK |
WEITER |