Meloncillo Рeine graphische Benutzerober߬ache zur musikalischen Raumklangsteuerung mit Implementierung einer OSC-Schnittstelle zur Klangsynthese

Magisterarbeit von Hanns Holger Rutz, Matr.-Nr. 192946 Technische Universit¨at Berlin Kommunikationswissenschaft Betreuer: Prof. Dr. Stefan Weinzierl La musique du futur? Sˆurement bas´ee sur le son et au-del`ades notes“ ” (Edgard Var`ese 1947)

Var`eses Denken war empirisch. Er interessierte sich dafur,¨ ” wie es klang – nicht wie es gemacht war.“ (Morton Feldman 1966)

Die selbst¨andige Anfertigung versichere ich an Eides Statt. Inhaltsverzeichnis

1 Einfuhrung¨ 5 1.1 Begriff der Raumklangsteuerung ...... 5 1.1.1 Abgrenzung zu Auralisationsverfahren ...... 8 1.1.2 Abgrenzung zu Live-Diffusionsverfahren ...... 8 1.2 Historische Wurzeln ...... 9 1.3 Vorhandene Software zur Raumklangsteuerung ...... 10 1.3.1 APB-Tools Σ 1 ...... 10 1.3.2 zplane.development z.matrix ...... 12 1.3.3 Wonder ...... 13 1.3.4 Surround Panning Objekte ...... 13 1.4 Hardware basierte Raumklangsteuerung ...... 14 1.5 Raumklang-Synthese Plug-Ins ...... 16 1.5.1 VBAP – Vector Based Amplitude Panning ...... 16 1.5.2 IRCAM Spat˜ ...... 17 1.5.3 Spatialisierung mit CSound ...... 18 1.6 Notwendigkeit einer neuen Raumklangsteuerung ...... 19

2 Entwicklung des Programms Meloncillo 20 2.1 Tendenzen in der Entwicklung von Musiksoftware ...... 20 2.2 Designspezifikation fur¨ eine neue Raumklangsteuerung ...... 21 2.2.1 Trennung von Oberfl¨ache und Signalverarbeitung ...... 21 2.2.2 Abstraktion vom Synthesemodell ...... 22 2.2.3 Anwender mit und ohne Programmiererfahrung ...... 23 2.2.4 Unabh¨angigkeit vom Betriebssystem ...... 23 2.2.5 Zwei grundlegende Objekttypen ...... 24 2.2.6 Echtzeit und Offline Modus ...... 24 2.2.7 Diskrete Datenstr¨ome ...... 25

3 Programmarchitektur 26 3.1 Sprache und Arbeitsumgebung ...... 26 3.2 Packages Uberblick¨ ...... 28 3.3 Session ...... 28 3.4 Receiver, ReceiverCollection ...... 30 3.5 Transmitter, TransmitterCollection ...... 31 3.6 Timeline ...... 32 3.7 Events ...... 32 3.8 Threads ...... 33

3 Inhaltsverzeichnis

4 Graphische Benutzerober߬ache 35 4.1 Surface : zweidimensionale Momentansicht ...... 35 4.1.1 Hilfs-Paletten und Werkzeuge ...... 37 4.1.2 ReceiverEditor ...... 39 4.1.3 Matrix Meter ...... 40 4.2 Timeline : horizontale Zeitdarstellung ...... 40 4.2.1 Trajektorien Daten-Format ...... 41 4.2.2 Transport Palette ...... 43

5 Plug-In Schnittstellen 44 5.1 Offline (Nicht-Echtzeit) ...... 44 5.2 Realtime (Echtzeit) ...... 46 5.3 Common Lisp furJava...... ¨ 49 5.3.1 Die LispPlugIn Klasse ...... 50 5.3.2 Ein Beispielscript ...... 51 5.4 Open Sound Control ...... 54 5.4.1 Protokollubersicht¨ ...... 54 5.4.2 Implementierung in Meloncillo ...... 56 5.4.3 Anbindung an SuperCollider ...... 57

6 Resum´e 62 6.1 Anwendungsbeispiel ...... 62 6.2 Probleme ...... 67 6.3 Ausblick ...... 68

Literaturverzeichnis 70

Anhang: Abbildungen, Quelltexte 73

4 1 Einfuhrung¨

Die vorliegende Magisterarbeit beschreibt den Entwurf und die Realisierung einer Software- Applikation zur musikalischen Raumklangsteuerung. Das im wesentlichen aus einer graphi- schen Benutzeroberfl¨ache bestehende Programm mit dem Namen Meloncillo“ erlaubt die ” Gestaltung von Trajektorien in einem zweidimensionalen Raum und kann in Verbindung mit einem existierenden Klangsynthese-Programm wie SuperCollider dazu verwendet werden, verr¨aumlichte Kl¨ange zu berechnen oder in Echtzeit abzuspielen. Fur¨ die Echtzeit-Steuerung ist eine Open Sound Control (OSC) Schnittstelle vorgesehen. Eine script-gesteuerte Plug-In Schnittstelle erm¨oglicht es, unterschiedliche Modelle der Verr¨aumlichung zu benutzen.

Die Arbeit ist dadurch motiviert, daß die Raumklangsteuerungen, die dem Autor bekannt sind, zu wenig gestalterische Freiheiten bieten oder nicht ohne weiteres fur¨ die heute g¨angigen Computer-Plattformen verfugbar¨ sind. Das hier vorgestellte Programm soll neue Sichtweisen auf musikalische R¨aumlichkeit ¨offnen.

CD-ROM

Der Quelltext und die Quelltext-Dokumentation k¨onnen aus Platzgrunden¨ nicht abgedruckt werden. Eine CD-ROM ist beigefugt,¨ die alle n¨otigen Dateien enth¨alt:

• Quelltext • HTML Dokumentation aller Pakete und Klassen (javadoc) • Xcode IDE Projekt-Datei • kompiliertes Programm und Mac OS X Application Wrapper • externe Bibliotheken • Beispiel-Script, -Session und -Kl¨ange

1.1 Begriff der Raumklangsteuerung

Der Begriff Raumklang enth¨alt bereits ein musikalisches Element, w¨ahrend die englische Ubersetzung,¨ etwa spatial sound, einen physikalischeren Charakter bekommt – sound kann ruck¨ ubersetzt¨ auch Schall heißen. Physikalische Begriffe w¨aren Raumschall oder Raumakustik.1 Zwischen Raumklang und Raumakustik besteht ein wesentlicher Unterschied: Raumakustik beschreibt den Klang des Raumes, w¨ahrend Raumklang die Gestaltung von Klang im Raum meint. Da eine musikalische Auffuhrung¨ meist in einem geschlossenen Raum stattfindet, muß

1vgl. [Haller 1995], S. 75

5 1 Einfuhrung¨ sich der Komponist naturlich¨ auch mit Raumakustik befassen. Das ist jedoch nicht Gegen- stand dieser Arbeit. Raumakustik tritt beispielsweise nicht bei Kopfh¨orerubertragung¨ oder Beschallung im offenen Feld auf. Ein anderer Fall ohne ¨außere Raumeinwirkung sind K¨orper- schallubertragung¨ und K¨orperstimulation durch Aktuatoren.2

Die ganz unterschiedlich akzentuierten Aspekte von R¨aumlichkeit sind eines der Hauptmerk- male von Klangkunst und Klanginstallation. Fur¨ einen Uberblick¨ sei auf die Artikel des Katalogs Klangkunst zum Festival Sonambiente 1996 hingewiesen3. Ein paar Beispiele: In Bill Fontanas Klangbrucke¨ K¨oln-Tokyo wird das akustische Bild zweier sehr weit voneinan- der entfernter Orte auf der Welt durch Satelliten-Transmission ausgetauscht. Die Arbeit steht in gewissem Kontext zu der von Murray Schafer entwickelten Idee der Klang¨okologie. Alvin Lucier l¨aßt dagegen in I’m Sitting in a Room die Resonanzen der Auffuhrungsorte¨ sprechen, La Monte Young verwendete stehende Wellen. In soundbits von Robin Minard wird die R¨aum- lichkeit nicht nur durch dem Objekt Gegenuberstehen,¨ sondern gleichfalls durch Herantreten und Entlangschreiten an diesem ausgedehnten und in die Architektur integrierten Gebilde erfahren.

Die begriffliche N¨ahe von Raumklang und Raumakustik kann leicht zu Verwirrungen fuhren:¨

Der Komponist orientiert sich am geometrischen Raum und versucht, in dessen ” erkennbaren Grenzen einen ebenfalls erkennbaren, d.h. erh¨orbaren Klangraum zu schaffen. Dieser Klangraum kann dem geometrischen Raum entsprechen, er muß es nicht.“4

Raum“ wird in zwei unterschiedlichen Bedeutungen benutzt, obwohl Hans Peter Haller ver- ” sucht, die Verschiedenheit durch die Attribute geometrisch respektive klanglich zu betonen.5 Viele Metaphern in der Musik sind r¨aumlich-geometrischer Natur, so spricht man beispiels- weise von einer hohen Tonlage, einer melodischen Linie oder Kontur; die Menge der verwende- ten T¨one bildet den Ton-Raum6. Herbert Eimert unterscheidet neben diesem metaphorischen Raum zwischen dem Musik-Raum, der durch die Raumakustik bestimmt ist, und dem musi- ” kalischen Vorstellungsraum, wie er in der Phantasie des Komponisten besteht, wie er vom H¨orer nachvollzogen wird und wie er sich in den Noten, im Notationsraum der aufgezeich- neten Musik niederschl¨agt.“7 Wird Musik r¨aumlich verteilt wiedergegeben, so kann dieser neue Raum fur¨ das Ohr ein gekrummter,¨ nicht euklidischer Raum“ sein. Eimert nennt die- ” sen Raum einen Raummusik-R[aum], in dem die Tonbewegung in die r¨aumlich-plastische ” Konfiguration der Klangfelder uberf¨ uhrt¨ wird.“

Die Verortung dieser Arbeit wird klarer, wenn wir den Begriff der Steuerung betrachten. Haller gibt eine sehr ingenieursm¨aßige Beschreibung von Klangsteuerung:

2Beim Klanganzug der Kunstlerin¨ Lynn Pook werden sechzehn Lautsprecher am K¨orper befestigt – Der ” menschliche K¨orper wird zum Klangraum“. Das Beispiel zeigt, daß Raumerfahrung nicht nur durch (echte oder simulierte) von unterschiedlichen Seiten auf das Ohr treffende Schallwellen gemacht werden kann. Dazu z¨ahlen auch einige Arbeiten von Bernhard Leitner. 3[de la Motte-Haber 1996] 4[Haller 1995], S. 75. Kurz davor geht Haller explizit darauf ein, daß bei der Gestaltung von Klangwegen die Interaktion mit der Raumakustik bedacht werden muß. 5Bezeichnenderweise beginnt Martin Supper in seinem Buch uber¨ Elektronische Musik ([Supper 1997]) das Kapitel uber¨ Raumklang mit einem Zitat von Rudolf Carnap uber¨ die Konfusion, die durch die unter- schiedliche Verwendung des Raumbegriffs entsteht. 6[Eimert/Humpert 1973], S. 271f 7ebd.

6 1 Einfuhrung¨

Klangsteuerung in der Elektronischen Klangumformung bedeutet weder Trans- ” formation noch Selektion einer Tonquelle. Sie kann fur¨ beide eine kontrollierende Funktion ubernehmen,¨ hat jedoch auf die direkte Erweiterung eines Klangspek- trums keinen Einfluß. Klangsteuerung heißt – wie der Name aussagt – Steuerung von Klanginformationen jeglicher Art, von Instrumenten oder Stimmen, original oder elektronisch bearbeitet.“8

Anders ausgedruckt¨ ist Klangsteuerung ein formgebender Prozeß, der auf einer hierarchisch ubergeordneten¨ Ebene stattfindet. Die Prozeßhaftigkeit, der dynamische Charakter der Klang- steuerung, wird durch weitere Bezugnahme auf Regelungstechnik wie auch die kontrollie- ” rende Funktion“ unterstrichen.9 In Hallers Ger¨aten wird zur Kontrolle oft ein Mikrophon benutzt, das w¨ahrend der Performance eine Klangumformung steuert. In den klassischen nach MUSIC V modellierten Musiksprachen bezeichnen Kontrolldaten diejenigen Daten, die dynamisch uber¨ die Zeit – und in der Regel mit konstanter Rate abgetastet – Einfluß auf Klangparameter und -transformationen nehmen.10

Raumklangsteuerung wird nun definiert als ein Mittel zur dynamischen Formgebung von Bewegungen, Verteilungen und Transformationen von Kl¨angen, die r¨aumlich, das heißt uber¨ mehrere Lautsprecher wiedergeben werden sollen. Das bedeutet, daß die Mehrkanaligkeit bereits in den Klangverteilungen und -transformationen angelegt ist und explizit gestaltet werden kann. Beispiel: Wenn ein monophoner Ausgangsklang mit unterschiedlichem Fre- quenzgang gefiltert und auf verschiedenen Lautsprechern ausgeben wird, ist das eine Form von Raumklang, denn der Klang wurde r¨aumlich gestaltet. Der benutzte Filter ist jedoch nur dann als Raumklangsteuerung zu bezeichnen, wenn in ihm selbst a) die dynamische, zeitver¨anderliche Steuerung und b) die Variation des Frequenzganges uber¨ verschiedene Aus- gangskan¨ale (oder allgemein eine r¨aumliche Situation) vorhanden sind. Umgekehrt wird ein Objekt zur Raumklangsteuerung, wenn es andere Objekte – ob einen Mixer oder ein Filter spielt dabei keine Rolle – dynamisch r¨aumlich kontrolliert, zum Beispiel indem es fur¨ jeden Ausgangskanal einen separaten Filter ansteuert.

Das Adjektiv in musikalischer Raumklangsteuerung soll unterstreichen, was in der eingangs zitierten Aussage Morton Feldmans uber¨ Edgard Var`ese zum Ausdruck kommt, und was Trevor Wishart nur unmerklich variiert, wenn er in Audible Design schreibt:

We [composers] may embark on signal-processing procedures which will appear ” bizarre to the scientifically sophisticated [...] The question we must ask as musi- cians however is not, are these procedures scientifically valid, or even predictable, but rather, do they produce aesthetically useful results on at least some types of sound materials.“11

Dies ist nicht als Aufforderung zu verstehen, unwissenschaftlich zu sein, sondern im Gegenteil, sich wissenschaftlicher Erkenntnisse zu bedienen, aber sich – also hier das Programm – nicht auf das zu beschr¨anken, was zun¨achst wissenschaftlich oder physikalisch plausibel scheint.

8[Haller 1995], S. 67. 9vgl. auch [Eimert/Humpert 1973], S. 328 10Die Rate dieser Daten wird als Controlrate, abgekurzt¨ kr, bezeichnet und liegt aus rechen¨okonomischen Grunden¨ meist etwa ein bis zwei Gr¨oßenordnungen unter der Abtastrate fur¨ Audiodaten. 11[Wishart 1994], S. 5

7 1 Einfuhrung¨

Musikalische Raumklangsteuerung bedeutet sowohl, daß nicht-physikalische Raumvorstellun- gen umgesetzt werden k¨onnen, als auch, daß Brucken¨ zu algorithmischer Komposition vor- gesehen sind.

1.1.1 Abgrenzung zu Auralisationsverfahren

Auralisation ist ein Verfahren, das unter Verwendung physikalischer oder mathematischer Modelle das Schallfeld, in dem sich eine Klangquelle befindet, reproduziert und dem H¨orer den Eindruck vermittelt, tats¨achlich an einer bestimmten Position in diesem Schallfeld zu sein.12 Ein anderer Ausdruck ist somit Soundfield Reproduction, zu deutsch Schallfeldreproduk- tion, als Unterkategorie von (virtueller) Raumakustik. Die wichtigsten technischen Verfahren sind die Binauraltechnik, das heißt die Raumsimulation durch Einbezug der Kopfubertra-¨ gungsfunktion (HRTF) und Wiedergabe uber¨ Kopfh¨orer, und die als Transaural-Technik bezeichnete Lautsprecher-Variante im reflexionsarmen Raum. Daneben wird auch die neuere Wellenfeldsynthese (WFS) als Auralisationstechnik verwendet.13

Das Ziel der Raumklangsteuerung ist nicht die Auralisation. Kurz dargestellt werden soll jedoch das WFS Programm Wonder (Abschnitt 1.3.3), da es sich explizit als musikalische Raumklangsteuerung versteht. Das in dieser Arbeit entwickelte Programm kann naturlich¨ mit einem Auralisationsverfahren verknupft¨ werden, es ist allerdings nicht speziell dafur¨ konzi- piert. Insbesondere sind Binaural- und Ambisonics-Rendering durch Steuerung von CSound m¨oglich (siehe Abschnitt 1.5.3). Es wird jedoch nicht auf die akustischen Grundlagen der Schallfeldreproduktion und des r¨aumlichen H¨orens eingegangen.14

1.1.2 Abgrenzung zu Live-Diffusionsverfahren

Das Haupteinsatzgebiet der Software soll in der Komposition liegen, das heißt sie soll opti- miert werden fur¨ eine Arbeitsweise,

• in der die Zeitebene der Bearbeitung von der Zeitebene der Performance des Stuckes¨ entkoppelt ist • in der die Daten nichtlinear bearbeitet werden • in der sich die Bearbeitung uber¨ mehrere Sitzungen erstreckt • in der Bearbeitungen evtl. verworfen werden

Dies resultiert sowohl aus pers¨onlichen Pr¨aferenzen als auch aus der Tatsache, daß im Bereich der Live-Elektronik bereits sehr m¨achtige Werkzeuge vorhanden sind. Es ist nicht Aufgabe dieser Arbeit, eine Software wie Max/MSP zu uberbieten,¨ stattdessen soll genau an den Punkten angesetzt werden, die durch die weitgehende Fixierung auf Echtzeit-F¨ahigkeit in Max nicht oder nur ungenugend¨ beachtet werden. Weitere Erl¨auterung dazu folgen in der Designspezifikation.

12sinngem¨aß nach [Kleiner et al. 1993] 13Eine sehr knappe Einfuhrung¨ zu WFS geben [de Vries/Boone 1999]; eine mit Medien aufbereitete Website ist http://wfs.topicbase.net/ 14Siehe dazu z.B. [Stuart 1996] oder [Schneider 1995], S. 1–22. Im Aufsatz von D. G. Malham wird die Schall- feldreproduktion am Ambisonics Verfahren erl¨autert ([Malham 1998]).

8 1 Einfuhrung¨

Aus diesem Grund wird auch nicht weiter auf spezielle Live-Diffusions-Strategien eingegan- gen. Kurz genannt werden soll zumindest die akusmatische Diffusion, in der in der Regel ein ein- oder zweikanaliges Stuck¨ mit Hilfe einer Live-Mischung ( Interpretation“) auf eine ” Vielzahl unterschiedlicher Lautsprecher verteilt wird, wobei die variablen Charakteristiken der Lautsprecher gezielt als instrumentale Formung des Klanges betrachtet werden.15

1.2 Historische Wurzeln

Obwohl der Raum als Parameter auch in der klassischen Musik nicht unbekannt war, sich zum Beispiel in der r¨aumlichen Aufteilung der Instrumentengruppen manifestierte, in der Ausnutzung der Raumakustik in Kirchen fur¨ Ch¨ore usw., und ohne auf spezielle Projekte wie die utopische Universe Symphony von Charles Ives einzugehen,16 beginnt die gezieltere Auseinandersetzung mit dem Einsatz von Lautsprechern in der elektronischen und konkreten Musik, das heißt in den 50er Jahren.17 In Karlheinz Stockhausens Gesang der Junglinge¨ von 1956 werden funf¨ kreisf¨ormig angeordnete Lautsprecher-Gruppen verwendet, die das Publi- kum umgeben, statt ihm frontal zu begegnen.18 Auch in der funf¨ Jahre davor uraufgefuhr-¨ ten Symphonie pour un homme seul von Pierre Schaeffer und Pierre Henry (1950) werden die Kl¨ange von im Raum verteilten Lautsprechergruppen wiedergegeben. Im Gegensatz zu Stockhausen ist diese Verteilung weniger Ergebnis eines strikten Auskomponierens, sondern geschieht durch eine Live-Interpretation auf den unterschiedlich klingenden Lautsprecher- Instrumenten.

Neben der Erfindung des Radios als der Verr¨aumlichung des Klanges – indem zwischen Sender und Empf¨anger praktisch beliebige Distanzen liegen k¨onnen – ist die Auseinandersetzung mit Zeit in der Malerei als symmetrischer Gegenpart dafur¨ zu nennen, daß Anfang des 20. Jahr- hunderts die Musik begann sich zu verr¨aumlichen. Der einer ¨alteren Generation angeh¨orende, nach Amerika ausgewanderte Franzose Edgard Var`ese arbeitete seit 1929 am letztlich nicht realisierten Werk Espace, das diese neue Aufmerksamkeit bereits im Titel zeigt. Realisiert worden ist 1958 das bekannte Po`eme Electronique´ fur¨ den Pavillon der Firma Philips auf der Weltausstellung jenes Jahres. Mehrere hundert Lautsprecher auf den Innenfl¨achen des von Le Corbusier und Iannis Xenakis entworfenen zeltartigen Baus standen ihm fur¨ eine r¨aumliche Komposition zur Verfugung.¨ Das Ausgangsmaterial von Var`ese hatte die Form eines Tonbands mit drei Spuren, von denen zwei stereophonisch verteilt werden konnten und die dritte aufgezeichneten Raumhall enthielt. Die r¨aumliche Verteilung geschah mit Hilfe von synchronen B¨andern, die Steuerbefehle fur¨ Relais enthielten. Die Relais schalteten die Lautsprecher-Gruppen ein und aus, mit denen sich bestimmte Klangbewegungen realisie- ren ließen. Angeblich hat Var`ese die Intonation“ der Bewegungen der Verantwortung der ” Ingenieure uberlassen.¨ 19

15vgl. [Gertig et al. 1995], S. 325 16vgl. [de la Motte-Haber 1996], S. 209 17Mit dem Beginn des Rundfunks datieren die ersten Lautsprecher in die 20er Jahre, vgl. [Ruschkowski 1998], S. 56–60; der Aspekt der r¨aumlichen Wiedergabe mittels mehrerer Lautsprecher spielte dabei noch keine Rolle. 18[Ruschkowski 1998], S. 242, 252f 19[de la Motte-Haber 1993], S. 83–110. Nach einem Drehbuch von Le Corbusier wurden zur Musik von Var`ese Dias an die W¨ande projiziert.

9 1 Einfuhrung¨

1.3 Vorhandene Software zur Raumklangsteuerung

Bei der Entwicklung einer neuen Software ist zun¨achst zu betrachten, welche bestehenden L¨osungen bereits existieren und wo ihre Vorteile und Nachteile liegen. Ohne Anspruch auf Vollst¨andigkeit und ohne auf die Vielzahl individueller Patches in Sprachen wie Max ein- zugehen, sollen die g¨angigsten Programme vorgestellt werden. Die auf Hardware basieren- den Implementationen werden kurz im Anschluß dargestellt. Darauf folgt eine kursorische Ubersicht¨ uber¨ Raumklang-Syntheseverfahren, die in Form von Plug-Ins durch eine Host- Applikation gesteuert werden k¨onnen.

Die Grundkonzepte unterscheiden sich in den meisten F¨allen nicht von der Pionier-Arbeit John Chownings20 zu Beginn der 70er Jahre. Darin beschreibt er die akustischen Merkmale der r¨aumlichen Ortung (interaurale Intensit¨ats- und Laufzeitunterschiede) und schl¨agt vor, zur Simulation r¨aumlicher Distanz variable Reverberation und Frequenz-Filterung zu benut- zen. Nach seinem Modell wird mit Hilfe von quadrophonisch den H¨orer umgebenden Laut- sprechern ein virtueller Raum um den tats¨achlichen Abh¨orraum konstruiert. Die Klangquelle wird zwischen jeweils benachbarten Lautsprechern gepannt21, durch variables Delay entsteht ein Doppler-Shift in Abh¨angigkeit von der Geschwindigkeit der Bewegung. Die Bewegun- gen k¨onnen entweder mit einer mechanischen Eingabevorrichtung in Echtzeit22 oder in Form einfacher geometrischer Pfade direkt vom Computer erzeugt werden.

Eine Verfeinerung dieses Prinzips wurde sp¨ater unter anderen im CMusic System von F. Richard Moore vollzogen.23 Dabei werden zus¨atzlich die ersten Reflexionen der Klangquelle von den W¨anden des virtuellen Raumes mit einer Tapped-Delay-Line simuliert. Desweiteren besitzen die Klangquellen eine Abstrahlcharakteristik, die sich aus einer richtungsabh¨angigen Lautst¨arke-D¨ampfung ergibt. In CMusic k¨onnen die Dimensionen der vier W¨ande des vir- tuellen und des Abh¨orraumes bestimmt und die L¨ange der Hallfahne festgelegt werden. Der Unit-Generator24 space synthetisiert den Klang im Raum. Das separate Programm sndpath dient dem Erstellen von Trajektorien-Dateien, die mit dem quad UGen in CMusic eingelesen werden k¨onnen.25

1.3.1 APB-Tools Σ 1

Σ 1 (sprich Sigma-One) steht am Beginn der Betrachtung, weil es die flexibelste Raumklang- steuerung darstellt und hinsichtlich der Oberfl¨ache als auch fur¨ die Receiver Objekte in dem hier entwickelten Programm Vorbild war. Technische Details und Funktionsweise k¨onnen so-

20[Chowning 1971] 21Das englische Wort Panning l¨aßt sich leider schlecht ubersetzen.¨ Es beschreibt den Einstellvorgang des Panoramas, das heißt die Positionierung eines Klangs im (Stereo-)Bild. 22Eine Wiedergabe in Echtzeit war noch nicht m¨oglich; der Klang wurde nach Ende der Aufzeichnung vom Computer synthetisiert. 23[Moore 1983] 24Zu MUSIC-V vgl. [Ruschkowski 1998], S. 287–291. Eine Ubersicht¨ uber¨ die MUSIC-V Familie mit Ver- knupfungen¨ zum Konzept der Unit-Generatoren bietet http://www.wordiq.com/definition/MUSIC-N 25siehe dazu [Moore 1985], S.61f, 76–78 und [Loy 1985]. Die Pfade sind durch Stutzpunkte¨ definiert, zwischen denen mit Hilfe von Spline-Funktionen interpoliert wird.

10 1 Einfuhrung¨

Abbildung 1.1: Σ 1 Oberfl¨ache wohl in der Magisterarbeit von Thomas Schneider26, auf deren Basis das Programm entstand, als auch im Online-Manual27 nachgelesen werden.

Σ 1 ist eine Standalone-Applikation fur¨ Mac OS Classic, die uber¨ eine Mixer-Matrix bis zu 32 Eingangssignale auf bis zu 24 Ausgangskan¨ale verteilen kann. Die Matrix wird auf Digidesign ProTools TDM Hardware realisiert und verwendet dazu softwareseitig die Digidesign Audio Engine (DAE). Dies stellt zugleich Hauptmanko und Hauptvorteil des Programms dar. Zum einen ist teure Hardware n¨otig28, zum anderen arbeitet das Programm nicht mehr mit DAE Version 5.1 und h¨oher zusammen. Bis eine Neuauflage des Programms erscheint, muß also – da pro Bootpartition nur eine DAE existieren kann – zum Betrieb eine separate Mac OS 8 oder 9 Partition gebootet werden. Vorteil der DAE Benutzung ist die M¨oglichkeit, TDM Plug-Ins verwenden und direkt Spuren aus ProTools Sessions einspielen zu k¨onnen, wobei allerdings nur die Regionen-Positionen und die Volume-Automation erkannt werden.

Die Flexibilit¨at des Programms resultiert, abgesehen von der hohen Zahl der Ein- und Ausg¨ange, aus der M¨oglichkeit, Schallquellen auf beliebigen zweidimensionalen Pfaden be- wegen und die sogenannten virtuellen Lautsprecher frei positionieren und konfigurieren zu k¨onnen. Jedem virtuellen Lautsprecher kann eine benutzerdefinierte Richtcharakteristik“ ” gegeben werden, indem zwei sogenannte Coverage-Tables editiert werden. Die Empfindlich- keit der virtuellen Lautsprecher ergibt sich dabei aus der Summe einer distanzabh¨angigen und einer richtungsabh¨angigen D¨ampfung, so daß sich neben Kugel, Niere, Keule und Acht eine Vielzahl m¨oglicher Charakteristiken ergibt.

Die Oberfl¨ache von Σ 1 besteht aus der zweidimensionalen Raumansicht, Stage genannt, einem Transport-Fenster, einem Mixer- und Aux-Fenster und einer Region-Playlist sowie einer Reihe von Werkzeug- und Aktions-spezifischen Dialogen. In Abbildung 1.1 sind Beispiele fur¨

26[Schneider 1995], S. 39–82. Sein Programm wurde mit Hilfe von Max und externem MIDI-Mixer realisiert, entspricht jedoch vom gesamten Konzept und der Oberfl¨ache her dem sp¨ateren Σ 1. 27http://apbtools.com bzw. http://apbtools.com/PDFs/SIGMA1_MANUAL.pdf 28Pro Tools d24 + MIX Farm, Pro Tools MIX oder Pro Tools MIX Plus. Es gibt einen sogenannten Offline- Modus, darin ist jedoch keine Audioausgabe m¨oglich.

11 1 Einfuhrung¨ eine Stage-Anordnung (links) und Coverage-Tables (rechts) abgebildet. Die diskusf¨ormigen Objekte in der Stage-Ebene stellen die Mittelpunkte der virtuellen Lautsprecher dar, um sie herum ist die Charakteristik durch abgestufte Farben dargestellt. Die kleinen ballf¨ormigen Objekte stellen die beweglichen Schallquellen dar. Ihre Bewegungspfade sind als Linienzuge¨ sichtbar.

Neben der Aufzeichnung von Pfaden in Echtzeit durch Bewegen der Maus29 gibt es die M¨oglichkeit, im Offline-Modus Linien und Kreise zu zeichnen und Pfade zu kopieren, zu verschieben und zu l¨oschen.

Die Berechnung der Ausgangskl¨ange erfolgt als Intensit¨atspanning mit Hilfe der dynamischen M × N Matrix, die aus den M Eingangskan¨alen und N Ausgangskan¨alen besteht. Jede Zelle (m, n) enth¨alt den Quellklang (Zeile m) multipliziert mit der Lautst¨arkeinformation, die aus dem Abstand des Klanges von und seinem Winkel zu einem Lautsprecher (Spalte n) gewonnen wird. Die Summierung einer Spalte ergibt das Ausgangssignal fur¨ den jeweiligen Lautsprecher.

1.3.2 zplane.development z.matrix

Einen ¨ahnlichen Ansatz wie Σ 1 verfolgt z.matrix der Firma zplane.development. Wie der Name andeutet, arbeitet z.matrix ebenfalls mit einer Matrix von Eingangs- und Ausgangs- kan¨alen, die Gr¨oße ist auf 16 × 16 beschr¨ankt. Auch hier hat man sich auf eine Hardware- Plattform festgelegt, die DSP-Karten der Firma Creamware (Pulsar und Scope), was dem Programm ¨ahnlich wie Σ 1 fast zum Verh¨angnis wurde, als Creamware im Jahr 2003 Insol- venz anmelden mußte. Mittlerweile hat eine Nachfolgefirma die Creamware-Produkte uber-¨ nommen, aber die Zukunft der DSP-Systeme ist noch nicht endgultig¨ gesichert.

Das Kernelement der Oberfl¨ache ist die Surface, wieder ein zweidimensionales Momentanbild mit beweglichen Icons fur¨ Lautsprecher und Klangquellen. Daneben existieren Level-Meter fur¨ die Ein- und Ausg¨ange. Ein Element, das in Σ 1 nicht vorhanden ist, ist der Sweat Spot, der optimale Abh¨orpunkt, der bei Mehrkanalbeschallung automatisch entsteht, wenn Pan- ning nach dem Prinzip der Phantomschallquellen arbeitet. z.matrix gleicht unterschiedliche Entfernungen der Lautsprecher zum Sweat Spot durch ein gegens¨atzliches Delay aus, so daß – vorausgesetzt der H¨orer sitzt in einer identischen Kopie der Szenerie tats¨achlich im Sweat Spot – alle direkten Wellenfronten koh¨arent (gleichzeitig) beim H¨orer ankommen. Da aus der Forschung zum r¨aumlichen H¨oren bekannt ist, daß unterschiedliche Indizien bei der Ortung in komplexer Weise zusammenwirken, versucht man hier, die Ortung durch Laufzeitunterschie- de zu minimieren, so daß sie sich nur an den Intensit¨aten orientieren kann. Interessant ist ferner die M¨oglichkeit, mehrere Quellen in Master/Slave Anordnung zu gruppieren, so daß die Slave-Objekte dem Master entweder in kartesischen oder polaren Koordinaten folgen. Im Gegensatz zu Σ 1 besteht keine fixierte Pixelaufl¨osung der Surface, sie l¨aßt sich beliebig vergr¨oßern, und Quellen k¨onnen frei benannt werden.

In z.matrix lassen sich die Lautsprecher-Charakteristiken nicht explizit einstellen, allerdings gibt es einen Divergenz-Parameter fur¨ jede Quelle und die M¨oglichkeit einer Lautst¨arken-

29Das Handbuch erw¨ahnt außerdem, daß ein MIDI Joystick oder Dataglove verwendet werden k¨onnen, macht dazu allerdings keinerlei weitere Angaben, so daß davon auszugehen ist, daß diese Funktion noch in Planung ist (zumal das Handbuch als preliminary“ bezeichnet wird). ”

12 1 Einfuhrung¨

Abnahme in Abh¨angigkeit der Distanz einer Quelle vom Mittelpunkt der Surface. Zus¨atzlich ist pro Quelle ein mit variablen Delays realisierter Doppler-Effekt einschaltbar.

1.3.3 Wonder

Wonder von Marije Baalman30 ist ein Akronym fur¨ Wavefield Synthesis of New Dimensions of ” Electronic Music in Realtime“. Es stellt eine Oberfl¨ache fur¨ das Faltungsprogramm BruteFIR dar, das gem¨aß den Prinzipien der Wellenfeldsynthese die Eingangssignale verz¨ogert, d¨ampft und filtert, bevor sie auf die einzelnen Kan¨ale eines Lautsprecher-Arrays gegeben werden.

Um Kl¨ange im virtuellen Raum zu bewegen, mussen¨ die Wellenfelder dynamisch erzeugt werden, das heißt die FIR Filter kontinuierlich uberblendet¨ werden. Mit einem Raster wird festgelegt, von welchen Orten aus der Klang abstrahlen kann. Die Abstrahlung kann alternativ kugelf¨ormig (als Punktquelle) oder planar (als ebene Welle) erfolgen. Zus¨atzlich k¨onnen erste Reflexionen simuliert werden.

Die Bewegungen k¨onnen linear zwischen manuell eingegebenen Breakpoints stattfinden oder im Realtime Modus als Mausbewegung aufgezeichnet werden. Um zu gew¨ahrleisten, daß die Bewegungen synchron mit der Audiowiedergabe abgespielt werden, wird Wonder durch eine von Daniel Plewe programmierte Open Sound Control Schnittstelle ferngesteuert. Beispiels- weise kann ein Max/MSP Patch gleichzeitig die Audio Dateien abspielen und Bewegungs- Koordinaten an Wonder senden.

Sehr interessant ist die geplante Erweiterung um geometrisch ausgedehnte Klangquellen.

1.3.4 Surround Panning Objekte

Mittlerweile sind die Mixer in allen g¨angigen Harddisk-Recording-Programmen um Surround- F¨ahigkeiten erweitert worden. Mit den Automations-Engines dieser Programme vereint, stel- len sie einfache Raumklangsteuerungen dar. Der Aufbau in den verschiedenen Programmen ¨ahnelt sich dabei sehr stark. Die Automation geschieht meist spurorientiert, das heißt fur¨ jeden Kanalzug des Mischers existieren neben der Audiospur zus¨atzlich Spuren fur¨ jeden automatisierten Parameter, wie Lautst¨arke, Equalizer oder Panorama. Die Automation kann in der Regel live aufgezeichnet werden, also durch Bewegen von Software-Reglern mit der Maus – oder externen Controllern wie MIDI-Fadern –, w¨ahrend der Transport l¨auft. Fur¨ eine Offline-Editierung wird eine Breakpoint-Darstellung der Automationsdaten uber¨ oder unter den Audio-Regionen im Arrangier-Fenster eingeblendet. Mehrdimensionale Parameter wie ein Surround-Pan werden aus separaten eindimensionalen Werten zusammengesetzt, wie zum Beispiel Front↔Rear.

Die Panner orientieren sich alle an den Filmformaten, so daß man sich lediglich entscheiden kann, ob man 5.1“ oder 10.2“ usw. mischen m¨ochte. Die graphische Oberfl¨ache ist eine zwei- ” ” dimensionale Fl¨ache, auf der die Lautsprecher als Icons abgebildet sind, angeordnet entweder im Rechteck oder kreisf¨ormig. Entsprechend wird das Panorama in das Informations-Paar Azimut/Divergenz oder das Tripel Front-Position/Rear-Position/Front-Rear zerlegt. Emagic

30http://gigant.kgw.tu-berlin.de/~baalman/

13 1 Einfuhrung¨

Abbildung 1.2: Panning Objekte in Digital Performer

Logic Pro (Version 6) verwendet den polaren Ansatz, Digidesign ProTools TDM (Version 6) den kartesischen Ansatz mit dem Tripel-Vektor. Mark Of The Unicorn’s Digital Performer (Version 4) beinhaltet dagegen beide Modelle und daruber¨ hinaus ein weiteres Panorama- Plug-In, das eine Reverb-Einheit und weitere akustische Modellingfunktionen wie Doppler- effekt und Kopfabschattung enth¨alt.31 Abbildung 1.2 zeigt die Surround-Panner von Digital Performer.

Von Drittanbietern gibt es diverse Plug-Ins fur¨ diese Harddisk-Recording-Programme, die auf Surround-Formate abgestimmt sind, so zum Beispiel das 360◦ Surround Tools“ Paket ” der Firma Waves, das Mixer-, Reverb-, Spatializer- und Dynamik-Plug-Ins fur¨ die TDM Schnittstelle enth¨alt.32 Ein weiteres Beispiel ist das Reverb-Plug-In RealVerb 5.1 der Firma Kind Of Loud. Alle erh¨altlichen Surround-Plug-Ins hier aufzufuhren,¨ wurde¨ den Rahmen sprengen, zumal sich der Markt fur¨ Plug-Ins laufend ¨andert.

1.4 Hardware basierte Raumklangsteuerung

Bevor Computer schnell genug waren, mußten Raumklangsteuerungen mit Hilfe von spezieller Hardware realisiert werden. Da das Anwendungsfeld kaum kommerzielles Potential besitzt – wenn man von Surround-Joysticks fur¨ Digitalpulte absieht –, handelt es meist um einzelne Spezialanfertigungen fur¨ ein Studio oder ein Projekt.

Das von Hans Peter Haller und Peter Lawo gebaute Halaphon hat durch seine Veran- kerung im Freiburger Experimentalstudio der Heinrich-Strobel-Stiftung (Sudwestrundfunk)¨ und den Einsatz in Konzerten von beispielsweise Luigi Nono einige Bekanntheit erlangt. In der ursprunglichen¨ Fassung von 1971 wurden die Lautst¨arken von vier Lautsprechern mittels spannungsgesteuerter Verst¨arker (VCA) geregelt.33 Jeder VCA ist mit einem Oszillator ver-

31Inwieweit hier eine HRTF Filterung stattfindet, ist unklar. Leider stand mir das Programm nicht zur Verfugung,¨ und MOTU bietet keinerlei Demoversionen an. Auch spricht die Produktbeschreibung von einem vierten kartesischen Panner mit der Bezeichnung n-Panner; worin er sich von dem im Bild gezeigten TriPan unterscheidet, bleibt ebenfalls unklar. 32siehe http://waves.com/default.asp?url=content.asp?id=56 33Die Erl¨auterung folgt den Ausfuhrungen¨ in [Haller 1995], S. 77–90

14 1 Einfuhrung¨ bunden, der bestimmte Hullkurvenverl¨ ¨aufe realisieren kann. Durch zeitlich programmierten Ablauf der Hullkurven¨ und Umschalten der Zuordnung von Kan¨alen zu Lautsprechern lassen sich bewegte Phantomschallquellen realisieren. Das Ger¨at wurde im Laufe der Zeit an neue technische Entwicklungen angepaßt und die Kanalzahl erh¨oht. Haller griff die Ideen Chow- nings auf (vgl. Abschnitt 1.2), erweiterte den Signalweg im Halaphon um Harmonizer zur Simulation von Doppler-Effekten, einen Frequenz-Filter und ein Hallger¨at. Die Hullkurven¨ konnten schließlich graphisch an einem Bildschirm erstellt, abgespeichert und wieder gela- den werden. Fur¨ den Einsatz des Halaphons in Konzert-Situationen kann der Ablauf live gesteuert werden. So kann eine Klangbewegung zum Beispiel direkt durch die Dynamik des Mikrophonsignals eines Instruments verlangsamt oder beschleunigt werden.

Andere Hardware basierte Systeme gehen ¨ahnlich dem Halaphon von einer Art programmier- barem Mischpult aus. Das Problem vorhandener Mischpulte ist meist die beschr¨ankte Zahl von Ausgangskan¨alen und die eingeschr¨ankten Routingm¨oglichkeiten. Fur¨ den Raumklang- einsatz mussen¨ gerade die Verteilm¨oglichkeiten groß sein, w¨ahrend die Zahl der Eingangs- kan¨ale untergeordnet ist. Ein solches umgedrehtes“ Mischpult ist der Topoph24, den Sukan- ” dar Kartadinata fur¨ die Installations-Projekte des Duos gebaut hat.34 Ein Hauptrechner steuert mit einem Sequenzer sowohl die Klangerzeuger – zum Beispiel Sampler – als auch per MIDI einen zweiten Computer, der Raumbeschreibungen in einzelne Steueranweisungen umrechnet, die wiederum per MIDI an den Steuercomputer des Mischpults geleitet werden. Das Mischpult verteilt die Audiosignale mit Hilfe von VCAs, die vom Steuercomputer kontrolliert werden.

Ebenso verteilt die Raumklangsteuerung RKS.1 von Werner Schaller Ausgangssignale mit einem VCA-Mischer auf bis zu 24 Lautsprecher.35 Mit einem graphischen Editor k¨onnen Figuren“ erstellt und per MIDI an den Mischer ubertragen¨ werden. Die fur¨ eine Figur ver- ” wendeten Kan¨ale k¨onnen beliebig gew¨ahlt werden und mussen¨ nicht benachbarte Lautspre- cher repr¨asentieren. Das Mapping von Kan¨alen auf Lautsprecher kann sp¨ater leicht angepaßt werden.

MIDI war eine der wichtigsten Schnittstellen, um Computer mit Hardware Peripherie zu ver- binden. Die Vorarbeit von Σ 1 basierte noch auf einem Max-Patch, das einen Mischer uber¨ MIDI ansteuerte. Einige Jahre fruher,¨ 1988, wurde an der TU Berlin ein MIDI Mischer gebaut, der bis zu 15 Eingangssignale auf 4 Ausgangskan¨ale verteilen konnte. Um einen hohen Rauschabstand zu gew¨ahrleisten, wurden dabei multiplizierende D/A Wandler statt VCAs eingesetzt. Das Programm arbeitete mit einem Nulldurchgangs-Detektor, der Knack- ger¨ausche minimierte, die durch die grobe Rasterung der Lautst¨arke-Stufen entstanden. Der MIDI Mischer von Torsten Radtke wurde dann 1990 von Thomas Seelig um eine graphi- sche Benutzeroberfl¨ache erweitert, die auf einem Atari Computer lief. Dadurch konnten die Klangquellen geometrisch plaziert und bewegt werden.36

34http://www.topophonien.de/2.5-w-d-topoph24.html 35vgl. [Hein 1999], S. 106 36[Radtke 1988] resp. [Seelig 1990]

15 1 Einfuhrung¨

1.5 Raumklang-Synthese Plug-Ins

In diesem Abschnitt sollen einige Plug-Ins und Unit-Generatoren vorgestellt werden, die in- teressante Synthese-Ans¨atze fur¨ Raumklang darstellen, von sich aus jedoch keine oder kaum graphische Steuerm¨oglichkeiten bieten. Im Zusammenhang mit der Entwicklung einer Steuer- oberfl¨ache stellen sie potentielle Synthese- Maschinen“ dar (vgl. Abschnitte 2.2.1 und 2.2.2). ”

1.5.1 VBAP – Vector Based Amplitude Panning

Vector Based Amplitude Panning ist, wie der Begriff vermuten l¨aßt, keine feststehende Soft- ware, sondern ein bestimmtes Modell von r¨aumlicher Klangverteilung. Dieses wurde von dem Finnl¨ander Ville Pulkki entwickelt und steht in Form eines freien Plug-Ins fur¨ CSound, Max/ MSP und Pure Data zur Verfugung.¨ 37

VBAP verallgemeinert ein auf der sogenannten Tangenten-Regel beruhendes Modell des Stereo-Pannings auf eine beliebige zweidimensionale (2-D VBAP) oder dreidimensionale (3-D VBAP) Anordnung von Lautsprechern. Dabei erfolgt ein Amplitudenpanning uber¨ die jeweils zwei respektive drei Lautsprecher, die der Klangquelle am dichtesten sind. VBAP liefert nur die Gain-Werte, die Programm-Umgebung, in der VBAP eingesetzt wird, muß selbst dafur¨ sorgen, daß unterschiedliche Abst¨ande der Lautsprecher zum H¨orer durch entspre- chende Delays nivelliert werden, damit als auditorischer Cue nur die Intensit¨atsunterschiede wirken.38 Die durch die Tupel oder Tripel aufgespannten Teilebenen bzw. -r¨aume werden so berechnet, daß sie sich nicht uberschneiden¨ und im Falle einer Bewegung der Klangquelle automatisch ein weicher Ubergang¨ von einem Teilraum in den anderen stattfindet.39

Da die Forschung ergeben hat, daß bei diesem Verfahren der Eindruck der Ausdehnung der Quelle (spread) unterschiedlich ist, je nachdem ob ein Klang von einem oder mehreren Laut- sprechern (Phantomschallquelle) abgestrahlt wird, wurde ein Divergenzverfahren integriert. Das Grundkonzept des VBAP, daß eine Quelle maximal von zwei respektive drei Lautspre- chern repr¨asentiert wird, wird dabei durch einen Trick aufrecht erhalten: Aus einer Quelle werden mehrere beieinander liegende Quellen gemacht, die intern summiert werden. Der Ab- stand dieser Quellen voneinander h¨angt von der H¨ohe der gew¨ahlten Divergenz ab.40

VBAP als Plug-In allein ist noch keine vollwertige Raumklangsteuerung, allerdings l¨aßt sich eine solche mit wenigen Klicks erstellen, wie der Max/MSP-Patch in Abbildung 1.3 zeigt. Hier wurde der Azimut-Parameter automatisiert, indem mit der Maus der Knopf im Panel links oben bewegt wird. Alternativ wird durch Klicken auf start rotation“ eine gleichm¨aßige ” Kreisbewegung ausgefuhrt.¨ 41 Als Klang wird ein Mono-Soundfile verwendet.

Grunds¨atzlich verarbeitet ein VBAP Objekt die Steuerdaten fur¨ einen Quellklang; sollen mehrere Kl¨ange unabh¨angig bewegt werden, mussen¨ weitere VBAP Instanzen erzeugt werden.

37http://www.acoustics.hut.fi/~ville/software/ . Dort ist auch noch ein ¨alteres Standalone-Demo fur¨ SGI Computer zu finden. 38vgl. [Pulkki 2001], S. 16f 39Im Falle der dreidimensionalen Anordnung wird der Klang im Ubergangspunkt¨ nur noch von den zwei Lautsprechern abgestrahlt, die beiden Teilr¨aumen gemeinsam sind. 40ebd., S. 18 41vorausgesetzt naturlich,¨ die Lautsprecher sind, wie im define_loudspeakers Objekt zu sehen, kreisf¨ormig angeordnet.

16 1 Einfuhrung¨

Abbildung 1.3: VBAP Anwendung in Max/MSP

Das Lautsprecher-Setup im abgebildeten Patch ist kreisf¨ormig in der horizontalen Ebene (2D), daher wird die Bewegung in der Vertikalen (Elevation42) nicht benutzt. Die Divergenz l¨aßt sich mit dem Schieberegler einstellen.

1.5.2 IRCAM Spat˜

Das Spat˜ Plug-In, von Jean-Marc Jot und Olivier Warusfel am IRCAM entwickelt,43 hat einen integrierteren Ansatz als VBAP. Das kommerziell vertriebene Paket besteht aus einer Reihe zusammengeh¨origer Objekte fur¨ Max/MSP oder IRCAM’s jMax. Insgesamt vier Stufen durchl¨auft ein Klang, bis er an den Ausgangskan¨alen oder Lautsprechern angelangt:

• Source~ versieht ein Quellsignal mit einer optionalen Entzerrung und variablem Delay, womit ein Doppler Effekt erzeugt werden kann • Room~ ist eine synthetische Multikanal-Reverb-Einheit • Pan~ verteilt die Quelle und das Hallsignal im Raum • Out~ versieht die zu den Ausgangskan¨alen geleiteten Kl¨ange mit einer optionalen Ent- zerrung und einstellbarem Delay und kompensiert so Nichtlinearit¨aten im Frequenzgang der Lautsprecher und deren Abstand vom H¨orer

Prinzipiell lassen sich die Objekte einzeln benutzen, beispielsweise kann ein Klang direkt in den Panner geschickt und dessen Output direkt an Lautsprecher gegeben werden, wenn man auf psychoakustische Modellierung und virtuellen Hall verzichten m¨ochte. Etwas ungew¨ohn- lich mag die Reihenfolge der Module wirken, wonach der Panner hinter dem Hallobjekt sitzt. Der Grund dafur¨ ist, daß in Pan~ die Lautsprecher-Konfiguration bestimmt wird. Das Room~ Objekt produziert einen formatunabh¨angigen Hall, der dann in Pan~ je nach Aufstellung der Lautsprecher mit einer Ambisonics-Matrizierung verteilt wird.

42im VBAP External das dritte Inlet 43siehe [Jot/Warusfel 1995]

17 1 Einfuhrung¨

Abbildung 1.4: Perzeptive Parameter in Spat˜

Das Pan~-Objekt von Spat˜ erlaubt bis zu acht Lautsprecher in einer horizontalen Ebene mit einstellbaren Winkeln. Fur¨ Kopfh¨orer-Wiedergabe kann auch eine Binaural-Faltung benutzt werden. Die Positionierung der Quelle wird wie beim VBAP mit den Parametern Azimut und Elevation eingestellt, allerdings l¨aßt sich ein Quellsignal im Source~ Objekt verz¨ogern und mit dem Raumprozessor so bearbeiten, daß N¨ahe- oder Ferne-Effekte entstehen.

Fur¨ jede der vier genannten Signal-Stufen gibt es ein Low-Level Kontroll-Objekt, mit dem die wichtigsten Parameter eingestellt werden k¨onnen, beispielsweise Room_ fur¨ die Early- und Late-Reflections-Charakteristik des Room~ Objekts. Fur¨ Spat~ selbst wurde der spe- zielle Spat_OPer Patch entwickelt, der in Abbildung 1.4 zu sehen ist. Spat_OPer enth¨alt perzeptions-basierte“ Parameter, die dann intern auf die DSP Parameter umgerechnet wer- ” den. Statt direkt die Raumgr¨oße in physikalischen Einheiten bestimmen zu k¨onnen, hat man sich dafur¨ entschieden, qualitative Parameter zu benutzen.

Interessant ist vor allem der Subpatcher, der sich hinter der Bezeichnung radiation verbirgt. Er enth¨alt eigentlich nur zwei parametrische Dreiband-Equalizer. Mit einer geeigneten dyna- mischen Steuerung jedoch kann die Klangfarben-Anderung¨ simuliert werden, die entsteht, wenn eine Klangquelle mit richtungsabh¨angiger Abstrahlung bewegt wird.

Eine einfache Steueroberfl¨ache wird bereits in Form des Circ Patchers von Gerhard Eckel mitgeliefert. Bis zu drei Klangquellen k¨onnen auf einem quadratischen Feld bewegt werden. Neben Azimut und Distanz wird auch die Abstrahlcharakteristik in Form eines Kreissegments dargestellt. Die Kontrolldaten von Circ k¨onnen mit den Spat_Circ und Pan_Circ Patches so umgerechnet werden, daß die Klangquelle entsprechend der Mausbewegung folgt und die Radiation-Filterkurven ver¨andert werden.

1.5.3 Spatialisierung mit CSound

Fur¨ CSound existieren verschiedene Verr¨aumlichungs-Opcodes. Neben dem beschriebenen VBAP gibt es die einfachen quadrophonen Panner locsig (polar), pan und space (karte- sisch), einen Ambisonics-Panner namens spat3d und einen Binaural-Panner namens hrtfer.

Der Ambisonics-Panner ben¨otigt als Parameter die Position der Klangquelle (x, y, z). Eine Verz¨ogerung ist ebenfalls vorgesehen, diese l¨aßt sich allerdings nicht dynamisch ver¨andern – in diesem Fall muß ein anderer CSound Opcode wie vdelayx benutzt werden. Fur¨ die Generierung von Nachhall kann eine spezielle Tabelle angegeben werden, die die Distanzen und Absorptionswerte fur¨ die sechs W¨ande eines virtuellen kubischen Raumes beschreibt.

18 1 Einfuhrung¨ spat3d erzeugt ausgangsseitig die vier B-Format Signale W, X, Y, Z. Diese kann man sich als virtuelle Aufnahmen eines Soundfield-Mikrophons vorstellen, das aus drei orthogonalen Achter-Charakteristiken und einer Kugel besteht. Mit geeigneten Matrizierungsformeln lassen sich daraus Signale fur¨ beliebig angeordnete Lautsprecher gewinnen.44 spat3d beinhaltet außerdem eine Stereo-Mixdown Option.

Der Binaural-Panner hrtfer ben¨otigt eine Datei mit Impulsantworten fur¨ die Kopfubertra-¨ gungsfunktion. Das Format ist leider nicht dokumentiert, jedoch gibt es eine entsprechende Datei auf dem CSound FTP Server. Die Synthese-Parameter sind Azimut und Elevation, eine entfernungsabh¨angige D¨ampfung oder Verhallung muß separat programmiert werden.

1.6 Notwendigkeit einer neuen Raumklangsteuerung

Das Feld an Raumklang-Software, die flexibel zu gebrauchen ist, ohne daß der Komponist selbst umfangreiche Programmierarbeiten erledigen muß, ist also recht ubersichtlich.¨ Auf die Einfuhrung¨ der DVD und die zunehmende Verbreitung kleiner Surroundsysteme in Wohn- zimmerkinos haben zwar alle Hersteller g¨angiger kommerzieller Software mit der Erweite- rung ihrer Produkte um Surround-Ausgabe-M¨oglichkeiten reagiert. Viel mehr als eine leichte Extrapolation der bisherigen Stereo-Technologien hat dabei aber kaum stattgefunden.

Eine Raumklang-Steuerung, die einfach zu bedienen ist, dabei jedoch gr¨oßtm¨ogliche Flexibi- lit¨at bietet und den Benutzer nicht auf ein enges Anwendungsfeld beschr¨ankt, die außerdem einen kompositorischen Umgang mit Raumgestaltung nicht nur erlaubt sondern auch f¨ordert, und mit der an bereits bestehende Klangsynthese-Software angeknupft¨ werden kann, ist eine Lucke,¨ die mit diesem Magisterarbeitsprojekt geschlossen werden soll.

44Zu Ambisonics und dem B-Format siehe [Malham 1998].

19 2 Entwicklung des Programms Meloncillo

2.1 Tendenzen in der Entwicklung von Musiksoftware

In der gegenw¨artigen Entwicklung von Software im Bereich experimenteller Musik sind folgen- de Tendenzen zu entdecken: Zum einen das rasche Anwachsen der Open-Source Community, das heißt der Entwicklung von Programmen, deren Quelltexte ¨offentlich zug¨anglich sind und die oft in gemeinsamer Arbeit mehrerer Programmierern entstehen. Zu nennen sind CSound – an Universit¨aten entstanden, war es bereits vor der Entwicklung im Open-Source Ver- fahren kostenlos zug¨anglich –, SuperCollider, das im Zuge des Wechsels des Autors James McCartney zu Apple Inc. in ein Open-Source Projekt umgewandelt wurde, zahlreiche kleinere Programme wie RTcmix, und auch ein Teil der IRCAM Software – vielleicht am beachtlich- sten, wenn man die ansonsten eher verschlossene Vertriebspolitik bedenkt –, darunter die graphische Klangsynthese-Sprache jMax und eine Umgebung fur¨ algorithmische Komposi- tion, OpenMusic. Fur¨ das Betriebssystem Linux, das selbst Open-Source ist, entwickelt sich momentan eine eigene Audio Community. Mit den Soundeditoren snd und Audacity, dem MIDI Sequenzer Rosegarden und dem Harddisk-Recording-Tool Ardour, den plattformuber-¨ greifenden Klangsynthese-Programmen jMax, SuperCollider, CSound und Pure Data sowie der Unterstutzung¨ professioneller Soundkarten u.a. von RME steht eine gunstige¨ Arbeits- umgebung bereit.

Eine logische Folge daraus ist, daß Programmierer viel mehr M¨oglichkeiten haben, Schnitt- stellen zwischen diesen Programmen zu entwerfen. Auch kommerzielle Musiksoftwarefirmen sind sich bewußt, daß sie den Mehrwert ihrer gewerblich angebotenen Programme erheblich steigern k¨onnen, wenn sie eine Entwicklergemeinde finden, die fur¨ eine Schnittstelle program- miert, die ihre Software unterstutzt.¨ Als wichtiger Anstoß darf die Einfuhrung¨ des VST Plug- In Standards der Firma Steinberg gelten, der sich schnell auf mehreren Rechnerplattformen und uber¨ die Basisapplikation Cubase hinaus durchgesetzt hat.

Der Wunsch, mehrere Audioprogramme miteinander zu verbinden, manifestiert sich seitdem in zahlreichen Schnittstellen. Im kommerziellen Sektor ist ReWire zu nennen, einer gemein- samen Entwicklung der Firmen Propellerhead und Steinberg. Im Open-Source Bereich ist ein ¨ahnlicher Versuch mit dem virtuellen Patchsystem Jack zu beobachten, einer zun¨achst auf Linux entwickelten Audiotreiber-Schnittstelle, die mittlerweile auch auf den anderen Rechner- plattformen verfugbar¨ ist und die u.a. von SuperCollider, jMax, PD, Ardour, Rosegarden und snd unterstutzt¨ wird. Die durchschlagendste Entwicklung im Open-Source Bereich dagegen besch¨aftigt sich nicht direkt mit dem Transport von Audiostr¨omen, sondern der gegenseitigen Kontrolle und Highlevel-Steuerung von Programmen. Es handelt sich um ein Kommunika- tionsprotokoll mit dem Namen Open Sound Control (OSC), das von Matt Wright und Adrian Freed am Zentrum fur¨ Neue Musik und Audiotechnologie CNMAT (Universit¨at Berkeley) entwickelt wurde.

20 2 Entwicklung des Programms Meloncillo

In gewisser Weise als inoffizieller Nachfolger von MIDI1 gedacht, werden in OSC mit einem Textkommando beginnende Nachrichten versandt. Definiert ist nur die Syntax, welche kon- kreten Befehle eine Applikation versteht, ist dabei nicht festgelegt. OSC eignet sich damit besonders fur¨ offene Systeme, die der Benutzer zum Teil oder vollst¨andig selbst programmie- ren kann, wie SuperCollider, dessen Synthese-Engine in der Version 3 vollst¨andig uber¨ OSC gesteuert wird und das damit als Paradebeispiel fur¨ OSC gelten kann, Max/MSP oder Pure Data (PD). Damit wird es zum ersten Mal m¨oglich, daß zum Beispiel ein Max/MSP Patch Teile oder die gesamte Klangsynthese an SuperCollider delegiert und sich auf die graphische Oberfl¨ache als wesentliche St¨arke von Max konzentrieren kann.2 Und dies, ohne daß der An- wender einen C-Compiler bedienen und eigene sogenannte Externals oder Unit-Generatoren programmieren muß.

Ein wichtiger Aspekt in der Entwicklung neuer Musiksoftware wird damit die Anstrengung sein, St¨arken bereits bestehender Systeme auf neue Art und Weise miteinander zu verknupfen.¨

2.2 Designspezifikation fur¨ eine neue Raumklangsteuerung

Die Kernelemente der neuen Software sollen sein:

• Trennung von Oberfl¨ache und Signalverarbeitung. Dabei weitgehende Beschr¨ankung auf eine graphische Benutzeroberfl¨ache und Ruckgriff¨ auf externe klanggenerierende Programme • Abstraktion der Oberfl¨ache von dem zugrundeliegenden Synthesemodell • Unterstutzung¨ sowohl von Anwendern ohne Programmiererfahrung, als auch von sol- chen, die mittels Musikprogrammiersprachen weitergehenden Einfluß auf die Bewegungs- Gestaltung und Klangsynthese nehmen m¨ochten • Betriebssystemunabh¨angige Implementierung

Desweiteren wurden folgende Entscheidungen zur Programmarchitektur gef¨allt:

• Komplementarit¨at aus zwei grundlegenden Objekttypen • Komplementarit¨at aus Echtzeit und Offline Anwendung mit Schwerpunkt auf Nicht- Echtzeit-Betrieb • Diskretisierung von Datenstr¨omen

Die genannten Aspekte werden im folgenden erl¨autert:

2.2.1 Trennung von Ober߬ache und Signalverarbeitung

Da fur¨ die Entwicklung einer graphischen Benutzeroberfl¨ache und eines Signalverarbeitungs- Kernels grunds¨atzlich andere Programmiertechniken verwendet werden – weil auch verschie-

1Ein Uberblick¨ uber¨ die MIDI Schnittstelle ist zum Beispiel in [Ruschkowski 1998], S. 371–412 zu finden. 2Tats¨achlich war Pyrite“, ein Vorl¨aufer der SuperCollider Language Application, einmal ein Max Objekt, ” vgl. [McCartney 1996]

21 2 Entwicklung des Programms Meloncillo dene Designziele existieren3 –, spricht vieles fur¨ eine Trennung dieser beiden Programmteile. Sind diese Teile hinreichend modularisiert, ergibt sich vor allem der Vorteil, daß gr¨oßere Ande-¨ rungen in einem Teil vorgenommen werden k¨onnen, ohne in den jeweils anderen Part eingrei- fen zu mussen.¨ Dieselbe Oberfl¨ache kann m¨oglicherweise mit unterschiedlichen austauschbaren Signalverarbeitungs-Modulen arbeiten und umgekehrt. Außerdem k¨onnen Alterungserschei- nungen abgefedert werden:

This architecture allows to define user-interfaces that provide access to exactly ” the functionality that is needed by the user, while the back-end can be scaled to a compromise between the current needs and the hardware possiblities.“4

Die gegenw¨artigen Klangsynthese Programme sind vom Gesichtspunkt der Signalverarbei- tung sehr ausgereift und effizient. Dies kann dagegen nicht von ihren Benutzeroberfl¨achen gesagt werden, wenn man SuperCollider oder CSound betrachtet. Max/MSP hat eine sehr ausgereifte Benutzeroberfl¨ache, die Programmierung gr¨oßer angelegter Patches kann jedoch leicht unubersichtlich¨ werden, und das Programm ist sehr stark auf den Echtzeit Betrieb aus- gerichtet. Von normalen Desktop Anwendungen erwartete Features wie Drag-and-Drop oder Clipboard Austausch sind h¨ochstens rudiment¨ar vorhanden. Eine klare Trennung von einem Patch als Instrument und den eingestellten Parametern als Dokument oder Stuck¨ ist nicht vorhanden.

Die zu entwickelnde Software soll sich aus dieser Uberlegung¨ heraus weitgehend auf die Ober- fl¨ache konzentrieren und im Falle der Signalverarbeitung die St¨arken der vorhandenen Pro- gramme nutzen.

2.2.2 Abstraktion vom Synthesemodell

In dem Moment, wo die Oberfl¨ache prinzipiell von der Signalverarbeitung getrennt ist, l¨aßt sich noch ein weiterer Abstraktionsschritt vollfuhren:¨ Zwischen die Datenstrukturen, die hin- ter den Oberfl¨achen-Elementen verborgen sind, und der Klangsynthese wird eine Vermitt- lungsinstanz eingesetzt, die dafur¨ sorgt, daß sich trotz einheitlicher Oberfl¨ache unterschied- liche Arten oder Modelle von Signalverarbeitungen realisieren lassen. Diese Instanz soll eine kompakte und leicht zu programmierende Script-Sprache sein.

Das bedeutet zum Beispiel, daß Meloncillo weder zu wissen braucht, in welchem exakten Format und in welcher Reihenfolge die Syntheseengine die Quelldaten ben¨otigt, noch, ob bei der Synthese eine reine Amplituden-Matrizierung oder eine Kombination mit Filtern oder Delays verwendet wird. Dies ist die Voraussetzung dafur,¨ daß verschiedene Programme als Syntheseengines benutzt werden k¨onnen, ohne auf deren Eigenheiten und St¨arken verzichten zu mussen.¨

3W¨ahrend es in der Signalverarbeitung vor allem um Recheneffizienz und -genauigkeit geht, muß eine Ober- fl¨ache in erster Linie Anforderungen an Ergonomie und Konsistenz mit betriebssystemspezifischen Style- Guides erfullen.¨ Die Programmierung des Oberfl¨ache legt grunds¨atzlich viel st¨arkeres Gewicht auf die Wartbarkeit und Flexibilit¨at des Quellcodes, auch wenn dies nicht immer mit bestm¨oglicher Performanz vereinbar ist. Da das Event-Handling nicht auf exaktes Timing angewiesen ist, k¨onnen hier andere Ent- wurfsschemata verwendet werden. 4[Zm¨olnig et al. 2003]. Der Autor weist auch auf den Vorteil hin, Oberfl¨ache und Audio-Engine auf verschie- denen Rechnern laufen lassen zu k¨onnen.

22 2 Entwicklung des Programms Meloncillo

Diese Abstraktion ist zugleich der Garant dafur,¨ daß ein Komponist mit Meloncillo neue Ideen verwirklichen kann, ohne daß jede Idee in der Programmstruktur a priori vorgedacht worden sein muß. Das weiche Element zwischen Oberfl¨ache und DSP Instanz federt die Erfordernis ab, bei Entwurfen¨ zu neuen Klangsynthese-Verfahren wieder in den Quelltext von Meloncillo eingreifen zu mussen.¨

2.2.3 Anwender mit und ohne Programmiererfahrung

In der elektroakustischen Musik sind zwei unterschiedliche Kunstler-Charaktere¨ anzutreffen: Die einen finden Gefallen daran, selbst die instrumentalen Grundlagen ihrer Stucke¨ zu ent- wickeln – die ja, anders als in der Instrumentalmusik, nicht automatisch gegeben sind – oder musikalische Strukturen mit Hilfe von Algorithmen zu erzeugen. Sie besitzen Programmier- erfahrung und begegnen rein graphisch orientierten Programmen mit Skepsis. Die andere Gruppe entwickelt ihre kompositorischen Vorstellungen eher unabh¨angig von den techni- schen Rahmenbedingungen der Software und sucht nach Mitteln, diese Vorstellungen mit m¨oglichst intuitiv zu bedienenden Programmen umzusetzen. Der Gedanke, ¨asthetische Ideen ingenieursm¨aßig auf technische Abl¨aufe herunterzubrechen, schreckt sie ab.

Die graphische Oberfl¨ache soll so gestaltet werden, daß sie von Benutzern bedient werden kann, deren Computer-Kenntnisse nicht viel weiter reichen als n¨otig ist, um mit ProTools zu arbeiten. Der tiefere Eingriff in das Programm und die Verknupfung¨ mit anderen Program- men wie CSound oder SuperCollider soll durch Definition von Plug-In Schnittstellen ge¨offnet werden.

2.2.4 Unabh¨angigkeit vom Betriebssystem

Applikationen, die uber¨ den reinen Charakter eines Utility“ hinausgehen, haben in der Regel ” eine l¨angere Lebensdauer als das Betriebssystem, fur¨ das sie ursprunglich¨ vorgesehen waren. Dies gilt selbstredend fur¨ Programme mit langer Tradition wie CSound, Max, CDP oder die IRCAM Software. Aber auch jungere¨ Programme waren beispielsweise von dem Neuanfang Apple’s mit Mac OS X betroffen. Eine zu enge Festlegung auf ein bestimmtes Betriebssystem kann das fruhzeitige¨ Ende eines Programmes bedeuten, wenn Zeit oder Geld fehlen, jede Migration mitzumachen, oder wenn eine Plattform mehr oder weniger komplett verschwindet wie im Falle von Atari, NeXT oder SGI. Benutzer sind oft gezwungen, sich fur¨ eine bestimmte Plattform zu entscheiden, weil es ihr Geldbeutel diktiert, weil eine bestimmte fur¨ sie wichtige Software nur auf dieser Plattform existiert, oder weil sie in einem Studio arbeiten, das auf diese Plattform ausgerichtet ist.

Die momentan wichtigsten Betriebssysteme im Musikkontext sind Mac OS X, Linux und Windows XP. Mit den meisten Sprachen l¨aßt sich plattformunabh¨angig programmieren. Schwierigkeiten entstehen dann, wenn uber¨ eine reine Consolen-Ausgabe hinaus zum Beispiel eine graphische Oberfl¨ache oder Interaktion mit der Computer-Peripherie (Audio-Hardware) gewunscht¨ sind. Folgende M¨oglichkeiten stehen zur Verfugung:¨

23 2 Entwicklung des Programms Meloncillo

• eine Sprache mit plattformunabh¨angigen Bibliotheken wie Java. • kommerzielle Produkte wie Xanalysis LispWorks5, die auf den drei genannten Platt- formen einschließlich der Bibliotheken kompilieren. Der Preis von LispWorks betr¨agt 1000 $, eine Weiterentwicklung als Open-Source Projekt scheidet damit auch aus. • eine plattformunabh¨angige Sprache wie ANSI C oder C++, die mit freien Bibliotheken gelinkt wird. Verbreitet ist Trolltech’s QT Bibliothek6, die allerdings entweder unter der GPL (siehe Abschnitt 3.1) oder kostenpflichtig lizensiert ist. Eine Alternative ist die Verwendung von Tk/Tcl; die Flexibilit¨at und Asthetik¨ der erstellten GUIs ist eher bescheiden.7

2.2.5 Zwei grundlegende Objekttypen

Bei der Betrachtung der vorhandenen Raumklang-Software f¨allt auf, daß die graphische Ober- fl¨ache meist zwei Typen von Objekten kennt: Klangquellen und Lautsprecher. Diese korre- spondieren im Signalfluß mit den Eing¨angen und Ausg¨angen. Die Beschr¨ankung auf zwei interagierende Objekte tr¨agt dazu bei, daß die Struktur des Programmes sehr klar bleibt. Die feste Rollenzuteilung steht einer flexiblen Anwendung jedoch im Wege. Diese zwei Objekte sollen also rollenunabh¨angig sein und dennoch komplement¨are, sich erg¨anzende Eigenschaften besitzen:

• Ein Receiver ist ein statisches Objekt, das eine fl¨achenf¨ormige Ausdehnung besitzt und seine Charakteristik – genannt Sensitivit¨at – aus einer Funktion des Ortes auf dieser Fl¨ache gewinnt. • Ein Transmitter ist ein punktf¨ormiges Objekt, das seine Charakteristik aus einer Bewegung als Funktion der Zeit gewinnt.

Die Bezeichnungen wurden aus Ermangelung besserer Begriffe gew¨ahlt und sollen nicht daruber¨ hinweg t¨auschen, daß ein Receiver keinesfalls die Rolle eines passiven und ein Trans- mitter keinesfalls die Rolle eines aktiven Elements ubernehmen¨ muß. Vielmehr stehen beide in einer Beziehung zueinander, die je nach gew¨ahltem Synthesemodell nutzbar gemacht wer- den kann. Obgleich zum Beispiel die Receiver rein optisch den virtuellen Lautsprechern von Σ 1 ¨ahneln, k¨onnen sie auch Klangfelder repr¨asentieren, die durch Transmitter als bewegte ” Mikrophone“ abgetastet werden.

2.2.6 Echtzeit und Offline Modus

Im Prozeß des Komponierens gibt es unterschiedliche, sich abwechselnde Formen von Zeit (vgl. Abschnitt 1.1.2). Ein Stuck¨ kann uber¨ die Dauer von Wochen bis Jahren entstehen, die einzelnen Sektionen mussen¨ nicht chronologisch gewachsen sein. Der Vorteil von schnellen Computern – der auch ein Nachteil sein kann – ist die M¨oglichkeit, unmittelbar die Re- sultate eines halbfertigen Stuckes¨ anh¨oren zu k¨onnen. Es ist also anzustreben, daß an dem

5http://www.lispworks.com/ 6http://www.trolltech.com/products/qt/ 7Der CSound Frontend Cecilia ist ein Beispiel fur¨ eine gelungene Nutzung von Tk/Tcl. Trevor Wisharts Soundloom Frontend fur¨ CDP ist ebenfalls in Tk/Tcl geschrieben. Ebenso die Oberfl¨ache von Pure Data. Ein halbwegs angenehmes Arbeitsgefuhl¨ will sich jedoch – zumindest unter Mac OS X – nicht einstellen.

24 2 Entwicklung des Programms Meloncillo

Stuck¨ gearbeitet werden kann, indem die performative Zeit des Stucks¨ angehalten wird und beispielsweise Teile verkurzt¨ oder umgruppiert werden, und zugleich in Echtzeit kontrolliert werden kann, ob das Ergebnis den Wunschen¨ entspricht. Da vielfach auch eine gestische Beschreibung von r¨aumlichen Bewegungen gewunscht¨ ist, sollen solche Gesten in Echtzeit aufgezeichnet werden k¨onnen. Ein Offline Modus ist auch vom signalverarbeitungstechni- schen Gesichtspunkt wunschenswert,¨ weil dadurch Modelle realisiert werden k¨onnen, deren Berechnung in Echtzeit aus Grunden¨ der CPU-Kapazit¨at derzeit ausscheidet.

2.2.7 Diskrete Datenstr¨ome

Die Funktionswerte der in Abschnitt 2.2.5 genannten Basisobjekte k¨onnen analytischer und diskretisierter Natur sein. Eine analytische Beschreibung eines Receivers w¨are etwa: Die Sen- sitivit¨at ist umgekehrt proportional zur Entfernung (f(d) ∼ 1/d). Eine diskretisierte Beschrei- bung w¨are: gegeben sei eine Tabelle mit 1000 Punkten, die durch Abtastung der Funktion f(dn) = 1/dn; dn = n · extent/1000 entstanden ist. Die Sensitivit¨at an einem Punkt mit dem Abstand d vom Receiver entspricht dem Tabellenwert mit dem Index round(d · 1000/extent).

Entsprechend kann die Bewegung eines Transmitters analytisch durch eine beliebige Kette von Funktions-Abschnitten gedacht werden: Der Transmitter bewege sich zwischen Sekun- de 10 und Sekunde 20 mit konstanter Geschwindigkeit von Punkt (0.25, 0.25) nach Punkt (0.667, 0.8). Die diskrete Beschreibung wiederum w¨are eine Abtastung dieser analytischen Funktion an gleichm¨aßig voneinander entfernten Stutzpunkten.¨

Der Vorteil einer analytischen Beschreibung ist die Exaktheit, denn durch die Abtastung entstehen zwangsl¨aufig Aliasing-Fehler. Eine analytische Beschreibung ist auch viel kom- pakter, denn im vorangegangenen Beispiel wird die Linie durch zwei Punkte beschrieben, w¨ahrend eine Abtastung bei 100 Hz fur¨ die Bewegung uber¨ zehn Sekunden bereits 1000 Punkte ben¨otigt. Soll zu einem sp¨ateren Zeitpunkt die Linie verkurzt¨ oder verl¨angert oder verlagert werden, so entstehen keine Artefakte und die gesamte Komposition bleibt sehr sauber“. ” Die Abtastung hat jedoch entscheidende Vorteile: Der Datenstrom kann an beliebigen Stellen zerschnitten und umgeordnet werden, ohne daß dadurch kompliziertere Berechnungen n¨otig sind. Bei einer Beschreibung mit Hilfe von Breakpoints mussen¨ in diesem Fall neue Punkte ein- gefugt¨ werden. Soll jetzt zus¨atzlich eine Sektion rotiert werden, beginnt die Umrechnung der Breakpoint-Funktionen kompliziert zu werden, es sind trigonometrische Funktions-Abschnitte n¨otig. Soll weiterhin eine Unregelm¨aßigkeit erzeugt werden, kann dem diskreten Datenstrom einfach Rauschen hinzugefugt¨ werden; in der Breakpoint-Darstellung ist dies nicht m¨oglich, es mußten¨ also zahlreiche zuf¨allige Punkte erzeugt werden, womit man de facto bei einer ge- sampelten Funktion endet und zugleich einen immensen Verwaltungsaufwand hat. Der Vorteil der diskreten Datenstr¨ome ist ferner, daß der Datendurchsatz unabh¨angig von der Editierung konstant bleibt. Aus diesen Grunden¨ soll zumindest den Transmittern ein diskretes Modell zugrundegelegt werden. Fur¨ die Receiver spielt die Wahl eine eher untergeordnete Rolle.

Obwohl bekannt ist, daß das Ohr eine relativ schlechte r¨aumliche Aufl¨osung besitzt, sollen die Samples der Transmitter-Trajektorien eine Aufl¨osung von 32-Bit Floating Point und eine beliebige Abtastrate haben. So wird auch durch wiederholte Transformationen die Signal- qualit¨at nicht fruhzeitig¨ beeintr¨achtigt. Der Benutzer kann die Rate seinen Wunschen¨ gem¨aß anpassen und beispielsweise mit Modulationen im Audio-Frequenzbereich experimentieren.

25 3 Programmarchitektur

Konventionen

Im Fließtext werden programmiersprachliche Schlusselw¨ ¨orter, Namen von Klassen, Paketen und Variablen in Schreibmaschinenschrift gesetzt. In den Klassendiagrammen wird eine Auszeichnung nach Abbildung 3.1 vorgenommen.

3.1 Sprache und Arbeitsumgebung

1 Meloncillo wurde mit Java 1.4.2 SE entwickelt . Als integrierte Pro- Interface grammierumgebung (IDE) diente Apple Xcode Version 1.12. Die Entwicklung fand auf einem G4/800 mit Mac OS 10.3 statt. implementor/ subclass

Ein Kernelement von Java ist jedoch die M¨oglichkeit, vollkommen Abstract Class plattformunabh¨angige Programme zu erstellen. Voraussetzung ist, daß auf der Zielplattform eine sogenannte Virtual Machine (VM) Class verfugbar¨ ist. Die VM enth¨alt einen Just-in-Time (JIT) Compi- ler, der die vorkompilierten Java Klassen in dem Moment, in dem instance variable sie ben¨otigt werden, ubersetzt.¨ Eine Vielzahl der Bibliotheken des instanceof Standard-API arbeitet sehr eng mit nativen (plattformabh¨angigen) Bibliotheken zusammen – dies gilt beispielsweise fur¨ die Graphik- Collection Ausgabe –, so daß die Performance von Java Applikationen im all- gemeinen sehr hoch ist. Als fur¨ Echtzeitanwendungen hinderlich wird oft angesehen, daß der Programmierer keine Kontrolle uber¨ Abbildung 3.1: Legende den automatischen Garbage-Collector hat3. Tats¨achlich entschei- dender ist das Fehlen von pr¨azisen Clock Objekten, die erst fur¨ kommende Java Versionen angekundigt¨ sind. Dieses Problem wird bei der Echtzeit-Schnittstelle erl¨autert.

1Zur Sprachspezifikation von Java siehe [Gosling et al. 2000]. Diese hat sich uber¨ die verschiedenen Versionen praktisch nicht ge¨andert, neu in Version 1.4 ist lediglich das Konzept der Assertions (siehe http://java. sun.com/j2se/1.4.2/docs/guide/lang/assert.html) Die wesentlichen Anderungen¨ zu Vorg¨angerversio- nen bestehen stets aus der Erweiterung der Bibliotheken. Wichtige Bibliotheken von Version 1.4, auf die in Meloncillo zuruckgegriffen¨ wird, sind u.a. die java.util.prefs (fur¨ Preferences) und java.nio (New- I/O fur¨ Eingabe- und Ausgabestr¨ome) Packages. SE ist die Standard-Edition von Java, deren SDK frei erh¨altlich ist, daneben gibt es noch eine Enterprise-Edition (EE), die hier jedoch keine Rolle spielt. 2kurz vor Fertigstellung wurde auf Version 1.5 gewechselt 3Im Gegensatz zu C++ werden in Java nur in Ausnahmef¨allen finalize Methoden, d.h. Methoden zur Frei- gabe von Ressourcen nicht mehr ben¨otigter Objekte, explizit benutzt. Stattdessen verfolgt der Garbage- Collector, wann ein Objekt nicht mehr referenziert wird und damit freigegeben werden kann. Diese Frei- gaben erfolgen in unregelm¨aßigen Intervallen und k¨onnen damit das Echtzeit-Timing beeintr¨achtigen.

26 3 Programmarchitektur

Meloncillo wurde erfolgreich auf Mac OS X und mit der Sun VM auf Windows XP und Linux/KDE getestet. Sun’s Linux Support beschr¨ankt sich auf Intel-Prozessoren, auf PowerPC (Macintosh) Computern ist eine alternative VM wie Blackdown erforderlich. Die Blackdown PPC Version reicht momentan leider nur bis Java 1.2.2.4

Java wurde als Sprache gew¨ahlt, weil der objekt-orientierte Ansatz (OOP) sich hervorragend fur¨ die Entwicklung modularer Systeme eignet. Da der Hauptaspekt von Meloncillo auf der Programmierung der graphischen Oberfl¨ache liegt, spielt Java hier mit den Technologien Swing und Java2D seine Vorteile gegenuber¨ C++ aus.

Swing ist eine umfangreiche Bibliothek zum Erzeugen von GUI Objekten wie Fenstern, Menus,¨ Buttons, Listen, Textfeldern usw. Es bietet ein ausgereiftes Event-Management5 und eine Vielzahl von Layout-Managern6 an. Fur¨ das tats¨achliche Aussehen der GUI Elemente wird ein austauschbares Look-and-Feel verwendet, so daß sich Java Programme an die Optik nativer Programme anlehnen k¨onnen.

Java2D ist eine Graphikbibliothek fur¨ zweidimensionale Oberfl¨achen, auf die sp¨ater noch genauer eingegangen wird. Im Zuge der Anbindung von Meloncillo an Open Sound Con- trol kann auf die Packages java.net (Netzwerk-Funktionen) und java.nio (Input/Output Funktionen und Buffer) zuruckgegriffen¨ werden. Durch die automatische Garbage-Collection und umfangreiche Debugging M¨oglichkeiten zur Laufzeit (Java Reflection) wird die Pro- grammentwicklung und -wartung erheblich erleichtert. Nicht zuletzt ausschlaggebend fur¨ die Sprachwahl ist die umfangreiche Erfahrung des Autors mit Java.

Neben den Standard-Java-Bibliotheken werden folgende externe Bibliotheken verwendet:

• MRJAdapter von Steve Roy stellt Funktionen zur Verfugung,¨ mit denen das Programm sich besser an das Look-and-Feel von Mac OS anpassen kann, ohne dadurch seine Plattformunabh¨angigkeit einbußen¨ zu mussen.¨ 7 • Jatha von Micheal Hewett stellt eine kompakte Common Lisp Umgebung mit Brucken-¨ funktionen zu Java dar und wird im Plug-In Teil genauer erl¨autert.

Beide Bibliotheken stehen unter der GNU Lesser General Public License (LGPL) und lassen sich damit rechtlich unkompliziert benutzen8.

4http://www.blackdown.org/java-linux/java2-status/index.html 5Events sind hier Ereignisse, die durch Aktionen des Benutzers an GUI Elementen ausgel¨ost werden. Ein ActionEvent kann z.B. durch Klicken auf einen Button ausgel¨ost werden, ein ComponentEvent durch Ver- gr¨oßern eines Objekts bei Anderung¨ der Fenstergr¨oße. Die Applikation installiert sogenannte Listener, d.h. Callback-Interfaces, die Benachrichtigungen uber¨ diese Events bekommen. 6Ein Layout-Manager benutzt ein bestimmtes Modell, um die GUI Elemente dynamisch, d.h. zur Lauf- zeit und in Abh¨angigkeit von der Fenstergr¨oße, Schriftgr¨oße usw., anzuordnen. Einfache Manager ver- wenden z.B. ein Raster-Modell, andere benutzen Modelle mit elastischen Modulen zwischen Objekten (javax.swing.SpringLayout). Im Sinne der Objektorientierung fragen sie die Objekte nach ihren bevor- zugten, minimalen und maximalen Ausmaßen. 7MRJAdapter verwaltet z.B. grundlegende Menu-Punkte¨ wie Preferences und Quit. Es erlaubt das Verse- hen von Dokumentdateien mit sogenannten Creator-Codes und File-Types. http://www.roydesign.net/ mrjadapter/ 8Diese von der Free Software Foundation erarbeite Lizenz fur¨ Open-Source Bibliotheken sichert wie die bekanntere General Public License (GPL) die Rechte des Benutzers – er darf zum Beispiel die Software selbst modifizieren –, hat jedoch aus Sicht des Programmierers, der diese Bibliothek benutzen will, den Vorteil, daß dessen eigene Applikation nicht wie im Falle der GPL ebenfalls frei (unkommerziell und Open- Source) sein muß. http://www.gnu.org/licenses/lgpl.html

27 3 Programmarchitektur

3.2 Packages Uberblick¨

Inhaltlich zusammengeh¨orige Klassen werden zu Paketen (packages) zusammengefaßt, dabei wird ublicherweise¨ eine durch Punkte getrennte, von links nach rechts absteigende Hierarchie benutzt, die an Internet-URLs anlehnt ist. Dadurch k¨onnen sp¨ater andere Pakete erg¨anzt werden, ohne daß Namenskonflikte auftreten. Das hierarchisch oberste Paket (root) heißt de.sciss.meloncillo. Es enth¨alt die Klasse Main, die von der VM gestartet wird und die Klasse Session, die das Dokument des Programms beschreibt (Abschnitt 3.3). Die unterge- ordneten Packages sind:

• debug : Fehlerkontrolle w¨ahrend der Programmentwicklung • edit : Editierungen, die ruckg¨ ¨angig gemacht werden k¨onnen (Undo/Redo) • gui : Graphical User Interface Elemente • io : Datei Input/Output • lisp : Lisp-Interpreter und Erweiterungen • math : mathematische Funktionen und Signalverarbeitung • net : Netzwerkobjekte (Open Sound Control) • plugin : allgemeine Plug-In Schnittstelle • realtime : Echtzeit Plug-In Schnittstelle • receiver : Receiver-Objekte, -Gruppen, -Ereignisse • render : Offline Plug-In Schnittstelle • timeline : Timeline-Objekte • transmitter : Transmitter-Objekte, -Gruppen, -Ereignisse • util : verschiedene Hilfsklassen

3.3 Session

Meloncillo ist als Single-Document-Application (SDA) konzipiert, das heißt, der Benutzer hat es stets mit einem aktuellen Dokument zu tun, das alle relevanten Datenobjekte enth¨alt. Diese Objekte werden beim L¨oschen des Dokuments entfernt, beim Laden des Dokuments ausgetauscht, bestehen also fur¨ die Dauer einer Sitzung. Das zentrale Dokument in der Appli- kation wird daher – in Analogie zu Digidesign ProTools und ¨ahnlichen Programmen9 – als Session bezeichnet. Die Session Klasse besteht im wesentlichen aus den drei Objek- ten ReceiverCollection10, TransmitterCollection und Timeline, wie in Abbildung 3.2 gezeigt. Diese sind direkt als ¨offentliche Instanzvariablen zug¨anglich.

9Ein Gegenbeispiel fur¨ eine Multi-Document-Application ist Emagic Logic Pro, bei dem grunds¨atzlich be- liebig viele Dokumente gleichzeitig ge¨offnet sein k¨onnen. Dies erh¨oht allerdings die Anforderungen an den Programmierentwurf erheblich, so daß auf ein MDA Design verzichtet wurde. 10Collection ist ein grundlegendes, im Paket java.util enthaltenes interface, das die Gruppierung von Elementen beschreibt und Methoden zum Hinzufugen¨ und Entfernen von Elementen definiert. ReceiverCollection und TransmitterCollection enthalten ¨ahnlich benannte Wrapper-Methoden fur¨ die Gruppe von Receivern und Transmittern, die sie verwalten.

28 3 Programmarchitektur

Session receiverCollection transmitterCollection timeline

Timeline ReceiverCollection TransmitterCollection rate collReceivers length collTransmitters position collSelection visibleSpan collSelection selectionSpan

Receiver ReceiverEditor Transmitter TransmitterEditor

AbstractReceiver AbstractReceiverEditor AbstractTransmitter AbstractTransmitterEditor

SigmaReceiver SigmaReceiverEditor SimpleTransmitter SimpleTransmitterEditor distanceTable rcv mte trns rotationTable

Abbildung 3.2: Session Struktur

Sowohl Session, als auch ReceiverCollection, TransmitterCollection und Timeline implementieren das Interface11 XMLRepresentation. Dieses ist uber¨ zwei Methoden definiert: Quelltext 3.1: XMLRepresentation.java (io package) public interface XMLRepresentation { public void toXML( Document domDoc, Element node ) throws IOException; public void fromXML( Document domDoc, Element node ) throws IOException; }

XML steht fur¨ Extensible Markup Language und ist eine aus SGML hervorgegangene Daten- beschreibungs-Sprache, die vom W3C (World Wide Web Consortium) standardisiert wird12. Das Interface besagt, daß die Session in eine XML Node umgewandelt werden kann oder seine Elemente aus einer XML Node regeneriert werden k¨onnen13. Diese Methoden werden benutzt, um die Session abzuspeichern und zu laden. XML bietet zahlreiche Vorteile, darunter die einfache Lesbarkeit der Dateien im Textformat ( human readable“) und die automatische ”

11Java Interfaces definieren Methoden, die ein Objekt implementiert. Der Ausdruck Interface ist recht zutref- fend, weil es sich dabei in der Regel um F¨ahigkeiten handelt, die nicht spezifisch fur¨ eine bestimmte Klasse sind, sondern eher die Schnittstelle zu einer anderen Technologie beschreiben. W¨ahrend eine Klasse nur eine Superclass beerben kann, kann sie beliebig viele Interfaces implementieren. Das zweite Interface, das Session implementiert, heißt FilenameFilter und ist im Paket java.io definiert. Es besagt, daß Session die F¨ahigkeit besitzt, Dateinamen nach einem bestimmten Prinzip zu filtern. Dies wird benutzt, um beim Offnen¨ der Session nur XML Dateien anzuzeigen. 12http://www.w3.org/XML/1999/XML-in-10-points . Zur Einfuhrung¨ sei auch auf die FAQ http://www.ucc. ie/xml/ verwiesen. 13Ein XML Dokument besteht aus einer hierarchischen Baumstruktur mit Knoten, die Nodes genannt werden.

29 3 Programmarchitektur

Verifizierung der Dateien anhand einer Document Type Definition (DTD). Die Entwicklung einer DTD ist ein nicht ganz triviales Unterfangen, und Meloncillo Sessions benutzen im Moment noch keine explizite DTD.

Wird die Session abgespeichert, enth¨alt die XML Datei die entsprechenden Repr¨asentationen der Session Objekte und der Collection-Elemente – Receiver und Transmitter –, die ihrer- seits das Interface unterstutzen.¨ Mit abgespeichert werden ferner Programm Preferences, die fur¨ die Session relevant sind. Große bin¨are Datenmengen wie die Trajektorien der Transmit- ter k¨onnen nicht zufriedenstellend mit XML dargestellt werden und werden daher in einem speziellen Unterordner unabh¨angig von der Session-Datei abgespeichert.

3.4 Receiver, ReceiverCollection

Das ReceiverCollection Objekt verwaltet die Receiver einer Session. Es beinhaltet Metho- den zum Hinzufugen¨ und Entfernen von Receivern. Ein Subset von Methoden dupliziert diese Collection-Operationen in Hinblick auf eine Untergruppe der Receiver, n¨amlich die Gruppe der ausgew¨ahlten Receiver. Dies bezieht sich auf die graphische Oberfl¨ache, auf der der Be- nutzer ein oder mehrere Receiver ausw¨ahlen kann. Die ausgew¨ahlten Receiver werden optisch anders dargestellt und stellen die Untergruppe der Receiver dar, auf die Editierungs-Befehle wie Ausschneiden, Kopieren, Umbenennen oder Bewegen wirken. Die selektionsbezogenen Methoden beginnen mit dem Term selection. Kann zum Beispiel mit ReceiverCollection. contains() befragt werden, ob ein Receiver in der Gruppe aller Receiver enthalten ist, so liefert ReceiverCollection.selectionContains() Auskunft daruber,¨ ob ein Receiver der Gruppe der ausgew¨ahlten Receiver angeh¨ort usw.

Die eigentlichen Receiver Objekte werden fast ausschließlich uber¨ das Receiver Interface angesprochen, das im folgenden abgedruckt ist:

Quelltext 3.2: Receiver.java (receiver package) public interface Receiver { public static final DataFlavor receiverFlavor = new DataFlavor( Receiver.class, null );

public void setAnchor( Point2D newAnchor ); public void setSize( Dimension2D newSize ); public Point2D getAnchor(); public Dimension2D getSize(); public Rectangle2D getBounds(); public void setName( String newName ); public String getName(); public void setDirectory( File f ); public File getDirectory(); public void getSensitivities( float[][] points, float[] sense, int off, int stop, int step ); public Shape getOutline(); public Class getDefaultEditor(); }

Die Entscheidung, fur¨ die Receiver ein Interface zu definieren, begrundet¨ sich durch den Abstraktionsgrad, der den Receivern zugeschrieben werden soll. Außerdem erlaubt es einer

30 3 Programmarchitektur

Klasse, gleichzeitig das Receiver und Transmitter Interface zu implementieren. Die Abstrak- tion besteht darin, beispielsweise nicht festzulegen, daß ein Receiver kreisf¨ormige Ausmaße haben muß und seine Charakteristik aus einer Distanz- und einer Rotationstabelle sch¨opft, sondern nur zu definieren,

• daß der Receiver uber¨ einen Ankerpunkt und ein ¨außeres, seinen Umriß umspannendes Rahmenrechteck verfugen¨ soll (getAnchor() und getBounds()). • daß der Receiver uber¨ einen Namen identifiziert werden kann (getName()) • daß der Receiver durch eine schematische Umrißlinie dargestellt werden kann (get- Outline())14 • daß der Receiver eine bestimmte ortsabh¨angige Sensitivit¨at besitzt (getSensitivities). points ist eine Liste von kartesischen Koordinaten; die Sensitivit¨aten an diesen Punk- ten werden als Ergebnis in das Array sense geschrieben. • daß es einen Standard-Editor gibt, um den Receiver zu bearbeiten (getDefaultEditor())

Um diese grundlegenden Methoden nicht jedesmal vollst¨andig implementieren zu mussen,¨ wurde die Klasse AbstractReceiver entworfen, von der dann spezielle Receiver wie der sp¨ater beschriebene SigmaReceiver erben k¨onnen.

Die File bezogenen Methoden waren n¨otig, um das Laden und Abspeichern der Daten, die den Receiver konstituieren, zu erm¨oglichen. Sie h¨atten vielleicht besser in einem eigenen Interface untergebracht werden sollen.

DataFlavor geh¨ort zum Paket java.awt.datatransfer und beschreibt die M¨oglichkeit, ein Objekt fur¨ Clipboard- oder Drag-and-Drop Operationen zu formatieren. Das Feld receiver- Flavor beschreibt das Wrapper-Format, mit dem Receiver beim Benutzen der Funktionen Ausschneiden / Kopieren / Einfugen¨ dargestellt werden.

3.5 Transmitter, TransmitterCollection

Die theoretische Komplementarit¨at von Receivern und Transmittern soll auch in der Pro- grammstruktur deutlich werden. TransmitterCollection beschreibt damit spiegelbildlich alle Gruppierungsfunktionen, die in ReceiverCollection vorhanden sind, wendet sie jedoch auf die Transmitter einer Session an. Entsprechend ist Transmitter ein Interface, das ver- schiedene konkrete Transmitter mit unterschiedlichen Datenmodellen unterfuttern¨ k¨onnen: Quelltext 3.3: Transmitter.java (transmitter package) public interface Transmitter { public void setName( String newName ); public String getName(); public void setDirectory( File f ); public File getDirectory(); public Class getDefaultEditor();

public MultirateTrackEditor getTrackEditor(); }

14java.awt.Shape ist eines der grundlegenden Interfaces von Java2D, das beliebig geformte Umrißlinien oder Fl¨achen beschreibt

31 3 Programmarchitektur

Mit der Methode getTrackEditor wurde jedoch schon eine weitgehende Festlegung getroffen. Sie liefert ein Objekt, das die Trajektorien des Transmitters verwaltet. Um in einer sp¨ate- ren Programmversion andere Datenmodelle zu verwenden als das gegenw¨artige der Klasse SimpleTransmitter, sollte hier wahrscheinlich statt der konkreten Klasse MultirateTrack- Editor ebenfalls ein Interface TrackEditor zuruckgeliefert¨ werden.

Analog zu Receiver gibt es eine basale implementierende Klasse AbstractTransmitter, von der konkrete Transmitter erben k¨onnen.

3.6 Timeline

Das Timeline Objekt beschreibt die L¨ange der Session, die gegenw¨artige Zeitposition und die Sample-Rate der Trajektorien. Sie verwaltet zwei Teilbereiche, selectionSpan – der aktuell ausgew¨ahlte Zeitbereich, der von Editierungs-Operationen betroffen ist – und visibleSpan – der im TimelineFrame dargestellte Zeitausschnitt.

3.7 Events

Objekte sollten von dem Innenleben anderer Objekte so wenig wie m¨oglich wissen, sie kennen nur die ¨offentlich gemachten Methoden.15 Um die Flexibilit¨at zu wahren, sollte die Interaktion zwischen Objekten von unten“ realisiert werden; das bedeutet, daß ein Objekt sich m¨oglichst ” selbst darum kummern¨ sollte, an ben¨otigte Informationen zu gelangen, statt diesen Vorgang durch ein hierarchisch ubergeordnetes¨ Objekt zu initiieren.

Die ReceiverCollection braucht zum Beispiel nicht wissen, welche Objekte daran interes- siert sind, auf Receiver zuzugreifen. Stattdessen bietet sie eine standardisierte Schnittstelle an, uber¨ die sich Interessenten registrieren lassen k¨onnen. Die einzig erforderliche Gemeinsam- keit dieser Interessenten ist die Implementierung eines Listener Interfaces. Hier das Beispiel des ReceiverCollectionListeners: Quelltext 3.4: ReceiverCollectionListener.java (receiver package) public interface ReceiverCollectionListener extends EventListener { public void receiverCollectionChanged( ReceiverCollectionEvent e ); public void receiverCollectionTransformed( ReceiverCollectionEvent e ); public void receiverCollectionSelected( ReceiverCollectionEvent e ); }

Die ReceiverCollection bietet Methoden zum Anmelden und Abmelden eines Receiver- CollectionListeners an. Wenn eine Ver¨anderung eines Receivers oder einer Gruppe von Receivern auftritt, so werden alle angemeldeten Listener benachrichtigt, indem eine der im Quelltext 3.4 gezeigten Callback-Methoden aufgerufen wird. Klickt der Benutzer zum Beispiel einen Receiver an, so stellt dies eine Ver¨anderung der Gruppe der selektierten Receiver dar,

15Methoden, die mit dem Schlusselwort¨ public beginnen; Methoden, die protected deklariert werden, sind innerhalb desselben Pakets ¨offentlich.

32 3 Programmarchitektur und die Methode receiverCollectionSelected jedes einzelnen Listeners wird aufgerufen. Genauere Informationen zu dem Ereignis kann er dem ReceiverCollectionEvent Argument entnehmen.

Der Vorteil von diesem Konzept, das in ¨ahnlicher Art auch von den Java AWT und Swing Pa- keten verwendet wird, ist die M¨oglichkeit, daß sich neue Objekte dynamisch in die Eventverar- beitung einklinken k¨onnen. Alle Objekte, die Events generieren – neben den drei Bestandtei- len der Session sind dies vor allem GUI Elemente wie VectorEditor usw. –, implementieren das Interface EventManager.Listener. Sie generieren ein Hilfsobjekt, den EventManager, der den eigentlichen Dispatcher darstellt, das heißt die Verwaltung der Listener und des Event-Queue ubernimmt¨ und neu eingetroffene Ereignisse weiterleitet. Um das Multitasking berechenbar zu machen, werden in Analogie zum Event System von Java Swing alle Events von Meloncillo ebenfalls uber¨ den Swing Event Thread verteilt.

3.8 Threads

Der Event Thread16 ist der Hauptthread in Meloncillo. Alle Reaktionen auf das GUI wer- den zun¨achst innerhalb des Event Threads bearbeitet. Preferences Anderungen,¨ die zumin- dest in der Apple VM einen separaten Dispatcher verwenden, werden mit der Hilfsklasse LaterInvocationManager ebenfalls an den GUI Event Thread delegiert.

Wenn zeitaufwendige Prozesse anstehen, zum Beispiel das Offnen¨ einer Session, das Rendern von Trajektorien-Daten oder das Bounce-to-Disk, muß ein zweiter Thread gestartet werden, um die Reaktivit¨at der GUI nicht zu stoppen. Dies geschieht in der Regel durch eine neue Instanz von ProcessingThread.17

Ein weiterer wichtiger Thread ist der Transport, ein Objekt, das die Echtzeit-Verarbeitung verwaltet. Dieser Thread wird zum Programmstart generiert und pausiert, wenn der Trans- port gestoppt ist; w¨ahrend des Wartens auf Transport-Befehle findet keine CPU Belastung statt. Damit der Rhythmus der Uhr-Ticks im Echtzeit-Betrieb nicht beeintr¨achtigt wird, ver- sendet das Lisp Realtime Plug-In (Abschnitt 5.3.1) OSC Datenpakete nicht aus dem Trans- port, sondern aus einem weiteren Thread.

Der letzte wichtige Fall fur¨ eigenst¨andige Threads ist der Empfang von OSC Nachrichten, der von der Klasse OSCReceiver bewerkstelligt wird. Der Thread pausiert automatisch, wenn keine Nachrichten eintreffen. Erreicht ein neues Datagramm den Empf¨anger, wird der Thread

16Threads sind nebenl¨aufige Prozesse. Zwar arbeiten in der Regel nur ein oder zwei Prozessoren im Compu- ter, das Betriebssystem schaltet jedoch in rascher Reihenfolge zwischen den aktiven Threads um, so daß praktisch mehrere Aufgaben (Tasks) gleichzeitig bewerkstelligt werden k¨onnen. In Java ist ein bestimm- ter Thread – der Event Dispatcher Thread – fur¨ die gesamte GUI Verwaltung zust¨andig, einschließlich der Bekanntmachung von Eingabe-Ereignissen (z.B. Mausbewegungen, Button-Klicks) und dem Aufruf von Methoden, die die GUI Elemente zeichnen (paint Methode). Zur Einfuhrung¨ in Java-Threads siehe [Lea 1997], S. 8–26 17Wenn der Prozeß synchronisiert ist (einen blockierenden sogenannten Monitor auf ein Objekt besitzt), werden die Dispatcher w¨ahrenddessen angehalten, so daß Ver¨anderungen erst im Anschluß weitergeleitet werden. Zum Beispiel werden beim Offnen¨ einer Session viele verschiedene Anderungen¨ an der Grup- pe der Receiver und Transmitter vorgenommen. Diese Ver¨anderungen werden weitergeleitet, wenn der Lade-Vorgang abgeschlossen ist, um eine Deadlock-Situation, die durch konkurrierende Synchronisierungs- versuche entstunde,¨ zu vermeiden.

33 3 Programmarchitektur fortgesetzt, und er benachrichtigt alle registrierten Listener. OSC wird im Abschnitt 5.4.2 beschrieben.

Objekte, auf die potentiell von verschiedenen Threads zugegriffen werden kann, mussen¨ synchronisiert werden, das heißt mit einem Mechanismus ausgestattet sein, der Interferen- zen unterbindet, die zu undefinierten Zust¨anden in oder ungultigen¨ Informationen uber¨ diese Objekte fuhren.¨ Dafur¨ wurde die Klasse LockManager entwickelt, die uber¨ das ein- fache Synchronisations-Konzept von Java hinaus zwischen geteilten Lese- und exklusiven Schreib-Zugriffen unterscheidet.18 Die Session besitzt einen LockManager fur¨ die Objekte ReceiverCollection, TransmitterCollection und Timeline.

18vgl. [Lea 1997], S. 133–136 und 169–171

34 4 Graphische Benutzerober߬ache

4.1 Surface : zweidimensionale Momentansicht

Das graphische Hauptelement der meisten Raumklangsteuerungen ist eine schematische Sicht auf das r¨aumliche Szenario. Dabei handelt es sich oft um eine zweidimensionale Momentan- sicht. Durch Bewegen der Zeitachsen-Position oder Starten des Transports werden die dyna- mischen Objekte animiert. Diesem Videoschirm-Paradigma“ folgt auch Meloncillo. W¨ahrend ” einige Programme auch dreidimensionale Raumansichten bieten1 oder als Middleware fur¨ Vir- tual Reality 3D-Applikationen fungieren2, folgt die planare Editierung aus der ausschließli- chen Zweidimensionalit¨at gegenw¨artiger Computersysteme (Bildschirm, Maus/Joystick/ Tablett).

Die Surface Klasse ist zust¨andig fur¨ die 2D-Sicht in Meloncillo. Eine solche Darstellung ist in Abbildung 4.1 abgedruckt. Receiver und Transmitter werden durch kleine rote respek- tive grune¨ Fadenkreuze dargestellt, die mit dem Namen der Objekte versehen sind. Die Umrißlinie der Receiver ist gestrichelt dargestellt. Optional wird die Sensitivit¨at der Re- ceiver in Grauschattierungen gezeigt. Wird die Zeitachsen-Position ver¨andert, bewegen sich die Transmitter entsprechend. Um die Trajektorien besser beurteilen zu k¨onnen, werden sie optional eingeblendet: Ein gruner¨ gestrichelter Pfad stellt den Verlauf der Trajektorien der ausgew¨ahlten Transmitter im ausgew¨ahlten Zeitabschnitt dar. Die Aufl¨osung, d.h. die Zahl der Stutzpunkte,¨ wird automatisch heruntergeschaltet, wenn der Zeitabschnitt gr¨oßer wird, um eine ausreichende Geschwindigkeit der Graphikdarstellung zu gew¨ahrleisten. Das Konzept der stufenweise aufgel¨osten Trajektoriendaten wird im Abschnitt 4.2.1 erl¨autert.

Alle Graphikbefehle sind im Rahmen von Java2D realisiert, dadurch l¨aßt sich das Surface Fenster stufenlos vergr¨oßern. Alle Objektkoordinaten werden in einem virtuellen Raum ausge- druckt,¨ der auf die Gr¨oße 1.0×1.0 normalisiert ist. Dazu implementiert Surface das Interface VirtualSurface: Quelltext 4.1: VirtualSurface.java (gui package) public interface VirtualSurface { public Point2D snap( Point2D freePt, boolean virtual ); public Point2D screenToVirtual( Point2D screenPt ); public Point2D virtualToScreen( Point2D virtualPt ); public Rectangle virtualToScreenClip( Rectangle2D virtualClip ); public Shape virtualToScreen( Shape virtualShape ); public Shape screenToVirtual( Shape screenShape ); }

1vgl. die IEM-Cube Software in [Zm¨olnig et al. 2003]. Siehe auch [Momenti/Wessel 2003]. 2vgl. das Scream Projekt in [Leahy 2004], das eine Anbindung an 3D Spiele und Multimedia vorsieht; ¨ahnlich das Sonificator Projekt in [Muhlethaler/Schuppisser¨ 2004], fur¨ das eine graphische Java3D Anwendung geschrieben wurde.

35 4 Graphische Benutzerober߬ache

Abbildung 4.1: Surface Fenster Abbildung 4.2: Hilfspaletten

VirtualSurface beschreibt also Methoden, um Koordinaten (wie sie beispielsweise von der Maus generiert werden) von der Bildschirm-Ebene in die virtuelle Ebene und umge- kehrt zu transformieren. Die Objekte Point2D und Rectangle2D sind Teil des Hauptpakets von Java2D, java.awt.geom. Darin sind vor allem das Interface Shape und die Klasse AffineTransform interessant: Shape beschreibt eine beliebige zweidimensionale geometri- sche Form, die in eine Folge von einfachen Segmenten (den PathIterator) zerlegt werden kann. Shape Objekte k¨onnen darauf getestet werden, ob sie bestimmte Punkte enthalten oder andere Shape Objekte uberschneiden.¨ Einige Klassen, die Shape implementieren, bieten Menge-Operatoren wie UND- oder Exklusive-ODER Verknupfung.¨

Mit einer AffineTransform lassen sich geometrische Skalierungen, Scherungen und Rota- tionen beschreiben. Diese k¨onnen auf Point2D und Shape Objekte angewandt werden. Die graphische Realisation findet in einem Graphics2D Kontext statt. Die Methode fill zeich- net dabei mit beliebiger Farbe, Verlauf oder Muster die Fl¨acheninhalte von Shapes. Die Methode draw zeichnet mit beliebiger Strichst¨arke und Form die Umrißlinie von Shapes. Das Graphics2D Objekt bietet die M¨oglichkeit, sogenannte RenderingHints zu setzen und damit die Qualit¨at der Graphik, zum Beispiel bei Skalierungen oder der Verwendung von Anti-Aliasing Techniken, zu kontrollieren.

Trotz der hohen Performance von Java2D muß in der Echtzeit-Umgebung versucht werden, aufwendige Graphikoperationen wie Skalierungen und semitransparentes Zeichnen zu mini- mieren. Dazu werden die statischen Elemente in ein Offscreen-Image gerendert, das dann relativ schnell wiederholt gezeichnet werden kann. Die Darstellung der Receiver-Sensitivit¨at

36 4 Graphische Benutzeroberfl¨ache selbst ist eine grob aufgel¨oste Bitmap-Graphik (8-Bit Graustufen), deren Berechnung relativ langsam ist.

4.1.1 Hilfs-Paletten und Werkzeuge

In der Abbildung 4.2 sind zwei Hilfs-Paletten zu sehen, die weitere Funktionalit¨at fur¨ die Surface und andere Objekte bereitstellen. Die ObserverPalette stellt kontextsensitive Text- Informationen dar. Sie enth¨alt verschiedene Karten, die in Abh¨angigkeit von der Benutzer- Aktion umgeschaltet werden. W¨ahlt der Benutzer beispielsweise einen Receiver aus, wird die Rcv“-Karte angezeigt. Sie enth¨alt die exakten Koordinaten des Anker-Punktes (Mittel- ” punktes) des Receivers, seine Ausdehnung und seinen Namen. Diese Angaben k¨onnen durch Texteingabe ge¨andert werden. Durch Anw¨ahlen einer Gruppe von Receivern k¨onnen diese gleichzeitig ver¨andert und ausgerichtet werden. Die weiteren Karten des Observers betreffen die ausgew¨ahlten Transmitter und die Timeline. Die Csr“-Karte stellt die aktuellen Maus- ” koordinaten (im virtuellen Bezugssystem) dar.

Die ToolPalette stellt die grundlegenden Editierungsfunktionen fur¨ die Surface bereit. Von links nach rechts zu sehen sind

• Auswahl-Werkzeug : Es dient der Auswahl und dem Bewegen von Receivern • Linien-Werkzeug : Zum Generieren linearer Trajektorien-Verl¨aufe • Kurven-Werkzeug : Generiert Trajektorien-Verl¨aufe anhand von kubischen Kurven • Kreissegment-Werkzeug : Generiert Trajektorien, die entlang einer Kreisbahn verlaufen • Freihand-Werkzeug : Dient der Echtzeit-Aufzeichnung von Mausbewegungen • Blending-Option : Versieht die Editierungen mit einer Uberblendung¨ (Crossfade)

Linien, Kurven und Kreissegmente sind Offline-Werkzeuge, sie arbeiten unabh¨angig vom Transport. Der Benutzer bestimmt einen Zeitausschnitt, uber¨ den sich der Trajektorien- Abschnitt erstrecken soll. Er zieht die werkzeugspezifische Grundform, die durch zwei Stutz-¨ punkte definiert ist. Anschließend kann er durch Anfassen und Ziehen der Kontrollpunkte die Form anpassen. Mit Tastaturbefehlen (Escape und Return) wird die Geste abgebrochen oder ausgefuhrt¨ (gerendert). Uber¨ eine spezielle Tastenkombination kann eine Serie von zu- sammenh¨angenden Segmenten gezeichnet werden.

Da diese drei Werkzeuge analytische (durch eine Funktion beschriebene) Formen darstellen, k¨onnen sie an beliebigen Punkten ausgewertet werden. Aufgrund dieser Uberlegung¨ wurde ein Velocity-Modus integriert, der dem Benutzer erlaubt, die Start- und Endgeschwindigkeit der Bewegung zu beeinflussen. Um zu verdeutlichen, was damit gemeint ist, sehen wir uns die dafur¨ vorgesehenen Methoden in der Super-Klasse AbstractGeomTool an:

37 4 Graphische Benutzerober߬ache

Quelltext 4.2: AbstractGeomTool.java (gui package) public abstract class AbstractGeomTool extends AbstractTool implements KeyListener { [...]

protected boolean canAccelerate() { return true; }

protected boolean initFunctionEvaluation( Point2D[] ctrlPoints ) { return false; }

protected void evaluateFunction( float[] warpedTime, float[][] interpBuf, int len ) {} [...] }

Die F¨ahigkeit, die Funktion an variablen Zeitpunkten auszuwerten, wird durch die Me- thode canAccelerate erfragt. Die Methode initFunctionEvaluation dient der Initialisie- rung von Parametern, die nur einmal berechnet werden mussen.¨ Der eigentlichen Methode evaluateFunction wird ein Array von Zeit-Werten ubergeben,¨ die monoton steigend aber nicht linear verteilt sein mussen.¨ Die Bezeichnung warpedTime besagt, daß die Eingangs- Zeitwerte ungleichm¨aßig angeordnet sind, die ihnen zugeordneten (in der Methode berech- neten) Funktionswerte jedoch als mit konstanter Sampling-Rate abgetasteter Trajektorien- Abschnitt aufgefaßt werden.

Mit anderen Worten, wenn eine Strecke mit dem Linien-Werkzeug gezeichnet und die Funk- tion so ausgewertet wird, daß die Eingangs-Zeitwerte zu Beginn dichter beieinander liegen als zum Schluß, so ergibt sich eine lineare Bewegung des Transmitters, deren Geschwindigkeit zunimmt.3 Durch Doppelklick auf die Surface wird dem Benutzer eine einfache M¨oglichkeit gegeben, die Start- und Endgeschwindigkeit der geometrischen Form anzupassen. Der Verlauf der Geschwindigkeit wird mit einer kubischen Funktion so berechnet, daß unabh¨angig von den Einstellungen des Benutzers der gew¨ahlte Zeitabschnitt exakt ausgefullt¨ wird. Die Ge- schwindigkeit wird durch eine transparente gelbe Hullkurve¨ dargestellt, die der geometrischen Grundform folgt (Graudarstellung in Abbildung 4.3).

In einer zukunftigen¨ Version sollte die M¨oglichkeit, mehrere Linienzuge¨ nacheinander zu zeich- nen, so erweitert werden, daß auch der Geschwindigkeitsvektor im Schnittpunkt zwischen zwei Segmenten stetig ist.

Die Funktion des Freihand-Tools wird im Abschnitt uber¨ den Transport dargestellt.

Um beim Einzeichnen von Trajektorien-Abschnitten zu vermeiden, daß ein Transmitter sprunghaft den Ort wechselt, kann durch Aktivierung der Blending-Option ein automati- scher Crossfade zwischen den vorherigen und den neuen Trajektorien-Daten erzeugt werden. Dies ist auch hilfreich beim Filtern der Trajektorien mit Plug-Ins, die in vielen F¨allen eine Unstetigkeit an den R¨andern des gefilterten Zeitausschnittes erzeugen. Ebenso kann mit einer

3 Die Geschwindigkeit ist proportional zu ∆twarped/T mit T = Sampleperiode der Trajektorien.

38 4 Graphische Benutzerober߬ache

Abbildung 4.3: B´ezier-Kurve mit variabler Geschwindigkeit langen Blending-Dauer der Output einfacher Filter ein- und ausgeblendet werden, so daß eine dynamische Transformation stattfindet, obwohl die Filter selbst keine zeitvariablen Parameter besitzen.

4.1.2 ReceiverEditor

Mit Doppelklick auf den Anker eines Receivers wird ein Editor ge¨offnet (Abbildung 4.4), mit dem die Sensitivit¨at des Receivers eingestellt werden kann. Grunds¨atzlich sind Receiver und ReceiverEditor Interfaces in Meloncillo, so daß sich verschiedene Modelle fur¨ die Berechnung der Sensitivit¨at integrieren lassen. In der aktuellen Version ist lediglich eine Klasse von Recei- vern vorhanden, der SigmaReceiver, der in Analogie zu Σ 1 eine Kreuzung zweier Tabellen vorsieht: Die Distance-Tabelle beschreibt die Empfindlichkeit des Receivers in Abh¨angigkeit eines Abstandes vom Anker-Punkt. Die Rotation-Tabelle beschreibt die Abh¨angigkeit vom Winkel, den ein Transmitter zum Anker-Punkt des Receivers einnimmt. Die Tabellen-Werte sind momentan linear skaliert und werden daher multipliziert: sense(r, φ) = distance table[r] · rotation table[φ]

Dadurch lassen sich alle Standard-Formen von Kugel bis Niere und Acht beschreiben. Da die Tabellen hinreichend groß sind (jeweils 1024 Punkte4), lassen sich durch harte Kanten oder Rauschen auch experimentelle nicht-stetige Empfindlichkeitsverl¨aufe realisieren. Dazu stehen per Popup-Menu¨ verschiedene Signalgeneratoren und mathematische Operationen zur Verfugung.¨ Um Zipper-Noise bei langsamen Bewegungen und tieffrequenten harmonischen T¨onen zu vermeiden, werden die Tabellen-Werte linear interpoliert.

Im klassischen Amplituden-Panning werden die Sensitivit¨aten direkt auf Lautst¨arken ge- mappt. Durch Vergr¨oßern der Receiverfl¨ache und Editieren der Tabellen lassen sich praktisch alle Panning-Verl¨aufe umsetzen und Divergenzen simulieren. Wird ein anderes Verfahren benutzt, beispielsweise VBAP, so sind fur¨ das reine Panning nur die Receiver-Koordinaten von Bedeutung; die Sensitivit¨at kann in diesem Fall ganz anders genutzt werden, etwa als Parameter fur¨ die Ansteuerung eines Raumhalls, einer Filterung oder Verzerrung.5

4Dies wird in einer zukunftigen¨ Version vom Benutzer konfigurierbar sein. 5In einer zukunftigen¨ Version wird es eine weitere Receiver-Klasse geben, die gar keine Sensitivit¨ats-Daten generiert und somit effektiv ist, wenn darauf ohnehin verzichtet wird, wie z.B. in einer HRTF Synthese.

39 4 Graphische Benutzerober߬ache

Abbildung 4.4: Editor fur¨ SigmaReceiver Abbildung 4.5: Matrix Meter

4.1.3 Matrix Meter

Der Observer zeigt w¨ahrend der Tabellen-Editierung die exakte Sensitivit¨at eines Receivers an. Um zu kontrollieren, wie der Ubergang¨ von einem Receiver zum n¨achsten verl¨auft, kann das sogenannte Matrix Meter Fenster eingeblendet werden (Abbildung 4.5). Es zeigt jeweils eine Zeile oder Spalte der aus Transmittern und Receivern gebildeten Matrix an. Durch Klick auf einen Transmitter Namen werden die momentanen Empfindlichkeiten aller Receiver an der Stelle dargestellt, an der sich dieser Transmitter befindet. Umgekehrt werden durch Klick auf einen Receiver Namen die Sensitivit¨aten dieses Receivers zu allen momentanen Transmitter- Positionen dargestellt. In einer zukunftigen¨ Version wird das Meter optional logarithmisch dargestellt6, außerdem sollen die exakten Werte im Observer ausgegeben werden.

4.2 Timeline : horizontale Zeitdarstellung

Fur¨ einen simultanen Uberblick¨ uber¨ den Verlauf der Trajektorien und die Gesamtform der Komposition sorgt das TimelineFrame (Abbildung 4.6). Ahnlich¨ dem Arrangier-Fenster eines Harddisk-Recording-Programms ist hier die Zeitachse horizontal aufgetragen, w¨ahrend die verschiedenen Spuren, die die Trajektorien der Transmitter zeigen, vertikal angeordnet sind. Jede Spur besteht aus zwei eindimensionalen Vektoren, die die kartesischen Koordinaten (x, y) der Trajektorien zeigen. M¨oglicherweise zeigt eine zukunftige¨ Version optional eine Polar-Koordinaten-Sicht. Die kartesische Darstellung hat jedoch den Vorteil, daß sie der inter- nen Datendarstellung entspricht und somit schnell gezeichnet werden kann, davon abgesehen mußten¨ Winkel mit der Periode 2π umgebrochen werden.

6Die jetzige Darstellung ist linear.

40 4 Graphische Benutzerober߬ache

Abbildung 4.7: Transport Abbildung 4.6: Timeline Fenster Palette

Die Darstellung der Koordinaten-Vektoren erfolgt mit einem VectorEditor, dadurch ist das direkte Einzeichnen mit der Maus m¨oglich. Komfortabler ist jedoch die Editierung auf der Surface oder mittels Filterung, wie sie im Plug-In Kapitel beschrieben wird. Die Editierung, die typischerweise im Timeline Fenster gemacht wird, ist das Ausschneiden, Kopieren und Einfugen¨ von Trajektorien-Abschnitten. Am oberen Rand des Fensters ist eine Zeitachse zu erkennen. Durch Klicken mit der Maus kann die gegenw¨artige Zeitposition, die durch die vertikale rote Linie symbolisiert wird, verschoben werden. Durch Halten der Umschalttaste kann eine Region selektiert werden, die durch dunklere Schattierung hervorgehoben wird. Durch Klick auf die Namen der Transmitter-Spuren k¨onnen diese Transmitter selektiert und deselektiert werden. Die Cut- und Copy-Befehle wirken auf die Trajektorien-Ausschnitte, die durch die selektierten Transmitter und den selektierten Zeitausschnitt bestimmt sind. Die Paste-Operation fugt¨ den Clipboard-Inhalt in die Trajektorien der gew¨ahlten Transmitter ein, an der Stelle, an der sich die Zeitposition befindet.

4.2.1 Trajektorien Daten-Format

Die Darstellung des Timeline Fensters kann horizontal und vertikal vergr¨oßert und verklei- nert werden. Durch die Diskretisierung der Trajektorien kann der Fall auftreten, daß durch Herauszoomen ein Ausschnitt dargestellt wird, dem mehrere Tausend bis Hunderttausende von Frames entsprechen. Eine solch große Zahl von Frames einzulesen ist sowohl zu zeit- als auch zu speicherintensiv. Die L¨osung besteht in einer Unterabtastung der Trajektorien. Dies geschieht in mehreren Schritten, um stets eine optimale Aufl¨osung zur Verfugung¨ zu haben. Jede Dezimations-Stufe verringert die Frame-Rate um den Faktor vier. Da VectorEditor die Daten als Vektorgraphik darstellt, wird der Umschaltpunkt so gelegt, daß maximal doppelt soviele und minimal halb soviele Punkte wie die aktuelle Fensterbreite gezeichnet werden.

Insgesamt werden sechs dezimierte Tracks pro Trajektorie berechnet. Angenommen den ex- trem unwahrscheinlichen Fall, daß die Framerate in der Gr¨oßenordnung von Audioraten liegt, zum Beispiel 48 kHz, so besitzt der am st¨arksten dezimierte Track (Faktor 1/4096) eine Rate

41 4 Graphische Benutzerober߬ache

1/1

: 4

1/4

: 4

1/16

Abbildung 4.8: Dezimation von Trajektorien von ca. 12 Hz. Wenn innerhalb einer Fensterbreite eine halbe Stunde dargestellt werden sollte, w¨are damit eine Puffergr¨oße von 21094 Frames verbunden. In dem wahrscheinlicheren Fall einer Framerate von 4800 Hz oder weniger k¨onnte eine volle Stunde mit gerade 4219 dezi- mierten Frames dargestellt werden, was einen geringen RAM-Verbrauch und geringe CPU Belastung bedeutet.

Die gespeicherte Session enth¨alt die Trajektorien in Form von Floating-Point Dateien in einem separaten Unterordner trns. Die dezimierten Dateien werden momentan nicht gespeichert, sondern beim Laden einer Session adhoc erstellt, was akzeptabel schnell verl¨auft. Die im tem- por¨aren Verzeichnis gespeicherten dezimierten Trajektorien ben¨otigen ca. 1/3 der Gr¨oße der Originaldatei. Die Editierung der Trajektorien geschieht nicht-destruktiv, das heißt, die Origi- naldatei wird bis zum Abspeichern der Session nicht ver¨andert. Die Verwaltung dieser nicht- linearen und nicht-destruktiven Editierung ubernimmt¨ die Klasse MultirateTrackEditor (MTE), die im wesentlichen sieben SubsampleTrackEditoren verwaltet. Diese repr¨asentieren die Trajektorien-Daten in voller respektive dezimierter Rate. Um auch bei st¨arkerer Dezima- tion eine m¨oglichst gute Ann¨aherung an die Signaleigenschaften zu erhalten, wird in jeder Stufe aus den jeweils vier Ausgangsframes jedes dezimierten Frames der Median berechnet. Abbildung 4.8 zeigt zwei Stufen des Dezimations-Prozesses.

Der MTE verwaltet eine sogenannte TrackList, eine chronologische Liste aus TrackSpan Objekten, die wie folgt aussehen:

Quelltext 4.3: TrackSpan.java (io package) public class TrackSpan { public Span span; public final InterleavedFloatFile f; public long offset; [...] }

Span ist eine Klasse, die sehr h¨aufig in Meloncillo benutzt wird. Sie beschreibt eine Zeitspanne durch Angabe eines Start- und Endframes. Die Spannen der Track-Liste fugen¨ sich nahtlos aneinander. Wird eine Session ge¨offnet, so besteht die Liste lediglich aus einem TrackSpan, der die gesamte Dauer der Session umfaßt. Wird jetzt ein Teil der Trajektorie herausgeschnitten, so wird diese TrackSpan durch zwei neue ersetzt, die die Spannen vor und nach dem Schnitt beschreiben. Die Datei vom Typ InterleavedFloatFile, die die Trajektorien-Daten enth¨alt,

42 4 Graphische Benutzeroberfl¨ache bleibt unver¨andert. Das Feld offset wird jedoch stets so angepaßt, daß es auf den richtigen Punkt innerhalb dieser Datei zeigt. Wird jetzt eine Trajektorie zum Beispiel mit dem Linien- Werkzeug uberzeichnet,¨ so wird der neue Abschnitt in einer tempor¨aren Datei gerendert und in Form einer neuen TrackSpan in die Track-Liste eingefugt.¨ Gegebenenfalls wird am Insert-Punkt die alte TrackSpan in zwei separate Objekte aufgeteilt.

Der MTE sorgt dafur,¨ daß nach jeder Editierung der Trajektorien die Dezimations-Files auf den aktuellen Stand gebracht werden. Die SubsampleTrackEditoren enthalten ebenfalls eine Liste von TrackSpans, deren Spannen jedoch durch die spezialisierte BiasedSpan Klasse beschrieben werden. BiasedSpan sorgt dafur,¨ daß die Rundungsfehler, die durch die Unter- abtastung hinsichtlich der Start- und Stopframes entstehen, stets minimiert werden.

4.2.2 Transport Palette

Abbildung 4.7 zeigt ein Fenster mit einfachen Transport-Funktionen. Der Transport ist eng mit der Realtime-Engine des Programms verknupft.¨ Er enth¨alt einen eigenen Event-Dispat- cher, der registrierte Listener uber¨ Start- und Stop-Vorg¨ange informiert. Die Palette enth¨alt einen Play- und Stop-Button und einen Loop-Umschalter. Das ballf¨ormige Symbol ganz rechts aktiviert das Realtime-Plug-In, das im n¨achsten Kapitel beschrieben wird.

Der Transport dient neben dem Realtime-Preview auch dem Aufzeichnen von Transmitter- Bewegungen in Echtzeit. W¨ahrend der Transport l¨auft, kann mit dem Freihand Werkzeug auf der Surface entlanggefahren werden. Die Bewegung wird zwischen den Stutzpunkten¨ linear interpoliert. Die Editierung wird gerendert, wenn der Mausknopf losgelassen wird. Das impliziert, daß die Bewegung im Moment des Zeichnens noch nicht uber¨ das Preview-Plug-In zu h¨oren ist. Eine L¨osung dafur¨ wird in der n¨achsten Programm-Version angestrebt.

43 5 Plug-In Schnittstellen

An drei Punkten wird im Programm auf ein Plug-In Konzept zuruckgegriffen:¨

• Filterung von Trajektorien • Bouncen (Rendern) der Klang-Synthese auf Harddisk • Realtime Vorschau der Klang-Synthese

Die Verwaltung dieser Plug-In Typen ubernehmen¨ drei Objekte, die das PlugInHost Interface implementieren: Es sind FilterDialog, BounceDialog und RealtimeFrame. Das Diagramm 5.1 zeigt die Hierarchie der am Plug-In Konzept beteiligten Klassen und Interfaces.

5.1 Offline (Nicht-Echtzeit)

Die nicht-echtzeit-basierten Filter- und Bounce-Plug-Ins implementieren das Interface Render- PlugIn:

Quelltext 5.1: RenderPlugIn.java (render package) public interface RenderPlugIn extends PlugIn { public boolean producerBegin( RenderContext context, RenderSource source ) throws IOException;

public boolean producerRender( RenderContext context, RenderSource source ) throws IOException;

public boolean producerFinish( RenderContext context, RenderSource source ) throws IOException;

public void producerCancel( RenderContext context, RenderSource source ) throws IOException; }

Es ubernimmt¨ als Subinterface von PlugIn eine Methode zur Generierung einer Plug-In- Oberfl¨ache (getSettingsView()), die vom RenderHost innerhalb eines Fensters dargestellt wird. Der Host reagiert auf die Aktionen des Benutzers. Wenn dieser den Render-Vorgang startet, ruft er nacheinander nach dem Push-Verfahren die Methoden producerBegin, pro- ducerRender und producerFinish des Plug-Ins auf, wobei producerRender gegebenenfalls mehrfach mit Teilbl¨ocken der zu rendernden Zeit aufgerufen wird.

44 5 Plug-In Schnittstellen

PlugIn PlugInHost

RealtimePlugIn RenderPlugIn RealtimeHost RenderHost

RealtimeConsumer Transport BasicRenderDialog RenderConsumer

BounceDialog FilterDialog

LispRealtimePlugIn LispRenderPlugIn TimeWarpFilter VectorTransformFilter

LispBounce LispFilter

Abbildung 5.1: Plug-In Interfaces und Klassen

Im Falle des Trajektorien-Filters mussen¨ die gefilterten Daten wieder zuruck¨ zur Applikation fließen. Dazu ubergibt¨ der Host dem Plug-In ein Objekt, das das Interface RenderConsumer implementiert. Es ist ganz ¨ahnlich dem RenderPlugIn aufgebaut: Quelltext 5.2: RenderConsumer.java (render package) public interface RenderConsumer { public boolean consumerBegin( RenderContext context, RenderSource source ) throws IOException;

public boolean consumerRender( RenderContext context, RenderSource source ) throws IOException;

public boolean consumerFinish( RenderContext context, RenderSource source ) throws IOException;

public void consumerCancel( RenderContext context, RenderSource source ) throws IOException; }

Das Plug-In fungiert dann als eigener Host, der den Consumer mit Datenblocks futtert.¨ Der FilterDialog ist bidirektional aufgebaut – das heißt, er empf¨angt die gefilterten Trajektorien und fugt¨ sie wieder in die Session ein –, implementiert daher sowohl RenderHost als auch RenderConsumer. Grunds¨atzlich werden zwei Typen von Daten unterschieden, die w¨ahrend der Plug-In Bearbeitung Informationen liefern: statische Daten, die in einem PlugInContext Objekt zusammengefaßt sind – beispielsweise die gesamte zu bearbeitende Zeitspanne, die beteiligten Transmitter und Receiver. Und dynamische Datenstr¨ome, die blockweise generiert werden und in Form des RenderSource Objekts zur Verfugung¨ stehen.

Wenn das Plug-In durch Aufruf von producerBegin initialisiert wird, kann es sogenannte Request-Felder im RenderSource ausfullen¨ und gibt damit bekannt, welche Datenstr¨ome

45 5 Plug-In Schnittstellen

Abbildung 5.2: Plug-Ins zur Trajektorien-Filterung erzeugt werden mussen.¨ Ein Plug-In kann zum Beispiel nur an den Trajektorien-Daten (wie im Falle der Filter-Klassen) oder nur an den Sensitivit¨aten der beteiligten Receiver interessiert sein.

Fur¨ die Filterung von Trajektorien stehen momentan drei Plug-Ins bereit, deren Settings- Views in Abbildung 5.2 zu sehen sind.

• Der TimeWarpFilter ordnet anhand einer Tabelle die Eingangszeitwerte (Ordinate) den Ausgangszeitwerten (Abszisse) zu, d.h. traj0(t) ← traj(f(t)). Eine absteigende Gerade bewirkt, daß die ursprunglichen¨ Bewegungen ruckw¨ ¨arts wieder gegeben werden. Eine Parabel wurde¨ ein Vorw¨arts- und Ruckw¨ ¨artslaufen simulieren, ein S¨agezahn mit drei Perioden wurde¨ die ausgew¨ahlte Trajektorie dreimal mit dreifacher Geschwindigkeit wiederholen. • Der VectorTransformFilter bietet die M¨oglichkeit, x und y Werte (alternativ Radius und Winkel zu einem Bezugspunkt) mit einer mathematischen Funktion zu bearbei- ten. Unter anderem steht ein Funktionsgenerator zur Verfugung,¨ mit dem sich einfache geometrische Figuren wie Spiralen und Linien oder das Hinzufugen¨ von Unregelm¨aßig- keiten (Rauschen) realisieren lassen. • Der LispFilter stellt ein frei programmierbares Plug-In dar, das uber¨ Common Lisp Scripte gesteuert wird. Es wird in Abschnitt 5.3 erkl¨art.

5.2 Realtime (Echtzeit)

Aus Abbildung 5.1 geht hervor, daß momentan genau ein RealtimeHost und ein Real- timePlugIn existieren. Die implementierenden Klassen sind Transport und LispRealtime- PlugIn. Transport ist der Motor des Echtzeit-Betriebs. Er ist ein spezieller Thread, der l¨auft, wenn der Play-Knopf der Transport-Palette gedruckt¨ wird. RealtimeConsumer k¨onnen sich bei ihm registrieren, so daß sie im Benachrichtigungs-Rhythmus mit neuen Informationen

46 5 Plug-In Schnittstellen

Klasse Request Rate Aktivit¨at Surface traj 30 Hz Nachfuhrung¨ der Transmitter Bewegungen MeterFrame sense 15 Hz Monitoring der Sensitivit¨aten TimelineFrame clock 30 Hz Animation der Zeitachsen-Positions-Linie TransportPalette clock 15 Hz Update des Zeitachsen-Positions-Textfeldes

Abbildung 5.3: RealtimeConsumer Profile versorgt werden. Die Genauigkeit der Uhr-Information in Java liegt bei einer Millisekunde. Die Methode Thread→sleep( long millis, int nanos ) kann benutzt werden, um den Thread fur¨ eine bestimmte Zahl zu pausieren. Die suggerierte Genauigkeit im Bereich von Nanosekunden ist jedoch uberhaupt¨ nicht gegeben. Selbst wenn eine Millisekunde lang ge- wartet wird, ist nicht garantiert, daß der Thread wirklich nach einer Millisekunde fortgesetzt wird. Deshalb wird im Transport-Kern ein Mechanismus benutzt, der laufend die aktuelle und die geforderte Rate vergleicht und entsprechend kurzer¨ oder l¨anger wartet. Der entste- hende Jitter ist optisch irrelevant und tangiert die externe Klangsynthese nicht, die Daten blockweise erh¨alt und ihren eigenen Scheduler hat.

Im Gegensatz zur Trajektorien-Filterung und Bounce-to-Disk gibt es im Echtzeit-Betrieb mehrere Consumer. Das bedarf einer Erl¨auterung: Im Klassen-Diagramm ist zu erkennen, daß LispRealtimePlugIn sowohl RealtimePlugIn als auch RealtimeConsumer implementiert. Worin besteht der Unterschied? Das Plug-In ist dafur¨ zust¨andig, mit externen Klangsynthese- Programmen zu kommunizieren. Das Interface beinhaltet Methoden zum Aktivieren und Deaktivieren des Plug-Ins, das heißt, es kann auf Bypass geschaltet werden. Der eigentliche Datenaustausch jedoch ist Teil des Consumer Interfaces. Neben dem Lisp Plug-In gibt es weitere Consumer in Meloncillo, die in Abbildung 5.3 gelistet sind.

Je nach Anwendung sind also unterschiedliche Datenraten gefragt. Die tabellierten Klassen sind alle Teil der graphischen Oberfl¨ache und ben¨otigen daher nur Raten, die einen optisch fließenden Eindruck vermitteln. Die verschiedenen Requests werden dynamisch verwaltet von einem Objekt, das eng mit Transport zusammenarbeitet, dem RealtimeProducer: Quelltext 5.3: RealtimeProducer.java (realtime package) public class RealtimeProducer implements LaterInvocationManager.Listener { [...] public RealtimeProducer.Source source; [...]

public void changeContext( RealtimeContext c ) { [...] } public void requestProduction( Span blockSpan, boolean even, long deadline ) { [...] } public void produceNow( Span blockSpan, boolean even ) { [...] } public void produceOffhand( long currentPos ) { [...] }

[...] }

Der RealtimeProducer produziert blockweise die geforderten Daten innerhalb des Event Threads. Eine neue Anfrage wird vom Transport durch Aufruf der requestProduction Me- thode gestellt. Der RealtimeProducer soll darin die Daten, die zur Zeitspanne blockSpan geh¨oren, produzieren. Um Dropouts zu vermeiden, darf er dafur¨ maximal deadline Milli-

47 5 Plug-In Schnittstellen

0 16 32 48 64 80 96 112 128 traj : 1/1 sense : 1/2

plugin sense read : 1/2 plugin notification : 1/8 surface traj read / timeline frame notif. : 1/16 transport palette notif. : 1/32

Abbildung 5.4: Realtime Datenstr¨ome sekunden ben¨otigen. Mit anderen Worten, der RealtimeProducer wird bereits im voraus beauftragt, einen neuen Block Daten zu generieren. Diese Daten sind in Arrays des source Objekts gespeichert. Die Consumer streichen im Clock-Rhythmus zirkul¨ar durch diese Puffer. Jedesmal, wenn die aktuelle Zeit den Puffer-Anfang oder die Puffer-Mitte uberschreitet,¨ wird die jeweils obsolete Puffer-H¨alfte, spezifiziert durch den even Parameter, aktualisiert.

Wenn der Transport gestartet wird, muß ein voller Block vorproduziert werden, dazu dient die Methode produceNow. Da die Oberfl¨ache auch auf manuelles Ziehen der Zeitachsen-Positions- Linie durch den Benutzer reagieren soll, ohne daß der Transport l¨auft, wurde die Methode produceOffhand eingefuhrt,¨ die nur ein einzelnes Zeitframe produziert. Wenn der Benut- zer die Session ver¨andert, zum Beispiel Receiver l¨oscht oder hinzufugt,¨ mussen¨ die Puffer neu angelegt werden. Dazu werden die Consumer kurzzeitig angehalten, der Kontext mittels changeContext aktualisiert, und ein neues Profil von allen Consumern angefordert.

Wie findet die Koordination zwischen mehreren gewunschten¨ Datenraten statt? Nehmen wir dazu an, daß neben den in Tabelle 5.3 aufgefuhrten¨ Consumern ein Lisp-Echtzeit-Plug-In l¨auft. Die Session habe eine Trajektorien-Datenrate von 500 Hz1. Nehmen wir an, das Plug- In steuert den SuperCollider-Synthesizer, dessen Controlrate ca. 690 Hz betr¨agt. Das Plug-In fordere aus Grunden¨ der CPU Belastung Sensitivit¨aten mit maximal 345 Hz an. Nehmen wir weiter an, ein voller Datenpuffer entspr¨ache etwa 1/4 Sekunde, n¨amlich 128 Frames. Dann ergibt sich ein Datenstrom-Produktions- und Konsumptions-Schema nach Abbildung 5.4.

Der RealtimeProducer produziert prinzipiell Trajektorien-Daten (traj ) mit voller Datenrate – also durchg¨angig alle 128 Frames eines Blocks –, da sie direkt von der Harddisk gelesen wer- den und eine Unterabtastung eher Rechenzeit vergeuden als sparen wurde.¨ Sensitivit¨ats-Daten (sense)werden nur produziert, wenn sie nachgefragt werden. Der einzige Request kommt vom Realtime Plug-In (345 Hz). Grunds¨atzlich mussen¨ die Faktoren der Unterabtastungen einer Zweierpotenz entsprechen, somit ergeben sich hier 250 Hz beziehungsweise eine Schrittwei- te von zwei Frames. Alle ungeraden Frame-Indices des Puffers werden ignoriert und haben keinen gultigen¨ Inhalt.

Der Transport sorgt dafur,¨ daß die Consumer mit der von ihnen angegebenen Rate benach- richtigt werden2. Auch hier gilt die Zweierpotenz-Regel, so daß sich die leicht ver¨anderten Frequenzen von 31.25 Hz bzw. 15.625 Hz ergeben. Im Falle von blockverarbeitenden Con-

1Die Voreinstellung betr¨agt 1 kHz. 2Notification, in der Abbildung mit notif.“ abgekurzt.¨ ”

48 5 Plug-In Schnittstellen sumern wie dem Plug-In ist die Benachrichtigungs-Rate in der Regel niedriger als die Rate der angeforderten Daten-Str¨ome. Im gezeigten Beispiel betr¨agt sie 1/8 der vollen Rate. Die Erkl¨arung dafur¨ wird im Abschnitt 5.4.3 in Zusammenhang mit der SuperCollider Anbindung geliefert.

5.3 Common Lisp fur¨ Java

Die Lisp-Plug-Ins sind weniger dafur¨ gedacht, direkte Manipulationen zum Beispiel der Tra- jektorien zu vollbringen, vielmehr sollen sie ein elastisches Bindeglied zu externen Klang- synthese Programmen sein. Aus diesem Grund wurde in einer fruhen¨ Version des Programms ein XML-Script zur Steuerung der externen Programme benutzt. XML erweist sich jedoch als unpraktisch, wenn programmiersprachliche Konstrukte wie Schleifen (do-while) oder Bedin- gungen (if-then-else) ben¨otigt werden. Diese h¨atten alle zu Fuß“ in den XML Interpreter ” eingebaut werden mussen.¨ Stattdessen wurde eine einfach strukturierte, kompakte, in Java integrierbare Interpreter-Sprache gesucht.

Die Wahl fiel auf Common Lisp: Die Syntax ist sehr uberschaubar¨ 3, mehrere algorithmische Musiksprachen basieren auf Lisp4, und es gibt mit Jatha eine einfache freie Implementation in Java. Micheal Hewett entwickelte Jatha uber¨ die letzten zehn Jahre, und es erweist sich als zuverl¨assig im Betrieb. Ein paar der Vorteile von Jatha:

• maximale rechtliche Freiheit durch GLPL Lizenz • kompakte Bibliothek (232 KB) • plattformunabh¨angig • Ausnutzung des automatischen Garbage-Collectors von Java • sehr einfache Konvertierung zwischen primitiven Lisp und Java Datentypen • neue Funktionen lassen sich durch einfache Java Klassen bereitstellen • neue Symbole k¨onnen von Java aus in das Environment eingefugt¨ werden • kann als reines API ohne eigene Console oder GUI verwendet werden

Die wesentlichen Nachteile sind die eher langsame Geschwindigkeit – trotz gegenteiliger Be- hauptungen des Autors – und der geringe Funktionsumfang. In der Selbstbeschreibung heißt es sehr zuruckhaltend,¨ Jatha implementiere a large part of the core of Common Lisp“5. Das ” bedeutet unter anderem, daß praktisch keine weitergehenden APIs eingebaut sind. Zum Bei- spiel gibt es keine Funktionen zum Lesen und Schreiben von Files. Auch Standard-Konzepte wie Streams, Arrays und Macros fehlen komplett. Im Rahmen der Anforderung als einfaches Scripting-Bindeglied wurden diese Nachteile in Kauf genommen.

3zur Sprache Common Lisp vgl. [Mayer 1995] 4z.B. OpenMusic und Common Music, RSC als SuperCollider Client in Scheme, sowie die Klangsynthese Sprache Common Lisp Music. 5http://jatha.sourceforge.net/doc/short-description.html

49 5 Plug-In Schnittstellen

5.3.1 Die LispPlugIn Klasse

Oberklasse fur¨ alle Lisp basierten Plug-Ins ist die Klasse LispPlugIn.

• Sie stellt eine standardisierte Oberfl¨ache bereit, die eine Auswahl-Box fur¨ die konkreten Lisp Scripte (Sourcecodes) enth¨alt und die M¨oglichkeit bietet, GUI Elemente darzu- stellen, die direkt von den Scripten erzeugt werden (vgl. Abb. 5.2 rechts). • Sie verwaltet die Jatha Umgebung und stellt zus¨atzliche Funktionen und Symbole zur Verfugung.¨ • Sie stellt die Methode executeLisp zur Verfugung,¨ mit der zur Renderzeit beliebige im Script definierte Funktionen ausgefuhrt¨ werden k¨onnen.

Die Namen dieser Funktionen h¨angen vom Plug-In Typ ab. Fur¨ die Filterung von Trajek- torien werden in Analogie zum RenderPlugIn Interface (Quellcode 5.1) die benutzerdefi- nierten Lisp Funktionen prepare, render und cleanup ausgefuhrt.¨ prepare erm¨oglicht dem Script, grundlegende Initialisierungen durchzufuhren¨ und Requests anzumelden. render wird im Gegensatz zu RenderPlugIn→producerRender() nur einmal ausgefuhrt.¨ Dies geschieht, nachdem die angeforderten Datenstr¨ome in Form von tempor¨aren Dateien bereitgestellt wurden, so daß hier ublicherweise¨ der Aufruf des externen Klangsynthese-Programms, z.B. CSound, erfolgen kann. Aufr¨aumarbeiten wie das Schließen oder L¨oschen von Dateien werden in der cleanup Funktion erledigt.

Die zus¨atzlich von Meloncillo bereitgestellten Lisp Funktionen beinhalten unter anderem:

• Offnen¨ von Audio-Dateien (AIFF, IRCAM oder AU Format) • Allokation und Beschreiben von Byte-Puffern (als Ersatz fur¨ den fehlenden Vector- Datentyp) • Offnen¨ und Beschreiben von Dateien • Erweiterte String-Operationen wie Formatierung von Zahlen und Pattern Matching mit Regul¨aren Ausdrucken¨ • Versenden von UDP Datagrammen (vgl. Abschnitt 5.4.2) • Generierung von OSC Paketen (vgl. Abschnitt 5.4.2) • Festlegung von Quelldaten und Zieldaten Requests (d.h. welche Trajektorien- und Sen- sitivit¨atsdaten ben¨otigt und zuruckgeliefert¨ werden) • Ausfuhren¨ von externen Programmen • Erzeugen von GUI Elementen

Die GUI Elemente dienen dazu, dem Benutzer die wichtigsten Script Parameter in Form von Checkboxes und Textfeldern zu pr¨asentieren, ohne daß dieser fur¨ jede Session separate Script-Dateien editieren muß. GUI Elemente werden in der speziellen Funktion create-gui definiert.

Das Script erh¨alt außerdem ein Dictionary6, das die wichtigsten statischen Parameter enth¨alt. Hier kann das Script nachschlagen, wieviele Transmitter und Receiver beim Rendern beteiligt sind, was ihre Namen sind usw., wie hoch die Datenrate ist und welche Werte die Plug-In

6in Form des speziellen Lisp-Datentyps LispHashTable

50 5 Plug-In Schnittstellen relevanten Preferences-Settings haben, etwa die voreingestellte Audio-Rate und der vorein- gestellte Pfad zur CSound Applikation.

5.3.2 Ein Beispielscript

W¨ahrend die Besonderheiten fur¨ Echtzeit-Scripte im folgenden Abschnitt erl¨autert werden, wird hier das Beispiel einer Trajektorien Filterung mit CSound durchgegangen. Nehmen wir an, CSound soll die Trajektorien tiefpaßfiltern, so daß die Transmitter-Bewegungen weniger hektisch und dafur¨ flussiger¨ werden.7 Das Lisp Script ist in der Datei "csfl-smooth.lisp" gespeichert. Wenn es im Filter Dialog ausgew¨ahlt wird (Abb. 5.2 rechts), wird der Quell- text geladen und ubersetzt.¨ Anschließend wird die Funktion create-gui ausgefuhrt,¨ die ein numerisches Eingabefeld fur¨ die Filter-Frequenz erzeugt:

(defun create−gui NIL (progn (gadget−make NIL "LABEL" ’(1 1) "Cutoff Frequency" NIL) (gadget−make filter−freq "NUMBER" ’(2 1) 1.0 (list "Hz" 0.0 1000.0 0.01)) T ; success ) )

Der erste gadget-make Befehl erzeugt die Beschriftung. Die Argumente fur¨ gadget-make sind (1) ein Lisp-Symbol, das stets den aktuellen Wert des GUI-Elements – in diesem Fall die Frequenz – enth¨alt, (2) der Gadget-Typ, (3) die Position des Gadget auf der Oberfl¨ache, (4) der voreingestellte Wert, (5) spezifische Optionen – hier die physikalische Einheit der Werte und die erlaubten Minimum- und Maximum-Werte. Die Funktion liefert T (wahr) zuruck¨ um zu signalisieren, daß keine Fehler aufgetreten sind.

Durch Klick auf den Process-Knopf wird die Filterung gestartet. Ein RenderContext der gerade ausgew¨ahlten Transmitter und des Zeitausschnitts wird erstellt. Die Lisp-Funktion prepare wird ausgefuhrt:¨

(defun prepare NIL (progn (setq colltrns (gethash "TRANSMITTERS" cillo)) (setq numtrns (length colltrns)) (setq prefs (gethash "PREFERENCES" cillo)) (setq timeline (gethash "TIMELINE" cillo)) (setq duration (− (gethash "STOP" timeline) (gethash "START" timeline))) (setq sense−rate (gethash "SENSERATE" prefs))

(setq trnsidx 0) (trnsiter ’(progn (let ((trns (elt colltrns trnsidx)) (bufidx trnsidx) (temp−input−file (temp−file−make)) (temp−output−file (temp−file−make)))

(audio−file−open bufidx temp−input−file "raw" "float32" sense−rate 2) (source−request "TRAJ" trnsidx bufidx) (target−request "TRAJ" trnsidx temp−output−file)

7Der Einfachheit halber wird die Ausfuhrung¨ weiter im Indikativ geschrieben.

51 5 Plug-In Schnittstellen

(setf−gethash "INPUT−FILE" trns temp−input−file) (setf−gethash "OUTPUT−FILE" trns temp−output−file) ) )) T ; success ) )

Mit der Funktion gethash werden der RenderContext und die Programm-Preferences aus- gelesen. Die Hashtable cillo wird als globales Symbol von LispPlugIn erzeugt. Die Liste der Transmitter colltrns, die Zahl der Transmitter numtrns, die L¨ange des Zeitausschnitts duration und die Datenrate sense-rate werden ermittelt. In einer Schleife8 wird fur¨ je- den Transmitter eine Eingabe- und Ausgabe-Datei im tempor¨aren Verzeichnis erzeugt. Mit audio-file-open wird das Eingabeformat festgelegt, hier eine raw“9 Datei fur¨ 32bit Floa- ” ting-Point Samples und zwei Kan¨ale. Diese Datei wird uber¨ den Identifier bufidx als Ziel fur¨ die Quelldaten bestimmt (source-request). Dem Lisp-Plug-In wird mitgeteilt, daß die Zieldaten in einer Datei temp-output-file zu erwarten sind. Fur¨ die sp¨atere Verwendung in der render Funktion werden die Dateinamen in der Hashtable gespeichert, die fur¨ jeden Transmitter existiert.

Nachdem die Funktion zuruckkehrt,¨ arbeitet das Lisp-Plug-In die Requests ab und schreibt die angeforderten Trajektorien-Daten in die tempor¨aren Dateien. Anschließend ruft es die Script Funktion render auf:

(defun render NIL (progn (setq trnsidx 0) (setq return−code 0) (trnsiter ’(progn (let ((trns (elt colltrns trnsidx)) (bufidx trnsidx) (csd−file (temp−file−make ".csd")))

(file−close bufidx) ; close traj data files

; −−−− create CSound unified Orc/Sco file −−−− (file−open 1977 csd−file "w") (file−write 1977 (concat "\\n\\n" "nchnls = 2\\n" "#include \"smooth.orc\"\\n" "\\n\\n" "i88 0 " duration "\\n" "i14 0 " duration " \""(gethash "INPUT−FILE" trns) "\" " filter−freq "\\n" "\\n\\n" )) (file−close 1977)

; −−−− launch csound −−−− (let ((exec−args (list (gethash "CSOUNDAPP" prefs) "−A" "−3" "−o" (gethash "OUTPUT−FILE" trns) "−r" sense−rate "−k" sense−rate csd−file)))

8Mangels einer Iterations-Funktion in Jatha wurde dafur¨ eine hier nicht abgedruckte rekursive Funktion trnsiter definiert, die die Variable trnsidx von 0 bis numtrns - 1 hochz¨ahlt. 9D.h. ohne Header – headerless – nur aus den Audio-Frames bestehend

52 5 Plug-In Schnittstellen

(println (concat "\\n∗∗∗∗∗ Transmitter \"" (gethash "NAME" trns) "\" executing:\\n" (concat−args exec−args))) (setq return−code (execute parse−cs−output exec−args NIL (car (path−split csd−file)))) (println (concat "Exited with return code " return−code)) (if (not (eql return−code 0)) (setq trnsidx numtrns) NIL) ) ) )) (eql return−code 0) ; success if return code is 0 ) )

Da CSound sich etwas schwierig tut, mehrkanalige Dateien zu schreiben, ruft das Script CSound jeweils getrennt fur¨ die einzelnen Transmitter auf; in jedem Durchgang der Iteration wird eine Text-Datei ge¨offnet (file-open), in der die CSound Score generiert wird. Das Script bindet das bereits auf der Harddisk gespeicherte Orchestra-File "smooth.orc" ein (siehe Quelltext 5.4) und schreibt zwei Instrumenten-Aufrufe: i88 und i14. Instrument 88 ist ein Hilfsinstrument, daß in Intervallen den Processing-Fortschritt in die Console schreibt. Instru- ment 14 liest die Trajektorien ein, filtert sie mit einem reson Unit-Generator der gew¨ahlten Frequenz und schreibt das Ergebnis in das CSound Ausgabefile.

CSound selbst wird durch die Lisp-Funktion execute gestartet. Der Pfad zu CSound wird durch Auslesen des Preferences-Feldes CSOUNDAPP ermittelt. Das erste Argument von execute ist eine Callback-Funktion im Script, die die Console-Ausgabe des ausgefuhrten¨ Programmes auswertet. Sie leitet diese Console-Ausgabe einfach mittels println in die Console von Melon- cillo um und filtert die von Instrument 88 generierten Strings heraus, um stattdessen mit progression-set die Fortschritts-Anzeige von Meloncillo zu aktualisieren:

(defun parse−cs−output (textline) (if (and (eql 10 (length textline)) (eql "CILLO "(substring textline 0 6))) (progression−set (car (format−parse "{0,number}"(substring textline 6 10)))) ; else (println textline) ) )

Nachdem alle execute Befehle ausgefuhrt¨ wurden, kehrt die Funktion render zuruck.¨ Das Lisp-Plug-In kopiert nun die von CSound generierten neuen Trajektorien-Dateien zuruck¨ in die Session und ruft abschließend die Script-Funktion cleanup auf. Quelltext 5.4: smooth.orc ; read a transmitter path and write its lowpass ; filtered transformation back to the output file ; p4 = traj input path; p5 = cutoff frequency [Hz] instr 14 ; bug in CSound 4.23f11 −− channels are swapped aty atx diskin p4, 1, 0, 0, 6 ; path, pitch, offset, wrap, format aoutx reson atx, 0, p5, 1 aouty reson aty, 0, p5, 1 outch 1, aoutx outch 2, aouty endin

53 5 Plug-In Schnittstellen

; print progress information every 2 seconds instr 88 iweight = 1.0 / p3 kschoko times printks "CILLO %.2f\\n", 2, kschoko ∗ iweight endin

5.4 Open Sound Control

Open Sound Control (OSC) wurde am CNMAT in Berkeley von Matt Wright und Adrian Freed entwickelt. Es ist als Kommunikationsprotokoll gedacht, mit dem sich Computer und Computeranwendungen, insbesondere Multimedia-Hardware und -Software verst¨andigen k¨on- nen. Das Grundkonzept wurde von den Autoren auf der ICMC 1997 vorgestellt.10 Nachdem der Boom im Bereich von Software-Synthesizern begonnen hatte und neue schnelle Computer- Schnittstellen wie Firewire und USB sich durchzusetzen begannen, stellte sich die Frage, wie voneinander getrennte Komponenten ihre Daten austauschen sollten. Die Musikinstrumente- Industrie (Yamaha) hatte bereits vorgeschlagen, auf dem etablierten MIDI Standard aufzu- bauen. OSC hingegen versucht, die offensichtlichen Beschr¨ankungen des damals 14-j¨ahrigen MIDI Standards zu umgehen: MIDI ist unskalierbar – der Befehlssatz ist festgelegt und uberdies¨ hochproblematisch11 –, hat eine viel zu geringe Datenrate (31.25 kbs), kennt nur eine beschr¨ankte Zahl von Adressaten (MIDI-Kan¨ale) und kann praktisch keine zwei Befehle gleichzeitig ausfuhren.¨

5.4.1 Protokollubersicht¨

In der Erkenntnis, daß Transport-Protokolle und Hardware-Interfaces sich schneller ¨andern k¨onnen als ein Musik-Kommunikations-Protokoll, wurde OSC transportunabh¨angig definiert. Es ist jedoch an die Erfordernisse von Netzwerk-Transport wie UDP angepaßt und geht von einer Paket (Datagramm) Struktur aus. OSC Befehle sind in einem OSC-Paket verpackt,12 das leicht als UDP-Datagramm versandt werden kann. Zwei Typen von OSC-Paketen werden unterschieden: Messages und Bundles. Bundles gruppieren synchron auszufuhrende¨ Messa- ges oder weitere Bundles in einem einzelnen Paket. Sie beginnen mit dem speziellen String "#bundle" gefolgt von einem sogenannten Time-Tag, das den Zeitpunkt beschreibt, zu dem die enthaltenen Messages auszufuhren¨ sind.13

Eine Message enth¨alt den eigentlichen Befehl. Sie besteht aus einem URL-¨ahnlichen symbo- lischen Adreß-String und einer beliebigen Zahl von bin¨ar kodierten Argumenten. Die symbo- lische Message-Adresse wird vom Empf¨anger ausgewertet, in einer objekt-orientierten Umge- bung ublicherweise¨ von links nach rechts hierarchisch absteigend, so daß eine Adresse wie

10[Wright/Freed 1997] 11Dazu z¨ahlt die ideologische Festlegung auf Tasteninstrumente mit 127 Halbtonschritten; naturlich¨ ist MIDI anders interpretierbar, aber die Umdefinierung von Controller-Changes oder das Hantieren mit SysEx- Befehlen kann nur als Notbehelf betrachtet werden. 12Die aktuellen Spezifikationen sind unter der Adresse http://www.cnmat.berkeley.edu/OpenSoundControl/ OSC-spec.html zu finden. 13Die zwei oder mehreren kommunizierenden Objekte sind dafur¨ verantwortlich, daß sie auf dieselbe System- Zeit zugreifen. Innerhalb desselben Computers ist dies automatisch gegeben, in einem Netzwerk mussen¨ sich die Systeme ggf. per Network-Time-Protocol (NTP) prufen¨ an einer Netzwerk-Uhr orientieren.

54 5 Plug-In Schnittstellen z.B. "/synth/oscillators/sawtooth/set-frequency" zuerst an das Synthesizer-Objekt geschickt wird, das sie an die Oszillator-Sektion weitergibt, die wiederum an den S¨agezahn- Generator, der dann den Befehl zum Andern¨ der Frequenz ausfuhrt.¨ Im Gegensatz zu MIDI kann sich der Adreß-Raum grunds¨atzlich dynamisch ver¨andern. Das ursprungliche¨ OSC Pro- tokoll sieht folgende spezielle Message-Adressen vor:

• Wildcards wie ’*’ oder ’?’, die es erlauben, eine Nachricht an mehrere Adressaten zu verschicken, deren Adressen auf das Wildcard Pattern passen • Objekt-spezifische Informations-Anfragen, die durch Zurucksenden¨ einer Nachricht be- antwortet werden14 • Anfragen zum Adreß-Raum, d.h. zu den verfugbaren¨ Unteradressen eines Objekts • Anfragen zu den erwarteten Argumenten und Daten-Typen eines Befehls • Eine "/documentation" Anfrage, die einen Text zuruckliefern¨ soll, der vom Benutzer gelesen werden kann • Eine "/current-value" Anfrage, die den aktuellen Parameter-Wert (etwa die Oszillator- Frequenz im obigen Beispiel) zuruckliefern¨ soll

Sechs Jahre nach Einfuhrung¨ von OSC gibt es bereits zahlreiche OSC-Implementationen. Der Umfang, in dem Time-Tags, Pattern-Matching und die speziellen Messages unterstutzt¨ werden, variiert jedoch erheblich. Eine klarere Rollen-Teilung der kommunizierenden Objekte wird in den Ausdrucken¨ OSC-Server und OSC-Client deutlich.15 Im Client/Server-Modell stellt der Server Dienste zur Verfugung,¨ ein oder mehrere Clients benutzen diese Dienste, die Kommunikation verl¨auft uberwiegend¨ in Richtung Server, der gegebenenfalls Antwort- Nachrichten zuruckschickt.¨

Das CNMAT fuhrt¨ eine Liste an Applikationen, die OSC unterstutzen,¨ 16 sie ist allerdings unvollst¨andig und zum Teil obsolet. Zu den Musik- und Klang-Programmen z¨ahlen Super- Collider, Max/MSP, PD, jMax, OpenMusic, RTcmix und Siren. Im Bereich Multimedia sind OSC-Anbindungen an Macromedia Flash (flosc) und Director (OSCar) zu nennen. Am IRCAM wurde mit EtherSense ein Sensor-Ger¨at fur¨ Live-Performances entwickelt, das direkt OSC uber¨ Ethernet an einen Computer ubertr¨ ¨agt. Das vom CNMAT herausgegebene OSC- Kit, eine OSC-Bibliothek in C, wurde in weitere Sprachen wie Java, Objective-C, Common Lisp und Ruby ubertragen.¨

In der Implementation von OSC in James McCartneys SuperCollider wurde eine entschei- dende Erweiterung des Protokolls vorgenommen, die sich ubergreifend¨ durchgesetzt hat: Die wenigsten Implementationen unterstutzen¨ derzeit das Type-Querying, also das Abfragen der Daten-Typen fur¨ Message-Parameter. In der Praxis ist dem Client oder Anwender bereits bekannt, wie die Messages eines Servers aufgebaut sind. Auf der Server-Seite wiederum muß ein allgemeines OSC-Empfangs-Objekt in der Lage sein, die Message-Argumente korrekt zu dekodieren, bevor sie vom eigentlichen Adressaten weiterverarbeitet werden.17 Daher wurde der Type-Tag-String in OSC-Messages eingefuhrt.¨ Er stellt das erste Argument jeder Message

14Der Sender wird nicht direkt in der Message vermerkt, kann jedoch normalerweise vom Transport-Layer erfragt werden. UDP Datagramme enthalten z.B. eine Return-Adresse. 15vgl. [Wright et al. 2003]. Die Ausdrucke¨ sind offenkundig von SuperCollider 3 ubernommen.¨ 16http://www.cnmat.berkeley.edu/OpenSoundControl/ 17Das Max-External OpenSoundControl zum Beispiel generiert eine Liste mit Max-Primitives aus den empfan- genen OSC-Nachrichten; diese wird dann normalerweise uber¨ OSC-route an die Adressaten verteilt. Ohne Type-Tags kann OpenSoundControl also nur raten“, welche Daten-Typen gemeint sind. ”

55 5 Plug-In Schnittstellen dar und besteht aus einem Komma-Charakter gefolgt von einer Kette von Type-Charakteren, die den Daten-Typ aller Argumente angeben. Die wichtigsten Typen sind ’i’ fur¨ 32bit lineare ganze Zahlen, ’f’ fur¨ 32bit Floating-Point Zahlen, ’s’ fur¨ Strings oder Symbole und ’b’ fur¨ den sogenannten ’Blob’, einen bin¨aren Datenblock. Type-Tags machen komplizierte Argument- Prufung¨ und Heuristiken uberfl¨ ussig.¨

5.4.2 Implementierung in Meloncillo

Die eigentlichen OSC-Klassen von Meloncillo befinden sich im Paket net. Es sind

• OSCPacket : Superclass von Messages und Bundles, die Methoden zum En- und Deko- dieren von Paketen enth¨alt • OSCMessage : Die Message Klasse, die Java-Primitives in Bin¨arform kodiert bzw. aus der bin¨aren empfangenen Nachricht dekodiert • OSCBundle : Die Bundle Klasse. Messages und Bundles werden zun¨achst einzeln hin- zugefugt¨ und anschließend in Bin¨arform kodiert. Neben den normalen absoluten Time- Tags des OSC Standards werden die relativen Time-Tags des SuperCollider NonReal- Time-Modus (NRT) unterstutzt¨ • OSCReceiver : Objekte dieser Klasse k¨onnen in einem eigenen Thread auf das Eintreffen von Nachrichten warten • OSCListener : Listener fur¨ einen OSCReceiver, der beim Empfang von Nachrichten informiert wird • OSCException : Klasse fur¨ OSC-bezogene Fehler

W¨ahrend sich die Klassen zun¨achst an die bereits existente Java-Bibliothek JavaOSC18 an- lehnten, wurden sie aus Grunden¨ der Effizienz und etwas umst¨andlichen Art von JavaOSC neu programmiert und auf die n¨otigsten Elemente beschr¨ankt. Sie unterstutzen¨ momentan kein Pattern-Matching19 und keine mit Brackets (’[’, ’]’) getypten Arrays20, außerdem gibt es keinen separaten Dispatcher. Stattdessen wird mit entsprechenden Methoden der java.net und java.nio Pakete einfach ein DatagramChannel ge¨offnet, die zu versendenden Pakete in einen ByteBuffer kodiert (dies erledigt OSCPacket) und mit write in den DatagramChannel geschickt.

Im Paket lisp existieren die Wrapper-Klassen OSCBundleSendPrimitive und OSCBundle- SendAndWaitPrimitive. Sie stehen den Lisp Scripten zur Verfugung.¨ W¨ahrend die erste Funktion ein OSC-Bundle asynchron verschickt, wartet die zweite Funktion nach dem Ver- sand fur¨ eine angegebene Zeit auf eine bestimmte Ruckmeldung.¨ Konkrete Beispiele fur¨ den Gebrauch von OSC-Messages in Lisp werden im Abschnitt 5.4.3 gezeigt.

18http://www.mat.ucsb.edu/~c.ramakr/illposed/javaosc.html 19Dies macht nur fur¨ OSC-Server Sinn. Ein Client-Listener kann jedoch auf die m¨achtigen Funktionen von java.util.regex zuruckgreifen.¨ Den gegenw¨artigen Diskussionen des Forums [email protected] kann daruber¨ hinaus entnommen werden, daß sich das Pattern-Konzept in zukunftigen¨ OSC Versionen voraussichtlich ¨andern wird. 20Dies auch vor dem Hintergrund, daß sclang ebenfalls keine Brackets benutzt, sondern Arrays einfach direkt in die einzelnen Elemente aufl¨ost.

56 5 Plug-In Schnittstellen

5.4.3 Anbindung an SuperCollider

SuperCollider is an environment for real time audio synthesis which runs on a ” Power Macintosh with no additional hardware“ [McCartney 1996]

Diese knappe Beschreibung der ersten Version von SuperCollider aus dem Jahre 1996 trifft im wesentlichen noch fur¨ Version 3 zu, obwohl das Programm konzeptuell einige Anderungen¨ erfahren hat.21 W¨ahrend SuperCollider 1 gerade aus der Fusion zweier Vorl¨auferprogramme hervorging, einer Klangsynthese-Sprache (Synth-O-Matic) und einer Interpreter-Umgebung fur¨ Max (Pyrite), besteht der wesentliche Unterschied von Version 3 zu Version 2 darin, daß es sich eigentlich wieder um zwei unabh¨angige Programme handelt, die SuperCollider Lan- guage Application (kurz sclang) und die SuperCollider Synthesis Engine (kurz scsynth). sclang bietet eine auf der Sprache SmallTalk basierende Programmierumgebung, die zur Klanggenerierung mit scsynth uber¨ OSC kommuniziert. scsynth hat grunds¨atzlich nichts mit SmallTalk oder uberhaupt¨ einer h¨oheren Sprache zu tun. Der einfache Befehlssatz, der aus ca. 50 einzelnen Kommandos eines flachen Adreßraums besteht22, und die Effizienz der DSP Algorithmen pr¨adestinieren scsynth dazu, von Frontends verschiedenster Art als reine Rechenmaschine verwendet zu werden, mit der der Anwender nicht direkt etwas zu tun be- kommt. In dieser Konstellation wird SuperCollider als Server und die Steueranwendung als Client bezeichnet.

Ein Beispiel fur¨ einen SuperCollider Client ist die in einer Fußnote in Abschnitt 4.1 erw¨ahnte Scream Umgebung bzw. die damit erstellte Applikation AmbiGranusampler. Ein weiteres Bei- spiel ist der dort ebenfalls kurz dargestellte Sonificator, der ¨ahnlich wie Scream als Programm- Schnittstelle (API) fur¨ Audio-Patches konzipiert ist, auf der lightweight Java Applikationen aufsetzen k¨onnen.

Da Meloncillo fast nichts von SuperCollider weiß – dies liegt in der Obhut der Scripte –, l¨aßt sich prinzipiell auch sclang als Server benutzen, wodurch komplexere algorithmische Verfahren m¨oglich sind. Der Einfachheit halber wird jedoch nur ein Beispiel fur¨ die direkte Kommunikation mit scsynth dargestellt. Im Gegensatz zu sclang wurde der Synth Server bereits auf andere Plattformen portiert und kann unter Mac OS X, Linux i386, Linux PPC und Win32 benutzt werden. Da Meloncillo die OSC Messages uber¨ UDP an SuperCollider versendet, kann SuperCollider auch auf einem anderen Rechner als Meloncillo laufen, wenn diese Rechner uber¨ ein LAN verbunden sind. Die Synchronisation der Uhren beider Rechner ist hingegen noch ungel¨ost (vgl. Abschnitt 6.2).

SuperCollider kann sowohl in Echtzeit, als auch in einem speziellen NonRealTime-Modus (NRT) gestartet werden. Mit wenigen Anpassungen lassen sich die Lisp Scripte und Super- Collider Patches gleichzeitig fur¨ Realtime-Synthese und Bounce-to-Disk verwenden, da Super- Collider im NRT Modus weiterhin uber¨ OSC gesteuert wird. Die OSC-Bundles werden dabei sequentiell aus einer Datei gelesen, statt sie in Echtzeit zu empfangen.

21siehe dazu [McCartney 2002] 22Deren Zahl halbiert sich etwa, wenn man eng verwandte Befehle zusammenfaßt, wie /b_set und /b_setn fur¨ das Beschreiben eines Puffers. Flacher Adreßraum bedeutet, daß Kommandos nicht hierarchisch geschach- telt und durch Schr¨agstriche getrennt werden, also ein Puffer beispielsweise direkt mit "/b_free 789" statt "/buffer/789/free" freigegeben wird.

57 5 Plug-In Schnittstellen

Root Node

numTrns = Zahl der Transmitter (5) numRcv = Zahl der Receiver (4) Master Group

Input Group Mix Group

Phasor Synth

Control−Bus

Vektor aus Input Synths Matrix aus Mix Synths Audio−File Buffer Audio−Bus 1

− Audio−File Buffer Audio−Bus

Audio−File Buffer Audio−Bus

Audio−File Buffer Audio−Bus 0...numTrns

Audio−File Buffer Audio−Bus

Sense−Buf Sense−Buf Sense−Buf Sense−Buf Audio Audio Audio Audio

Sense−Buf Sense−Buf Sense−Buf Sense−Buf − − − − Hardware Hardware Hardware Hardware Sense−Buf Sense−Buf Sense−Buf Sense−Buf

Sense−Buf Sense−Buf Sense−Buf Sense−Buf − − − − Sense−Buf Sense−Buf Sense−Buf Sense−Buf Output Output Output Output

Matrix aus Sensitivitäts−Puffern

0...numRcv−1

Abbildung 5.5: Nodes, Busse und Buffer fur¨ einen Amplituden-Mixer in SuperCollider

Beispiel eines einfachen Amplituden-Pannings scsynth verwaltet in gewisser Analogie zum MUSIC V Konzept Synthesizer, die aus Unit- Generatoren bestehen. Ein solcher durch eine UGen-Graph-Function beschriebener Synthe- sizer ist ein Knoten-Punkt in einem hierarchischen Baum, den scsynth verwaltet. Neben Synth-Nodes gibt es Group-Nodes, die mehrere Synthesizer oder Gruppen zusammenfassen. Eine Gruppe ist eine Liste aus Knoten. Neue Knoten werden entweder an den Anfang oder das Ende der Liste gesetzt. Innerhalb einer Gruppe werden die Knoten in der Reihenfol- ge ihrer Position in der Liste abgearbeitet. Die Reihenfolge ist entscheidend beim Entwurf eines Patches – wird zum Beispiel ein Soundfile eingelesen (Input-Knoten) und auf einen Bus geschickt, auf den ein Mixer zugreifen soll (Mix-Knoten), so muß der Input-Knoten vor dem Mix-Knoten ausgefuhrt¨ werden. In den OSC Messages werden Synthesizer und Gruppen durch eine eindeutige ganze Zahl, die Node-ID, angesprochen, die jedoch keinen Einfluß auf die Reihenfolge der Abarbeitung hat.

58 5 Plug-In Schnittstellen

Ebenfalls klassisch in SuperCollider ist die Trennung zwischen Controlrate- und Audiorate- Signalen. Diese laufen uber¨ ein globales Bussystem, was vor allem hinsichtlich der Audio- Daten den Vorteil hat, daß beliebig viele Synthesizer aus einem Audio-Bus lesen oder in einem Audio-Bus zusammengemischt werden k¨onnen. Neben Bussen gibt es Puffer, die intern oder per OSC blockweise beschrieben werden k¨onnen.

Um einen einfachen Matrix-Mixer nach dem Amplituden-Panning Prinzip zu realisieren, wer- den Gruppen und Synthesizer nach dem in Abbildung 5.5 dargestellten Schema kreiert. Drei verschiedene Synthesizer kommen zum Einsatz, die in sclang programmiert wurden:

Quelltext 5.5: synthdef-sources.sc // reads input from sound file // and writes it to an audio bus SynthDef( "cillo−input", { arg i aInBuf, i aOutBus, i gain = 1.0;

Out.ar( bus: i aOutBus, channelsArray: DiskIn.ar( numChannels: 1, bufnum: i aInBuf ) ∗ i gain ); }).writeDefFile( p );

// mixing pipe taking an input audio // bus, a control buf for amplitude // modulation and an audio output bus SynthDef( "cillo−mix", { arg i aInBus, i aOutBus, i kInBuf, i kPhasorBus;

Out.ar( bus: i aOutBus, channelsArray: In.ar( bus: i aInBus ) ∗ BufRd.kr( numChannels: 1, bufnum: i kInBuf, phase: In.kr( bus: i kPhasorBus ))); }).writeDefFile( p );

// one phasor object represents something // like a synchronized motor for all // control rate amplitude buffer reads. // a trigger is fired twice per buffer cycle SynthDef( "cillo−phasor", { arg i rate, i bufSize, i kPhasorBus; var clockTrig, phasorTrig, clockRate, phasorRate, controlRate;

controlRate = SampleRate.ir / 64; phasorRate = i rate / controlRate; clockRate = 2 ∗ i rate / i bufSize; clockTrig = Impulse.kr( freq: clockRate ); phasorTrig = PulseDivider.kr( trig: clockTrig, div: 2, start: 1 );

SendTrig.kr( in: clockTrig, id: 0, value: PulseCount.kr( trig: clockTrig )); Out.kr( bus: i kPhasorBus, channelsArray: Phasor.kr( trig: phasorTrig, rate: phasorRate, start: 0, end: i bufSize )); }).writeDefFile( p )

cillo-input liest mit dem DiskIn UGen ein Soundfile ein und schreibt es auf einen Bus, cillo-mix mischt einen Eingangsbus (Soundfile) auf einen Ausgangsbus (Soundkarten-Aus- gang). Die Lautst¨arke wird aus Puffern gelesen, die blockweise mit dem OSC Befehl "/b_setn" von Meloncillo gefullt¨ werden. Der Phasor-Synthesizer generiert ein S¨agezahn-Signal, das diese Puffer zyklisch abtastet. Die Instantiierung der Gruppen und Synthesizer erfolgt vom Lisp-Script aus mit der osc-bundle-send[-and-wait] Funktion. Hier ein Beispiel:

59 5 Plug-In Schnittstellen

(datagram−channel−open 1977 "localhost" 57110) (if (null (osc−bundle−send−and−wait 1977 0.0 (list (list "/g new" master−group 1 0 input−group 0 master−group mix−group 1 master−group) (list "/d load" synthdefs)) "/done" 2000 )) (println "TIMEOUT! group creation, definition load") ; else NIL )

1977 ist der Identifier fur¨ den in der ersten Zeile ge¨offneten Datagramm-Kanal. Das Bundle enth¨alt die zwei Messages "/g_new" zur Erzeugung der Gruppen-Knoten und "/d_load" zum Einlesen der Synthesizer-Definitionen aus einer Festplatten-Datei. Die letzten beiden Argu- mente der OSC-Funktion legen fest, daß maximal zwei Sekunden auf die Antwort-Nachricht "/done" gewartet werden soll. Die Funktion liefert diese Antwort-Nachricht zuruck¨ oder NIL, wenn innerhalb dieser Zeitspanne nicht geantwortet wurde.

W¨ahrend der Realtime Modus aktiv ist, werden die Transport-Befehle an das Lisp-Script weitergegeben. Es muß dafur¨ die Funktionen position, play und stop definieren. Aus Performance-Grunden¨ wird das Script nicht damit beauftragt, kontinuierlich OSC-Nachrichten zum Auffullen¨ der Sense-Puffer zu erzeugen. Stattdessen ubergibt¨ es der im Realtime-Modus etwas modifizierten source-request Funktion einen vorher mit dem Skelett der OSC-Message ("/b_setn") initialisierten Byte-Buffer und eine Liste von Anweisungen, die auf diesem Puffer ausgefuhrt¨ werden sollen:

(source−request "SENSE" (cons trnsidx rcvidx) 1978 (list (list "INT" bufidx msgbuf−off) (list "VAR" "BUFOFF" (+ msgbuf−off 4)) (list "STREAM" (+ msgbuf−off 12)) (list "SEND" 1977) ))

1978 ist der Identifier des Byte-Buffers, in den die Nachricht kodiert wird. Die Befehlsliste be- wirkt, daß der (SuperCollider-)Puffer-Index und der Puffer-Lese-Index jeweils ersetzt und die Sensitivit¨atsdaten ("STREAM") ubertragen¨ werden, bevor die Nachricht an den Datagramm- Kanal mit dem Identifier 1977 versandt wird.

Meloncillo kennt daruber¨ hinaus einen speziellen Sync-Befehl23: Der Phasor in Quelltext 5.5 sendet zweimal pro Durchlauf mit dem SendTrig UGen eine OSC-Nachricht "/tr" an Meloncillo. Dadurch wird der Versand neuer Sensitivit¨ats-Puffer ausgel¨ost. Wurde¨ Meloncillo nach seiner internen Uhr die Puffer versenden, k¨onnten diese manchmal zu fruh¨ ankommen. Neue Trigger-Befehle werden mehrfach pro Puffer-Periode ausgewertet, dies ist der Grund fur¨ die spezielle Notification-Rate in Abbildung 5.4. Gleichzeitig kann das Programm uberpr¨ ufen,¨ ob Drop-Outs aufgetreten sind und meldet dies dem Benutzer. Fur¨ eine zukunftige¨ Version wird gepruft,¨ ob sich die Synchronisierung einfacher durch die Time-Tags der Bundles l¨osen l¨aßt.

Das Script und die SynthDefs k¨onnen als Ausgangspunkt dienen, mit neuen Synthese-Modellen zu experimentieren. Die Input-Synths k¨onnten zum Beispiel durch Live-Inputs ersetzt wer-

23(target-request "SYNC" 0 )

60 5 Plug-In Schnittstellen den24, zwischen die Input- und Mix-Stufe kann eine Filter, (Doppler-)Delay oder Verzerrer- Einheit gesetzt werden. Die Mix-Stufe selbst kann modifiziert werden, oder ihre Ausg¨ange auf weitere Busse statt direkt auf die Hardware-Outputs geschickt werden.

24Da scsynth allerdings kein MIDI versteht, muß noch eine L¨osung zur Synchronisierung z.B. mit einem Harddisk-Recording-Programm gefunden werden. Man kann versuchen, dazu sclang zu verwenden.

61 6 Resum´e

6.1 Anwendungsbeispiel

Abschließend sollen an einem SuperCollider Patch ein paar M¨oglichkeiten des Programms demonstriert werden. Ausgangspunkt ist ein Synthesizer nach Abbildung 5.5. Er soll wie folgt erweitert werden:

• zuschaltbarer Doppler-Effekt fur¨ die Transmitter-Bewegungen • zuschaltbarer r¨aumlich gerichteter Verzerrer • zuschaltbarer Hall • optionale Umkehrung des Modells, so daß die Receiver die Ausgangskl¨ange symbolisie- ren und die Transmitter diese Klangfelder als bewegte Mikrophone“ abtasten und zu ” den Lautsprechern leiten

Doppler-Effekt

Der Doppler-Effekt beschreibt das Ph¨anomen, daß sich die wahrgenommene Tonh¨ohe eines Klangk¨orpers in Abh¨angigkeit von seiner Bewegung relativ zum Beobachter ver¨andert. N¨ahert sich der Klangk¨orper dem Beobachter, so wird die Wellenl¨ange effektiv verkurzt¨ und die Tonh¨ohe steigt, der umgekehrte Fall tritt auf, wenn sich der Klangk¨orper wegbewegt. Um einen Doppler-Effekt zu realisieren, bedient man sich einer variablen interpolierenden Delay- Line. Die momentane Delay-Zeit korrespondiert mit dem Abstand der Klangquelle vom Be- obachter und betr¨agt im Medium Luft bei Raumtemperatur etwa ∆t = ∆d/(344m/s).

Der Doppler-Effekt wird als Insert in den Signalfluß gesetzt. Ein Insert kann in Super- Collider realisiert werden, indem ein Audio-Bus mittels In.ar eingelesen und das Ergebnis mit ReplaceOut.ar zuruckgeschrieben¨ wird. Zur Berechnung des Doppler-Shifts werden im Lisp Script mit weiteren (source-request) Befehlen nun zus¨atzlich zu den Sensitivit¨aten auch die Trajektorien-Koordinaten angefordert. Fur¨ die Beobachter-Position wird vereinfachend der Surface-Mittelpunkt (0.5, 0.5) angenommen, dies l¨aßt sich sp¨ater leicht parametrisieren. Die Trajektorien-Daten werden analog zum Mix-Synth (Quelltext 5.5) mit einem durch den Phasor betriebenen BufRd abgetastet. Das aus X- und Y-Koordinaten bestehende Stereo- Signal wird mit Select UGens aufgetrennt und die Distanz nach dem Satz des Pythagoras berechnet:

62 6 Resum´e

Quelltext 6.1: cillo-doppler.sc

SynthDef( "cillo−doppler", { arg i aBus, i kInBuf, i kPhasorBus, i extent = 0.04; var traj, dly;

traj= BufRd.kr( numChannels: 2, bufnum: i kInBuf, phase: In.kr( bus: i kPhasorBus )); dly = ((Select.kr( which: 0, array: traj ) − 0.5).squared + (Select.kr( which: 1, array: traj ) − 0.5).squared).sqrt ∗ i extent;

ReplaceOut.ar( bus: i aBus, channelsArray: DelayC.ar( in: In.ar( bus: i aBus ), maxdelaytime: 2 ∗ i extent, delaytime: dly )); }).writeDefFile( p );

Der Benutzer bestimmt die Raum-Gr¨oße auf der graphischen Oberfl¨ache des Lisp Plug-Ins. Der Normalisierungsfaktor fur¨ die Delay-Zeit i_extent wird bereits im Lisp Script berech- net. DelayC ist eine kubisch interpolierende Delay-Line. maxdelaytime bestimmt die interne Puffergr¨oße und muß so gew¨ahlt sein, daß keine Verz¨ogerungen auftreten, die gr¨oßer als dieser Wert sind.

Verzerrer

Unter Verzerrung kann man allgemein eine Signaltransformation verstehen, die nicht durch ein lineares System beschrieben werden kann. Eine einfache Verzerrung ist beispielsweise die Transformation y ← x2. Ein Verzerrer kann mit einem Median-Filter gebaut werden. Wenn man jeweils von wenigen benachbarten Samples den Median berechnet, werden kurze Spikes eliminiert. Subtrahiert man nun das Originalsignal, bleiben haupts¨achlich diese kurzen Signal- spitzen ubrig.¨ Das Differenz-Signal wird mit dem gegl¨atteten Median-Signal moduliert. Mit einem Amplituden-Envelope-Follower kann das verzerrte Signal grob an die ursprungliche¨ Lautst¨arke angepaßt werden.

Der Verzerrer soll von einem Richtungsvektor gesteuert werden. Ein zus¨atzlicher Transmitter wird dafur¨ benutzt. Er bekommt den speziellen Namen ’d’ (Distortion) und wird aufgrund dieses Namens vom Lisp Script erkannt und separat behandelt. Fur¨ jeden Ausgangskanal wird ein Distortion-Synth erzeugt, der in Abh¨angigkeit von diesem d-Transmitter zwischen dem trockenen und verzerrten Signal uberblendet.¨ Das Mischungsverh¨altnis wird aufgrund des Winkels, den der d-Transmitter und der jeweilige Receiver zum Surface-Mittelpunkt bilden, gew¨ahlt. Wenn A die gegenw¨artige Position des d-Transmitters, B der Surface-Mittelpunkt und C der Ankerpunkt des Receivers sind, ergibt sich der Winkel nach

  arctan (Cx−Bx)·(Ay−By)−(Cy−By)·(Ax−Bx) (Cx−Bx)·(Ax−Bx)+(Cy−By)·(Ay−By)

Das Mischungsverh¨altnis wird daraus so berechnet, daß bei einem Winkel von 0◦ nur die Verzerrung, bei 180◦ nur das trockene Signal zu h¨oren ist. Mit einem Divergenz-Parameter i_narrow l¨aßt sich die Verlauf zwischen 0◦ und 180◦ einstellen. Hier die Synthesizer-Definition:

63 6 Resum´e

Quelltext 6.2: cillo-distortion.sc SynthDef( "cillo−distortion", { arg i aBus, i kInBuf, i kPhasorBus, i locX, i locY, i gain = 2.0, i narrow = 4.0; var traj, dtrajx, dtrajy, dstatx, dstaty, da, dry, mix, med, flt, norm mul, norm add;

dstatx = i locX − 0.5; dstaty = i locY − 0.5; norm mul= −1.0 / pi; norm add= 1.0;

traj = BufRd.kr( numChannels: 2, bufnum: i kInBuf, phase: In.kr( bus: i kPhasorBus )); dtrajx = Select.kr( which: 0, array: traj ) − 0.5; dtrajy = Select.kr( which: 1, array: traj ) − 0.5;

// delta angle normalized to 0.0 ... 1.0 // (where 1.0 is 0 degrees, 0.5 is +/− 90 degrees, // 0.0 is 180 degrees) da = abs( atan2( (dstatx ∗ dtrajy) − (dstaty ∗ dtrajx), (dstatx ∗ dtrajx) + (dstaty ∗ dtrajy) )) ∗ norm mul + norm add; mix = min( 1.0, (dtrajx.squared + dtrajy.squared) / 0.125 ) ∗ da.pow( i narrow );

dry = In.ar( bus: i aBus ); med = Median.ar( length: 3, in: dry ); flt = Normalizer.ar( in: (dry − med) ∗ med, level: Amplitude.kr( in: dry, mul: i gain ), dur: 0.005 );

ReplaceOut.ar( bus: i aBus, channelsArray: Median.ar( length: 3, in: flt, mul: mix, add: DelayN.ar( in: dry, mul: 1.0 − mix, delaytime: 0.1, maxdelaytime: 0.01 ))); }).writeDefFile( p );

Das trockene Signal muß mit DelayN verz¨ogert werden, um den Look-Ahead des Median- Filters auszugleichen und Kammfilter-Effekte bei der Uberblendung¨ zu verhindern.

Hall

Mit Allpass-Filtern kann man einen primitiven Hall simulieren. Ahnlich¨ dem Verzerrer ver- wenden wir ein Session-Objekt zur Steuerung des Halls: Einen zus¨atzlichen Receiver mit dem speziellen Namen ’e’ (Echos). Angenommen, die normalen Receiver befinden sich in einer kreisf¨ormigen Anordnung. Dann kann der e-Receiver einfach in deren Mitte plaziert werden; wird ein Transmitter von der Kreisbahn zur Mitte hin abgelenkt, so wird sein Signal in die Hall-Sektion gegeben. Der Einfachheit halber ist der Input dieser Hall-Sektion ein Mono-Bus, und fur¨ jeden Ausgangskanal wird dieses Mono-Signal mit einem Allpass-Filter verhallt, das eine zuf¨allige variierende Delay-Zeit hat:

64 6 Resum´e

Normaler Modus

Input Group Doppler Group Mix Group Echo + Distortion Group

Sense−Buf Sense−Bufs Matrix (e−Receiver)

Input−Synth Echo−Synth

... Mix−Synths ... Matrix Input−Synth Echo−Synth numInputs

(insert)

Doppler−Synth ...

Doppler−Synth Distortion−Synth ...

(insert) Distortion−Synth

Traj−Buf Matrix Traj−Buf Output Output ... − − (d−Transmitter) Audio Audio numInputs = Zahl der Transmitter numOutputs = Zahl der Receiver numOutputs

Umgedrehter Modus

Input Group Distortion Group Mix Group Doppler Group

Input−Synth ... Mix−Synths Sense−Buf Matrix Matrix Input−Synth numInputs

(insert)

Distortion−Synth

... Doppler−Synth Distortion−Synth ... (insert) Doppler−Synth

Traj−Buf (d−Transmitter) Output Output ...

− − Traj−Buf Matrix Audio Audio numInputs = Zahl der Receiver numOutputs = Zahl der Transmitter numOutputs

Abbildung 6.1: Erweiterter SuperCollider Synthesizer

65 6 Resum´e

Abbildung 6.2: Steuerelemente und Script Oberfl¨ache fur¨ den erweiterten Synth

Quelltext 6.3: cillo-echo.sc SynthDef( "cillo−echo", { arg i aInBus, i aOutBus;

Out.ar( bus: i aOutBus, channelsArray: LPZ2.ar( in: AllpassL.ar( in: In.ar( bus: i aInBus ), maxdelaytime: 0.31, delaytime: LFNoise1.kr( 0.1, mul: 0.1, add: 0.2 ), decaytime: 3 ) ) ); }).writeDefFile( p );

Der Lowpass-Filter LPZ2 dunkelt die Hallfarbe etwas ab.

Modell-Umkehrung

Um das Modell so umzukehren, daß die Receiver Klangfelder darstellen und die Transmit- ter bewegte Mikrophone/Lautsprecher, muß das Lisp Script so ver¨andert werden, daß Re- ceiver durch abstrakte Output-Objekte und Transmitter durch abstrakte Input-Objekte er- setzt werden. In der Initialisierung kann dann die Zuordnung einfach umgetauscht werden. Zus¨atzlicher Aufwand entsteht dadurch, daß die Indices der Transmitter und Receiver bei der Quelldaten-Anforderung mit (source-request) nicht umgedreht werden durfen.¨ Auch mussen¨ die Gruppen-Knoten unterschiedlich angeordnet werden, damit die Reihenfolge der DSP-Bl¨ocke korrekt bleibt. Wenn man davon ausgeht, daß die Verzerrer unabh¨angig vom Modell immer die Receiver bearbeiten und der Doppler immer auf die Transmitter einwirkt (die Receiver sind ja unbewegt und k¨onnen daher keinen Doppler-Shift erzeugen), ergeben sich die beiden Schemata nach Abbildung 6.1.

Das Lisp Script scrt-demo.lisp ist zusammen mit einer Beispiel-Session und Beispiel- Kl¨angen auf der beigefugten¨ CD-ROM enthalten. Die vom Script generierten GUI Para-

66 6 Resum´e meter sind in Abbildung 6.2 rechts zu sehen. Der Normal-Modus, in dem die Transmitter den Soundfiles zugeordnet sind, ist angew¨ahlt. Die Surface links zeigt einen Ausschnitt der d-Transmitter Trajektorie zum Steuern der Verzerrung. Zu sehen ist auch der kreisf¨ormige Umriß des in der Mitte plazierten e-Receivers zum Ansteuern des Halls.

6.2 Probleme

W¨ahrend der Entwicklung der vorliegenden Arbeit sind keine ungel¨osten Probleme im in- ternen Programmverhalten aufgetreten. Die Thread-Synchronisierung hat einige Zeit in An- spruch genommen und insbesondere in der Anfangsphase viele Bugs enthalten. Dasselbe gilt fur¨ die dynamische Anpassung an Preferences-Anderungen¨ mit dem java.util.prefs Paket. Insbesondere hat sich als nachteilig erwiesen, daß es einen eigenen Event-Dispatcher ver- wendet, der außerhalb des AWT Threads l¨auft, und daß die Ereignisse keine Informationen daruber¨ tragen, wer die Preferences ver¨andert hat, so daß umfangreiche Vorkehrungen zur Verhinderung von Deadlocks getroffen werden mußten. Die interne Umstellung aller Objekte beim Laden einer Session h¨atte eleganter durch einen zentralen Mechanismus gel¨ost werden k¨onnen.

Das Programm enth¨alt in der aktuellen Version 0.66 noch zahlreiche kleinere Bugs, die nicht vital fur¨ die Benutzung sind. Mit dem Update der Apple Java VM von Version 1.4.2 03 nach 1.4.2 05 kurz vor Fertigstellung der Arbeit wurde die Graphikdarstellung des Timeline Fen- sters im Echtzeit Modus leider sehr langsam und flackert.1 Dieses Problem ist vermutlich auf eine Anderung¨ des Double-Buffering Mechanismus zuruckzuf¨ uhren¨ und muß in der n¨achsten Version von Meloncillo dringend beseitigt werden.

Ungel¨ost sind noch Probleme beim Betrieb im Netzwerk. Obwohl in der Anfangspha- se ein Test erfolgreich lief, in dem auf einem Computer Meloncillo und auf dem ande- ren SuperCollider lief, wurde die Realtime-Engine von Meloncillo aus Performance-Grunden¨ sp¨ater neu geschrieben. Weitere jungst¨ vorgenommene Tests ergaben, daß die beiden Rech- ner nicht synchron bleiben. Die Zeitspanne, die vergeht, bis die ersten Dropouts auftreten, schwankt je nach Rechner-Paar zwischen einer halben Minute und einer Viertelstunde. Da die Clock-Unterschiede eigentlich so klein sein sollten, daß bei entsprechend gew¨ahlten Puffer- Gr¨oßen ein Synchronisationsverlust erst nach einer Zeitspanne in der Gr¨oßenordnung von Stunden auftreten kann, muß die Ursache im Timing-Schema des OSC-Datenversands ge- sucht werden. M¨oglicherweise l¨aßt sich das Problem l¨osen, indem die OSC-Befehle zum Puffer-Update mit Time-Tags versehen werden.2 Nichtsdestotrotz sollte langfristig eine Slave- Synchronisierung in Meloncillo integriert werden, um eine synchronen Betrieb mit Harddisk- Recording-Programmen zu erm¨oglichen.

1Man kann sich momentan nur behelfen, indem das Fenster zeitweilig geschlossen wird. Ein positiver Aspekt des VM Updates ist das Verschwinden eines Bugs, der sich in gelegentlichen Stack-Overflows ¨außerte, die innerhalb der Bibliotheken auftraten und damit unm¨oglich zu eliminieren waren. 2Ein Vorteil des gegenw¨artigen Mechanismus – der Versand nach Aufforderung durch eine /tr Nachricht – besteht darin, daß eine Anbindung an Max/MSP leichter zu realisieren ist, denn die OSC-Externals von Max/MSP behandeln Time-Tags derzeit nicht automatisch.

67 6 Resum´e

6.3 Ausblick

Die weitere Entwicklung des Programms kann in Detailverbesserungen und gr¨oßere Erg¨anzun- gen und Umstrukturierungen unterteilt werden. Zur ersten Kategorie zu z¨ahlen sind

• Anpassung der Oberfl¨ache und Tastatur-Shortcuts unter Linux und Windows • konfigurierbare Farbgebung • Dehnen und Kurzen¨ des Zeitabschnitts im Filter Dialog (Resampling) • Verbesserung der geometrischen Zeichentools • Entwicklung einer DTD fur¨ die Session-Datei • Shuffle- und Slip-Modus fur¨ Timeline-Operationen analog zu ProTools

Die gr¨oßeren Erg¨anzungen h¨angen im wesentlichen davon ab, wie sich das Programm in der Praxis bew¨ahrt. Wichtige Elemente werden sein

• Stabile Realtime Performance im Netzwerk • Synchronisierung mit Harddisk-Recording Programmen • Anbindung an Max/MSP 4.5 • Erweiterung der Timeline um frei setzbare Markierungen • evtl. Erweiterung um eine Layer-Struktur • Erweiterung der Receiver und Transmitter Interfaces um Attribute • script-generierte Preferences Karten

Wie bereits geschildert, bricht die Synchronisation momentan bei Betrieb im Netzwerk fruher¨ oder sp¨ater zusammen. Obwohl sich das Problem voraussichtlich leicht l¨osen l¨aßt, wird eine Unterstutzung¨ von OSC-Time-Tags angestrebt. Wenn eine Slave-Synchronisierung in Meloncillo eingebaut wird, sollte zugleich ein grundlegendes Konzept fur¨ eine OSC-Server Schnittstelle entworfen werden.

Eine einfache Timecode Steuerung (z.B. auf MIDI-Timecode Basis) sollte entwickelt werden, so daß ein synchrones Einspielen von Spuren aus einem Harddisk-Recording Programm m¨oglich wird; momentan mussen¨ die zu spatialisierenden Kl¨ange zun¨achst gebounct werden, was sehr hinderlich ist. Eine Zwischenl¨osung kann wahrscheinlich mit sclang erreicht werden. Es l¨aßt sich ebenso wie scsynth von einem OSC-Client steuern. Ein OSCresponderNode Objekt mußte¨ auf den Transport-Start in Meloncillo reagieren und einen entsprechenden MIDI Befehl an eine Applikation wie Logic Pro weiterleiten.

Das Ansteuern von Max/MSP macht momentan wenig Sinn, weil das OSC-Objekt otudp read von Matt Wright alle Message-Argumente in primitive Max-Typen ubersetzt,¨ was fur¨ das Senden großer Floating-Point Puffer ungeeignet ist. Max/MSP 4.5 bietet eine integrier- te Java-Schnittstelle (mxj) an. Ein einfaches Plug-In soll dafur¨ entwickelt werden, das die Sensitivit¨ats-UDP-Pakete empf¨angt und direkt in MSP-Puffer schreibt.

Um ein Stuck¨ besser uberblicken¨ zu k¨onnen, sind Zeitmarker erforderlich. Diese k¨onnten auch mit Scripten generiert werden oder von Scripten ausgelesen und zur Klangsynthese benutzt werden.

68 6 Resum´e

Wenn, wie im letzten Beispiel gezeigt, mit mehreren Klangtransformationen gearbeitet wird, kann die Surface schnell unubersichtlich¨ werden. Zu uberlegen¨ ist, wie m¨oglichst einfach die Form einer Ebenen-Struktur in die Session gebracht werden kann. Diese Ebenen k¨onnten entweder optisch umgeschaltet oder uberlagert¨ dargestellt werden.

Receiver und Transmitter sollten mit einer Attribute-Mappe ausgestattet werden. Um einfache Features zu integrieren, wie zum Beispiel die M¨oglichkeit, Transmitter stummzu- schalten oder solo abzuh¨oren, mussen¨ die Scripte momentan spezielle GUI Felder auf ihre Plug-In Oberfl¨achen addieren. Er w¨are effektiver, mit einem einfachen get und set Mecha- nismus den Transmittern und Receivern beliebige Attribute hinzuzufugen,¨ die dann auch von den Editoren unterstutzt¨ werden. Ein Transmitter Editor k¨onnte dann Solo- und Mute- Buttons direkt im Timeline Fenster darstellen. Getrennte Methoden wie getName, setName, getAnchor, setAnchor wurden¨ in diesem allgemeinen Attribute-System aufgel¨ost werden.

Von Beta-Testern ist der Wunsch ge¨außert worden, eine Input/Output Konfiguration fur¨ die Audio-Hardware in Meloncillo vornehmen zu k¨onnen. Das kollidiert zun¨achst mit der Grundidee, daß das Programm nichts uber¨ konkrete Signalverarbeitung weiß. Eine Alternative w¨aren Preferences-Karten, die dynamisch von Scripts generiert werden. Wenn in einer der n¨achsten Versionen die Anbindung an Max/MSP realisiert ist, mußten¨ die Preferences nicht innerhalb des Programmes erweitert, sondern lediglich ein zus¨atzliches Preferences-Script angemeldet werden.

Die Hauptaufgabe wird jedoch sein, das Programm ausfuhrlicher¨ durch m¨oglichst viele ver- schiedene Anwender in der Praxis zu erproben.

69 Literaturverzeichnis

[Chowning 1971] John Chowning, The Simulation of Moving Sound Sources. Journal of the AES Vol. 19, No. 1, Januar 1971 (Nachdruck in Computer Music Journal Vol. 1 No. 3, Juni 1977, S. 48–52)

[Eimert/Humpert 1973] Herbert Eimert / Hans Ulrich Humpert, Das Lexikon der elektro- nischen Musik (Artikel Raum“, Raumton“, Raumakustik“ und ” ” ” Steuerung“). Regensburg 1973 ” [Gertig et al. 1995] Frank Gertig / Julia Gerlach / Golo F¨ollmer, Musik..., verwandelt – Das Elektronische Studio der TU Berlin 1953–1995. Hofheim 1995

[Gosling et al. 2000] James Gosling / Bill Joy / Guy Steele / Gilad Bracha, The Java Language Specification, 2nd Edition. Boston 2000. Online publi- ziert: http://java.sun.com/docs/books/jls/second_edition/ html/j.title.doc.html [Haller 1995] Hans Peter Haller, Das Experimentalstudio der Heinrich-Strobel- Stifung des Sudwestfunks¨ Freiburg 1971–1989 : Die Erforschung der Elektronischen Klangumformung und ihre Geschichte (Band 1, Zur Technik der Elektronischen Klangumformung). Baden-Baden 1995

[Hein 1999] Folkmar Hein, Von der Quadrophonie zur Raumklangsteuerung – Uberlegungen¨ zur Konzeption des neuen TU-Studios. In: Bernhard Feiten / Folkmar Hein / Axel R¨obel / Werner Schaller (Hrsg.), Impulse und Antworten – Festschrift fur¨ Manfred Krause. Berlin 1999, S. 85–110

[Jot/Warusfel 1995] Jean-Marc Jot / Olivier Warusfel, Spat˜ : A Spatial Processor for Musicians and Sound Engineers. CIARM: International Conference on Acoustics and Musical Research, Mai 1995

[Kleiner et al. 1993] Mendel Kleiner / Bengt-Inge Dalenb¨ack / Peter Svensson, Aura- lization – An Overview. Journal of the AES Vol. 41, No. 11, No- vember 1993, S. 861-875

[Lea 1997] Doug Lea, Concurrent Programming in Java – Entwurfsprinzipien und Muster. Bonn 1997

[Leahy 2004] Michael Leahy, SCREAM – SuperCollider Resource for Electro- Acoustic Music. Online-Publikation 2004: http://audio.egregious.net/scream/whitepapers/scream_ whitepaper.v1.1.1.pdf

70 Literaturverzeichnis

[Loy 1985] Gareth Loy, SNDPATH. In: Computer Audio Research Laboratory (CARL) Program Guide. La Jolla 1985

[Mayer 1995] Otto Mayer, Programmieren in COMMON LISP. Heidelberg, 1995

[Malham 1998] D. G. Malham, Spatial Hearing Mechanisms and Sound Re- production. Online-Publikation 1998: http://www.york.ac.uk/ inst/mustech/3d_audio/ambis2.htm

[McCartney 1996] James McCartney, SuperCollider: A New Real Time Synthesis Lan- guage. ICMC Paper 1996

[McCartney 2002] James McCartney, Rethinking the Computer Music Language: SuperCollider. In: Computer Music Journal Vol. 26, No. 4, Winter 2002, S. 61–68

[Momenti/Wessel 2003] Ali Momenti / David Wessel, Characterizing and Controlling Mu- sical Material Intuitively with Geometric Models. Proc. of the 2003 Conference on New Interfaces for Musical Expression (NIME-03), Montreal, S. 54–62

[Moore 1983] F. Richard Moore, A General Model for Spatial Processing of Sounds. Computer Music Journal Vol. 7, No. 3, Herbst 1983, S. 6–15

[Moore 1985] F. Richard Moore, The CMusic Sound Synthesis Program. La Jolla 1985

[de la Motte-Haber 1996] Helga de la Motte-Haber (Red.), Klangkunst. Katalog von Son- ambiente – Festival fur¨ H¨oren und Sehen. Hrsg. von der Akademie der Kunste,¨ Berlin 1996

[de la Motte-Haber 1993] Helga de la Motte-Haber, Die Musik von Edgard Var`ese. Hofheim 1993

[Muhlethaler/Schuppisser¨ 2004] Christian Muhlethaler¨ / Alexander Schuppisser, Sonificator – A Java Framework for writing Applications that use Super- Collider as Sound-Engine. Vortrag auf der Linux Audio Developer (LAD) Conference 2004. Online-Slides: http://www.linuxdj. com/audio/lad/contrib/zkm_meeting_2004/slides/friday/ muehletaler+schuppisser-supercollider.pdf

[Pulkki 2001] Ville Pulkki, Spatial Sound Generation and Perception by Ampli- tude Panning Techniques. Espoo, 2001

[Radtke 1988] Torsten Radtke, Entwurf und Bau eines computergesteuerten 4- Kanal-Mischers nach ARD-Pflichtenheft. Diplomarbeit TU Berlin 1988

[Ruschkowski 1998] Andr´eRuschkowski, Elektronische Kl¨ange und musikalische Ent- deckungen. Stuttgart 1988

[Schneider 1995] Thomas Schneider, Programm zur Steuerung multipler Audio- signale zur Simulation r¨aumlich bewegter Schallquellen. Magister- arbeit TU Berlin 1995

71 Literaturverzeichnis

[Seelig 1990] Thomas Seelig, Entwicklung einer grafischen Benutzeroberfl¨ache fur¨ ein MIDI-gesteuertes quadrophones Mischpult. Magisterarbeit TU Berlin 1990

[Stuart 1996] J. Robert Stuart, The Psychoacoustics of Multichannel Audio. AES UK Audio for New Media Conference, Paper ANM-12, 1996

[Supper 1997] Martin Supper, Elektroakustische Musik und Computermusik: Geschichte, Asthetik,¨ Methoden, Systemen. Darmstadt 1977

[de Vries/Boone 1999] Diemer de Vries / Marinus M. Boone, Wave Field Synthesis and Analysis Using Array Technology. Proc. IEEE Workshop on Appl. of Signal Proc. to Audio and Acoustics, New Paltz, Oktober 1999

[Wishart 1994] Trevor Wishart, Audible Design : A Plain and Easy Introduction to Practical Sound Composition. York 1994

[Wright/Freed 1997] Matthew Wright / Adrian Freed, Open SoundControl : A New Protocol for Communicating with Sound Synthesizers. Proc. of the 1997 Intl. Computer Music Conference (ICMC), Thessaloniki, S. 101–104

[Wright et al. 2003] Matthew Wright / Adrian Freed / Ali Momenti, OpenSound Con- trol : State of the Art 2003. Proc. of the 2003 Conference on New Interfaces for Musical Expression (NIME-03), Montreal, S. 153–159

[Zm¨olnig et al. 2003] Johannes Zm¨olnig / Alois Sontacchi / Winfried Ritsch, The IEM- Cube : A Periphonic Re-/Production System. Proc. of the AES 24th Intl. Conference, 2003, S. 21–25

72 Anhang: Abbildungen, Quelltexte

Abbildungsverzeichnis

1.1 Σ 1 Oberfl¨ache ...... 11 1.2 Panning Objekte in Digital Performer ...... 14 1.3 VBAP Anwendung in Max/MSP ...... 17 1.4 Perzeptive Parameter in Spat˜ ...... 18

3.1 Legende ...... 26 3.2 Session Struktur ...... 29

4.1 Surface Fenster ...... 36 4.2 Hilfspaletten ...... 36 4.3 B´ezier-Kurve mit variabler Geschwindigkeit ...... 39 4.4 Editor fur¨ SigmaReceiver ...... 40 4.5 Matrix Meter ...... 40 4.6 Timeline Fenster ...... 41 4.7 Transport Palette ...... 41 4.8 Dezimation von Trajektorien ...... 42

5.1 Plug-In Interfaces und Klassen ...... 45 5.2 Plug-Ins zur Trajektorien-Filterung ...... 46 5.3 RealtimeConsumer Profile ...... 47 5.4 Realtime Datenstr¨ome ...... 48 5.5 Nodes, Busse und Buffer fur¨ einen Amplituden-Mixer in SuperCollider . . . . 58

6.1 Erweiterter SuperCollider Synthesizer ...... 65 6.2 Steuerelemente und Script Oberfl¨ache fur¨ den erweiterten Synth ...... 66

Quelltexte

3.1 XMLRepresentation.java (io package) ...... 29 3.2 Receiver.java (receiver package) ...... 30 3.3 Transmitter.java (transmitter package) ...... 31 3.4 ReceiverCollectionListener.java (receiver package) ...... 32 4.1 VirtualSurface.java (gui package) ...... 35 4.2 AbstractGeomTool.java (gui package) ...... 38 4.3 TrackSpan.java (io package) ...... 42 5.1 RenderPlugIn.java (render package) ...... 44 5.2 RenderConsumer.java (render package) ...... 45

73 Quelltexte

5.3 RealtimeProducer.java (realtime package) ...... 47 5.4 smooth.orc ...... 53 5.5 synthdef-sources.sc ...... 59 6.1 cillo-doppler.sc ...... 63 6.2 cillo-distortion.sc ...... 64 6.3 cillo-echo.sc ...... 66

74