[an error occurred while processing this directive]
nmz-archiv
nmz 2003/05 | Seite 21
52. Jahrgang | Mai
Internet/Computer
In Bildern komponieren
Die grafische Programmiersprache Max/MSP (Teil 1)
Jeder Komponist, der seine Musik mit Hilfe von Computern und Computerprogrammen
produziert, stößt früher oder später an die
Grenzen seiner Werkzeuge. Werkzeuge werden geplant und hergestellt,
um eine verallgemeinerte Funktion ausführen und dadurch eine
ganze Reihe von Aufgaben lösen zu können. Ein Werkzeugmacher
kann jedoch kaum alle möglichen Aufgaben, für die sein
Werkzeug jemals eingesetzt werden wird, vorwegnehmen. Wie fabelhaft
wäre es, könnte man seine Werkzeuge selbst herstellen
und ein Orchester mit Instrumenten, die passend zum zu lösenden
musikalischen Problem entworfen wurden, realisieren!
Die Programmierung von Computern gilt gemeinhin als kryptische
Angelegenheit. Sie scheint lediglich Spezialisten vorbehalten,
die willens sind, große Mengen Zeit
und Kraft darin zu investieren, abstrakte, dem menschlichen Maße unangemessene
Texte zu lesen und zu schreiben. Mittels dieser Texte wird die in ihrem Aufbau
und ihrer Funktionsweise noch unverständlichere und noch menschenfernere
Rechenmaschine in Bewegung gesetzt und durch Hilfsmittel wie grafische Oberflächen
und Mauszeiger bedienbarer gemacht. Das ist im Wesentlichen zutreffend und
verweist auf eine zentrale Eigenschaft, durch die sich Programmiersprachen
voneinander unterscheiden lassen: wie viele der intrikaten technischen Details
der Computerhardware werden vor dem Programmierer beziehungsweise Anwender
mit Hilfe von Abstraktionen verborgen. Oder andersherum, welche der Möglichkeiten,
die eine gegebene Computerhardware bietet, möchte der Programmierer nutzen
und auf diese zugreifen können.
Eine der wichtigsten Prämissen für die Wahl einer Programmiersprache
ist demnach, wie nah oder wie fern der Maschine ein Autor sich verorten möchte.
Eine Sprache, die von der Hardware stark abstrahiert, hat den Vorteil, dass
Paradigmen aus der „realen“ Welt zur Veranschaulichung als Metapher
gewählt werden können. Diese Paradigmen sind dem Nutzer bekannt,
so dass er sie mit überschaubarem Aufwand auf den Computer übertragen
kann und nicht ein neues erlernen muss. Ein Beispiel hierfür wäre
der „Schreibtisch“ einer grafischen Benutzeroberfläche, auf
dem „Dokumente“ abgelegt werden, die vom Bild (Icon) eines beschriebenen
Papierblatts symbolisiert werden. Diese Dokumente können mit dem „Mauszeiger“ als
Stellvertreter der Hand angefasst, an einen anderen „Ort“ geschoben,
in einen „Recycler“ genannten Mülleimer befördert oder
per elektronischer „Post“ an eine andere Adresse „verschickt“ werden.
Nachteilig an diesem metaphorischen Paradigma ist, dass dem Anwender im Falle
einer technischen Panne deren Ursachen verborgen bleiben und in aller Regel
keine grafisch aufbereiteten Werkzeuge zur Verfügung stehen, um die Störung
auf der metaphorischen Ebene analysieren und beheben zu können.
Auf die Domäne der Software-Entwicklung übertragen würde sich
der Vorteil einer metaphorischen Darstellung in einer leichten Handhabbarkeit
der Programmiersprache unter Verwendung von Alltagswissen ausbuchstabieren.
Die Schattenseite würde gebildet durch eine Einschränkung der Möglichkeiten,
auf die der Entwickler zugreifen kann, wie auch die geringere Effizienz einer
solchen Sprache gegenüber maschinennahen, denn der Bedienkomfort kommt
nicht ganz umsonst, sondern kostet immer auch Rechenzyklen.
Eine kurze Geschichte von Max/MSP
Mit dieser Präambel möchte ich die Programmiersprache
Max/MSP vorstellen, die sich schlüssig in die oben genannten
Kriterien einordnen lässt. Die Geschichte von Max beginnt
1986, als der Komponist und Software-Entwickler Miller Puckette
am Pariser Ircam einen grafischen Hochsprachen-Editor namens Patcher
für die Apple-Plattform veröffentlichte, dessen Funktionalität
auf die Erzeugung und Verarbeitung von Kontrolldaten per MIDI beschränkt
war. Patcher steuerte damit den „4X“, eine externe
Recheneinheit zur Echtzeit-Klangsynthese. 1990 wurde Patcher an
die amerikanische Firma Opcode lizensiert, dort von David Zicarelli
erweitert und nach dem Vornamen eines der bedeutendsten Pioniere
der Computermusik, Max Mathews, in Max umgetauft.
Ebenfalls 1990 wurde am Ircam eine um Software-Module zur Audio-Verarbeitung
erweiterte Fassung von Max vorgestellt. Aufgrund der aus heutiger
Sicht geringen Rechenleistung von PC- und Workstation-Computern
wurde eine dedizierte Hardware-Plattform namens ISPW (Ircam Signal
Processing Workstation) entwickelt, die als Einschubkarte für
Workstations der Firma NeXT vermarktet wurde. Die ISPW-Plattform
stellte zusammen mit der Programmiersprache Max/ISPW für viele
Jahre eines der flexibelsten Systeme zur Realisierung von Kompositionen
dar, die auf Echtzeit-Prozesse zurückgriffen. Dem entsprechend
hoch war in dieser Phase bis circa 1998 ihre Beliebtheit unter
Komponisten und zahllose musikalische Werke sind für diese
Plattform entstanden.
Ende 1997 veröffentlichte Zicarelli eine Modul-Bibliothek
zur Audioverarbeitung, MSP („Max Signal Processing“),
die derjenigen von Max/ISPW sehr ähnlich war und nahtlos in
die Max-Umgebung integriert werden konnte. Im Unterschied zu Max/ISPW
benötigte sie jedoch keine besondere und äußerst
kostspielige Audio-Hardware mit dazugehöriger Workstation,
sondern lief bereits sinnvoll auf den schnelleren Modellen der
damals erhältlichen Apple-Computer. 2002 wurde Max/MSP durch
die ebenfalls nahtlos integrierte Bibliothek „Jitter“ zur
effizienten Generierung und Verarbeitung von Grafik-Daten und Bewegtbild
erweitert. Jüngst wurde eine Version von Max/MSP/Jitter für
Apples reformiertes Betriebssystem OS X veröffentlicht. Eine
Version für Windows XP ist angekündigt.
Am Ircam wird Max in einem anderen Strang ebenfalls weiterentwickelt.
Verfügbar ist dort das Produkt jMAX (Java MAX), das mit ähnlichem
Umfang wie Max/MSP ausgestattet, jedoch als Open Source frei erhältlich
und bisher auf die Betriebssysteme Linux, Windows und OS X übertragen
worden ist.
Programme zeichnen
Was macht es so reizvoll mit Max/MSP zu arbeiten, was ist das
Besondere daran? Zum einen handelt es sich um eine Hochsprache
in dem Sinne,
dass sie über sehr umfangreiche Sammlungen fertiger und
getesteter Programm-Module („Objekte“) verfügt,
die oft benötigte Funktionen bereitstellen. Diese können
baukastenartig miteinander zu größeren Einheiten verknüpft
werden. Zum anderen werden diese Module nicht durch einen Zeichen
für Zeichen einzugebenden Text miteinander in Beziehung
gesetzt, sondern mithilfe einer grafischen Repräsentation,
in der die verwendeten Module als „Bauklötzchen“ mit „Ein-“ und „Ausgängen“ dargestellt
sind. Die Verbindungen zwischen den Klötzchen werden durch „Kabel“ hergestellt,
durch die die Module miteinander „Nachrichten“ austauschen,
die je nach Bedarf ausgelöst und an die angeschlossenen
Module verschickt werden. Die eingangs genannten Vor- und Nachteile
von mehr oder minder großer Hardwarenähe greifen hier
freilich in vollem Umfang.
Eine weitere Erleichterung für die Entwicklung von Programmen
ist, dass der Prozess des Programmierens bei Max/MSP nicht zweigeteilt
ist in die Erstellung des Befehlscodes in einem Texteditor und
die darauffolgende Übersetzung in maschinenlesbaren, ausführbaren
Code (Kompilierung). Dieses unter Programmiersprachen sehr weit
verbreitete Modell hat den Nachteil, dass bei jeder auch noch so
kleinen Änderung am Programm das alte Programm beendet, der
Befehlscode editiert, übersetzt und das neue Programm gestartet
werden muss. Erfolg oder Misserfolg der Änderung kann erst
nach Ablauf dieser Schritte beurteilt werden.
Die Trennung zwischen menschenlesbarem Befehlscode und maschinenlesbarem
Programm ist im Gegensatz dazu bei Max/MSP auf ein Minimum reduziert.
Die Erstellung eines Programms kann gewissermaßen „am
offenen Herzen“ geschehen.
Dies liegt hauptsächlich im Konzept der Sprache begründet.
Um eine Funktion zu erweitern, wird ein Modul aus einer Bibliothek
ausgewählt und in den Befehlstext eingefügt. Es mag paradox
klingen, aber dadurch es ist möglich, Programme zu ändern,
während sie laufen, und das Ergebnis der Änderung unmittelbar
zu evaluieren. Die auf diese Weise entstehenden kurzen Wege zwischen
Aktion durch den Programmautor und Reaktion durch das Konstrukt
beschleunigen in Kombination mit sehr brauchbaren Modul-Bibliotheken
die Programmentwicklung in Max/MSP auf ein hohes Maß. Diese
Eigenschaft macht Max/MSP ideal für die rasche Entwicklung
von Prototypen, in deren Verlauf viele verschiedene Möglichkeiten
zur Lösung eines Problems probiert und evaluiert werden sollen.
Beispiel einer im Text
erwähnten Transpositions-Operation
Als Beispiel sei das in der Abbildung gezeigte simple Programm
(„Patch“) zur Tonhöhen-Transposition gegeben.
Eine Bildschirm-Tastatur zur Noteneingabe ist über ein Berechnungs-Modul
[ + 12 ] mit einer weiteren Bildschirm-Tastatur zur Notenausgabe
verbunden. Zusätzlich wird jeder Notenwert vor und nach der
Transposition als Notenname symbolisch angezeigt. Eine per Bildschirm-Tastatur
erzeugte „Note“, C2, wird nun durch das Berechnungs-Modul
[ + 7 ] um eine Quinte aufwärts transponiert und auf der unteren
Bildschirm-Tastatur grafisch angezeigt. Wird während der Laufzeit
des Programms das Berechnungs-Modul nach [ - 7 ] geändert,
berechnet das Programm bei der nächsten eintreffenden „Note“ eine
Transposition um sieben Halbtöne nach unten.
Dieses recht einfache Beispiel beleuchtet das Konzept des grafisch
repräsentierten Moduls, das grafische Erstellen von Programmen
durch Verbindung von Modulein- und -ausgängen mit Verbindungslinien,
die Kommunikation der Module bei Bedarf mittels Nachrichten sowie
die daraus entstehende Möglichkeit, das Programm während
seiner Ausführung zu ändern.
Im zweiten Teil werden umfangreichere Beispiele, Reflexionen über
die ästhetischen Implikationen der Sprache sowie ihren Einfluss
auf das kompositorische Denken aufgezeigt.
