Meloncillo – eine graphischeBenutzeroberflache zur musikalischenRaumklangsteuerung mitImplementierung einerOSC-Schnittstelle zur Klangsynthese

Magisterarbeitvon Hanns Holger Rutz, Matr.-Nr. 192946Technische Universitat BerlinKommunikationswissenschaftBetreuer: Prof. Dr. Stefan Weinzierl

”La musique du futur? Surement basee sur le son et au-dela des notes“(Edgard Varese 1947)

”Vareses Denken war empirisch. Er interessierte sich dafur,wie es klang – nicht wie es gemacht war.“

(Morton Feldman 1966)

Die selbstandige Anfertigung versichere ich an Eides Statt.

Inhaltsverzeichnis

1 Einfuhrung 5

1.1 Begriff der Raumklangsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.1 Abgrenzung zu Auralisationsverfahren . . . . . . . . . . . . . . . . . . 81.1.2 Abgrenzung zu Live-Diffusionsverfahren . . . . . . . . . . . . . . . . . 8

1.2 Historische Wurzeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Vorhandene Software zur Raumklangsteuerung . . . . . . . . . . . . . . . . . 10

1.3.1 APB-Tools Σ 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.2 zplane.development z.matrix . . . . . . . . . . . . . . . . . . . . . . . 121.3.3 Wonder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.4 Surround Panning Objekte . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 Hardware basierte Raumklangsteuerung . . . . . . . . . . . . . . . . . . . . . 141.5 Raumklang-Synthese Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.5.1 VBAP – Vector Based Amplitude Panning . . . . . . . . . . . . . . . 161.5.2 IRCAM Spat˜ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.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 . . . . . . . . . . . . . . . . 202.2 Designspezifikation fur eine neue Raumklangsteuerung . . . . . . . . . . . . . 21

2.2.1 Trennung von Oberflache und Signalverarbeitung . . . . . . . . . . . . 212.2.2 Abstraktion vom Synthesemodell . . . . . . . . . . . . . . . . . . . . . 222.2.3 Anwender mit und ohne Programmiererfahrung . . . . . . . . . . . . . 232.2.4 Unabhangigkeit vom Betriebssystem . . . . . . . . . . . . . . . . . . . 232.2.5 Zwei grundlegende Objekttypen . . . . . . . . . . . . . . . . . . . . . 242.2.6 Echtzeit und Offline Modus . . . . . . . . . . . . . . . . . . . . . . . . 242.2.7 Diskrete Datenstrome . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Programmarchitektur 26

3.1 Sprache und Arbeitsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Packages Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3 Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 Receiver, ReceiverCollection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5 Transmitter, TransmitterCollection . . . . . . . . . . . . . . . . . . . . . . . . 313.6 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.8 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3

Inhaltsverzeichnis

4 Graphische Benutzeroberflache 354.1 Surface : zweidimensionale Momentansicht . . . . . . . . . . . . . . . . . . . . 35

4.1.1 Hilfs-Paletten und Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . 374.1.2 ReceiverEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1.3 Matrix Meter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Timeline : horizontale Zeitdarstellung . . . . . . . . . . . . . . . . . . . . . . 404.2.1 Trajektorien Daten-Format . . . . . . . . . . . . . . . . . . . . . . . . 414.2.2 Transport Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Plug-In Schnittstellen 445.1 Offline (Nicht-Echtzeit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2 Realtime (Echtzeit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.3 Common Lisp fur Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3.1 Die LispPlugIn Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3.2 Ein Beispielscript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.4 Open Sound Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.4.1 Protokollubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.4.2 Implementierung in Meloncillo . . . . . . . . . . . . . . . . . . . . . . 565.4.3 Anbindung an SuperCollider . . . . . . . . . . . . . . . . . . . . . . . 57

6 Resume 626.1 Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.2 Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.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 Benutzeroberflache bestehende Programm mit dem Namen ”Meloncillo“ erlaubt dieGestaltung von Trajektorien in einem zweidimensionalen Raum und kann in Verbindungmit einem existierenden Klangsynthese-Programm wie SuperCollider dazu verwendet werden,verraumlichte Klange zu berechnen oder in Echtzeit abzuspielen. Fur die Echtzeit-Steuerungist eine Open Sound Control (OSC) Schnittstelle vorgesehen. Eine script-gesteuerte Plug-InSchnittstelle ermoglicht es, unterschiedliche Modelle der Verraumlichung zu benutzen.

Die Arbeit ist dadurch motiviert, daß die Raumklangsteuerungen, die dem Autor bekanntsind, zu wenig gestalterische Freiheiten bieten oder nicht ohne weiteres fur die heute gangigenComputer-Plattformen verfugbar sind. Das hier vorgestellte Programm soll neue Sichtweisenauf musikalische Raumlichkeit offnen.

CD-ROM

Der Quelltext und die Quelltext-Dokumentation konnen aus Platzgrunden nicht abgedrucktwerden. Eine CD-ROM ist beigefugt, die alle notigen Dateien enthalt:

• 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 -Klange

1.1 Begriff der Raumklangsteuerung

Der Begriff Raumklang enthalt bereits ein musikalisches Element, wahrend die englischeUbersetzung, etwa spatial sound, einen physikalischeren Charakter bekommt – sound kannruckubersetzt auch Schall heißen. Physikalische Begriffe waren Raumschall oder Raumakustik.1

Zwischen Raumklang und Raumakustik besteht ein wesentlicher Unterschied: Raumakustikbeschreibt den Klang des Raumes, wahrend Raumklang die Gestaltung von Klang im Raummeint. 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 Kopfhorerubertragung oderBeschallung im offenen Feld auf. Ein anderer Fall ohne außere Raumeinwirkung sind Korper-schallubertragung und Korperstimulation durch Aktuatoren.2

Die ganz unterschiedlich akzentuierten Aspekte von Raumlichkeit sind eines der Hauptmerk-male von Klangkunst und Klanginstallation. Fur einen Uberblick sei auf die Artikel desKatalogs Klangkunst zum Festival Sonambiente 1996 hingewiesen3. Ein paar Beispiele: InBill Fontanas Klangbrucke Koln-Tokyo wird das akustische Bild zweier sehr weit voneinan-der entfernter Orte auf der Welt durch Satelliten-Transmission ausgetauscht. Die Arbeit stehtin gewissem Kontext zu der von Murray Schafer entwickelten Idee der Klangokologie. AlvinLucier laß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 Raum-lichkeit nicht nur durch dem Objekt Gegenuberstehen, sondern gleichfalls durch Herantretenund Entlangschreiten an diesem ausgedehnten und in die Architektur integrierten Gebildeerfahren.

Die begriffliche Nahe von Raumklang und Raumakustik kann leicht zu Verwirrungen fuhren:

”Der Komponist orientiert sich am geometrischen Raum und versucht, in dessenerkennbaren Grenzen einen ebenfalls erkennbaren, d.h. erhorbaren Klangraum zuschaffen. 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 raumlich-geometrischer Natur, so spricht man beispiels-weise von einer hohen Tonlage, einer melodischen Linie oder Kontur; die Menge der verwende-ten Tone bildet den Ton-Raum6. Herbert Eimert unterscheidet neben diesem metaphorischenRaum 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 vomHorer nachvollzogen wird und wie er sich in den Noten, im Notationsraum der aufgezeich-neten Musik niederschlagt.“7 Wird Musik raumlich verteilt wiedergegeben, so kann dieserneue 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 raumlich-plastischeKonfiguration der Klangfelder uberfuhrt wird.“

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

2Beim Klanganzug der Kunstlerin Lynn Pook werden sechzehn Lautsprecher am Korper befestigt –”Der

menschliche Korper wird zum Klangraum“. Das Beispiel zeigt, daß Raumerfahrung nicht nur durch (echteoder simulierte) von unterschiedlichen Seiten auf das Ohr treffende Schallwellen gemacht werden kann.Dazu zahlen 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. 271f7ebd.

6

1 Einfuhrung

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

Anders ausgedruckt ist Klangsteuerung ein formgebender Prozeß, der auf einer hierarchischubergeordneten 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 Geraten wird zur Kontrolle oft ein Mikrophonbenutzt, das wahrend der Performance eine Klangumformung steuert. In den klassischennach MUSIC V modellierten Musiksprachen bezeichnen Kontrolldaten diejenigen Daten, diedynamisch uber die Zeit – und in der Regel mit konstanter Rate abgetastet – Einfluß aufKlangparameter und -transformationen nehmen.10

Raumklangsteuerung wird nun definiert als ein Mittel zur dynamischen Formgebung vonBewegungen, Verteilungen und Transformationen von Klangen, die raumlich, das heißt ubermehrere Lautsprecher wiedergeben werden sollen. Das bedeutet, daß die Mehrkanaligkeitbereits in den Klangverteilungen und -transformationen angelegt ist und explizit gestaltetwerden kann. Beispiel: Wenn ein monophoner Ausgangsklang mit unterschiedlichem Fre-quenzgang gefiltert und auf verschiedenen Lautsprechern ausgeben wird, ist das eine Formvon Raumklang, denn der Klang wurde raumlich gestaltet. Der benutzte Filter ist jedochnur dann als Raumklangsteuerung zu bezeichnen, wenn in ihm selbst a) die dynamische,zeitveranderliche Steuerung und b) die Variation des Frequenzganges uber verschiedene Aus-gangskanale (oder allgemein eine raumliche Situation) vorhanden sind. Umgekehrt wird einObjekt zur Raumklangsteuerung, wenn es andere Objekte – ob einen Mixer oder ein Filterspielt dabei keine Rolle – dynamisch raumlich kontrolliert, zum Beispiel indem es fur jedenAusgangskanal einen separaten Filter ansteuert.

Das Adjektiv in musikalischer Raumklangsteuerung soll unterstreichen, was in der eingangszitierten Aussage Morton Feldmans uber Edgard Varese zum Ausdruck kommt, und wasTrevor Wishart nur unmerklich variiert, wenn er in Audible Design schreibt:

”We [composers] may embark on signal-processing procedures which will appearbizarre 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 ofsound 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 – nichtauf das zu beschranken, was zunachst 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 rechenokonomischenGrunden meist etwa ein bis zwei Groß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 konnen, 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 mathematischerModelle das Schallfeld, in dem sich eine Klangquelle befindet, reproduziert und dem Horer denEindruck vermittelt, tatsachlich 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 Verfahrensind die Binauraltechnik, das heißt die Raumsimulation durch Einbezug der Kopfubertra-gungsfunktion (HRTF) und Wiedergabe uber Kopfhorer, und die als Transaural-Technikbezeichnete Lautsprecher-Variante im reflexionsarmen Raum. Daneben wird auch die neuereWellenfeldsynthese (WFS) als Auralisationstechnik verwendet.13

Das Ziel der Raumklangsteuerung ist nicht die Auralisation. Kurz dargestellt werden solljedoch das WFS Programm Wonder (Abschnitt 1.3.3), da es sich explizit als musikalischeRaumklangsteuerung versteht. Das in dieser Arbeit entwickelte Programm kann naturlich miteinem Auralisationsverfahren verknupft werden, es ist allerdings nicht speziell dafur konzi-piert. Insbesondere sind Binaural- und Ambisonics-Rendering durch Steuerung von CSoundmoglich (siehe Abschnitt 1.5.3). Es wird jedoch nicht auf die akustischen Grundlagen derSchallfeldreproduktion und des raumlichen Horens 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 Stuckesentkoppelt 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 personlichen Praferenzen als auch aus der Tatsache, daß im Bereichder Live-Elektronik bereits sehr machtige Werkzeuge vorhanden sind. Es ist nicht Aufgabedieser Arbeit, eine Software wie Max/MSP zu uberbieten, stattdessen soll genau an denPunkten angesetzt werden, die durch die weitgehende Fixierung auf Echtzeit-Fahigkeit inMax nicht oder nur ungenugend beachtet werden. Weitere Erlauterung dazu folgen in derDesignspezifikation.

12sinngemaß 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 erlautert ([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 Regelein ein- oder zweikanaliges Stuck mit Hilfe einer Live-Mischung (”Interpretation“) auf eineVielzahl unterschiedlicher Lautsprecher verteilt wird, wobei die variablen Charakteristikender 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, sichzum Beispiel in der raumlichen Aufteilung der Instrumentengruppen manifestierte, in derAusnutzung der Raumakustik in Kirchen fur Chore usw., und ohne auf spezielle Projektewie die utopische Universe Symphony von Charles Ives einzugehen,16 beginnt die gezieltereAuseinandersetzung mit dem Einsatz von Lautsprechern in der elektronischen und konkretenMusik, das heißt in den 50er Jahren.17 In Karlheinz Stockhausens Gesang der Junglinge von1956 werden funf kreisformig 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) werdendie Klange von im Raum verteilten Lautsprechergruppen wiedergegeben. Im Gegensatz zuStockhausen ist diese Verteilung weniger Ergebnis eines strikten Auskomponierens, sonderngeschieht durch eine Live-Interpretation auf den unterschiedlich klingenden Lautsprecher-Instrumenten.

Neben der Erfindung des Radios als der Verraumlichung des Klanges – indem zwischen Senderund Empfanger praktisch beliebige Distanzen liegen konnen – ist die Auseinandersetzung mitZeit in der Malerei als symmetrischer Gegenpart dafur zu nennen, daß Anfang des 20. Jahr-hunderts die Musik begann sich zu verraumlichen. Der einer alteren Generation angehorende,nach Amerika ausgewanderte Franzose Edgard Varese arbeitete seit 1929 am letztlich nichtrealisierten Werk Espace, das diese neue Aufmerksamkeit bereits im Titel zeigt. Realisiertworden ist 1958 das bekannte Poeme Electronique fur den Pavillon der Firma Philips aufder Weltausstellung jenes Jahres. Mehrere hundert Lautsprecher auf den Innenflachen desvon Le Corbusier und Iannis Xenakis entworfenen zeltartigen Baus standen ihm fur eineraumliche Komposition zur Verfugung. Das Ausgangsmaterial von Varese hatte die Formeines Tonbands mit drei Spuren, von denen zwei stereophonisch verteilt werden konnten unddie dritte aufgezeichneten Raumhall enthielt. Die raumliche Verteilung geschah mit Hilfevon synchronen Bandern, die Steuerbefehle fur Relais enthielten. Die Relais schalteten dieLautsprecher-Gruppen ein und aus, mit denen sich bestimmte Klangbewegungen realisie-ren ließen. Angeblich hat Varese die ”Intonation“ der Bewegungen der Verantwortung derIngenieure uberlassen.19

15vgl. [Gertig et al. 1995], S. 32516vgl. [de la Motte-Haber 1996], S. 20917Mit dem Beginn des Rundfunks datieren die ersten Lautsprecher in die 20er Jahre, vgl. [Ruschkowski 1998],

S. 56–60; der Aspekt der raumlichen Wiedergabe mittels mehrerer Lautsprecher spielte dabei noch keineRolle.

18[Ruschkowski 1998], S. 242, 252f19[de la Motte-Haber 1993], S. 83–110. Nach einem Drehbuch von Le Corbusier wurden zur Musik von Varese

Dias an die Wande projiziert.

9

1 Einfuhrung

1.3 Vorhandene Software zur Raumklangsteuerung

Bei der Entwicklung einer neuen Software ist zunachst zu betrachten, welche bestehendenLosungen bereits existieren und wo ihre Vorteile und Nachteile liegen. Ohne Anspruch aufVollstandigkeit und ohne auf die Vielzahl individueller Patches in Sprachen wie Max ein-zugehen, sollen die gangigsten Programme vorgestellt werden. Die auf Hardware basieren-den Implementationen werden kurz im Anschluß dargestellt. Darauf folgt eine kursorischeUbersicht uber Raumklang-Syntheseverfahren, die in Form von Plug-Ins durch eine Host-Applikation gesteuert werden konnen.

Die Grundkonzepte unterscheiden sich in den meisten Fallen nicht von der Pionier-ArbeitJohn Chownings20 zu Beginn der 70er Jahre. Darin beschreibt er die akustischen Merkmaleder raumlichen Ortung (interaurale Intensitats- und Laufzeitunterschiede) und schlagt vor,zur Simulation raumlicher Distanz variable Reverberation und Frequenz-Filterung zu benut-zen. Nach seinem Modell wird mit Hilfe von quadrophonisch den Horer umgebenden Laut-sprechern ein virtueller Raum um den tatsachlichen Abhorraum konstruiert. Die Klangquellewird zwischen jeweils benachbarten Lautsprechern gepannt21, durch variables Delay entstehtein Doppler-Shift in Abhangigkeit von der Geschwindigkeit der Bewegung. Die Bewegun-gen konnen entweder mit einer mechanischen Eingabevorrichtung in Echtzeit22 oder in Formeinfacher geometrischer Pfade direkt vom Computer erzeugt werden.

Eine Verfeinerung dieses Prinzips wurde spater unter anderen im CMusic System von F.Richard Moore vollzogen.23 Dabei werden zusatzlich die ersten Reflexionen der Klangquellevon den Wanden des virtuellen Raumes mit einer Tapped-Delay-Line simuliert. Desweiterenbesitzen die Klangquellen eine Abstrahlcharakteristik, die sich aus einer richtungsabhangigenLautstarke-Dampfung ergibt. In CMusic konnen die Dimensionen der vier Wande des vir-tuellen und des Abhorraumes bestimmt und die Lange der Hallfahne festgelegt werden. DerUnit-Generator24 space synthetisiert den Klang im Raum. Das separate Programm sndpathdient dem Erstellen von Trajektorien-Dateien, die mit dem quad UGen in CMusic eingelesenwerden konnen.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 Oberflache als auch fur die Receiver Objekte in demhier entwickelten Programm Vorbild war. Technische Details und Funktionsweise konnen so-

20[Chowning 1971]21Das englische Wort Panning laß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 moglich; 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-N25siehe 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 Oberflache

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 32Eingangssignale auf bis zu 24 Ausgangskanale verteilen kann. Die Matrix wird auf DigidesignProTools TDM Hardware realisiert und verwendet dazu softwareseitig die Digidesign AudioEngine (DAE). Dies stellt zugleich Hauptmanko und Hauptvorteil des Programms dar. Zumeinen ist teure Hardware notig28, zum anderen arbeitet das Programm nicht mehr mit DAEVersion 5.1 und hoher zusammen. Bis eine Neuauflage des Programms erscheint, muß also– da pro Bootpartition nur eine DAE existieren kann – zum Betrieb eine separate Mac OS8 oder 9 Partition gebootet werden. Vorteil der DAE Benutzung ist die Moglichkeit, TDMPlug-Ins verwenden und direkt Spuren aus ProTools Sessions einspielen zu konnen, wobeiallerdings nur die Regionen-Positionen und die Volume-Automation erkannt werden.

Die Flexibilitat des Programms resultiert, abgesehen von der hohen Zahl der Ein- undAusgange, aus der Moglichkeit, Schallquellen auf beliebigen zweidimensionalen Pfaden be-wegen und die sogenannten virtuellen Lautsprecher frei positionieren und konfigurieren zukonnen. 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 distanzabhangigenund einer richtungsabhangigen Dampfung, so daß sich neben Kugel, Niere, Keule und Achteine Vielzahl moglicher Charakteristiken ergibt.

Die Oberflache von Σ 1 besteht aus der zweidimensionalen Raumansicht, Stage genannt,einem Transport-Fenster, einem Mixer- und Aux-Fenster und einer Region-Playlist sowie einerReihe 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 Oberflache her dem spateren Σ 1.

27http://apbtools.com bzw. http://apbtools.com/PDFs/SIGMA1_MANUAL.pdf28Pro Tools d24 + MIX Farm, Pro Tools MIX oder Pro Tools MIX Plus. Es gibt einen sogenannten Offline-

Modus, darin ist jedoch keine Audioausgabe moglich.

11

1 Einfuhrung

eine Stage-Anordnung (links) und Coverage-Tables (rechts) abgebildet. Die diskusformigenObjekte in der Stage-Ebene stellen die Mittelpunkte der virtuellen Lautsprecher dar, um sieherum ist die Charakteristik durch abgestufte Farben dargestellt. Die kleinen ballformigenObjekte stellen die beweglichen Schallquellen dar. Ihre Bewegungspfade sind als Linienzugesichtbar.

Neben der Aufzeichnung von Pfaden in Echtzeit durch Bewegen der Maus29 gibt es dieMoglichkeit, im Offline-Modus Linien und Kreise zu zeichnen und Pfade zu kopieren, zuverschieben und zu loschen.

Die Berechnung der Ausgangsklange erfolgt als Intensitatspanning mit Hilfe der dynamischenM ×N Matrix, die aus den M Eingangskanalen und N Ausgangskanalen besteht. Jede Zelle(m, n) enthalt den Quellklang (Zeile m) multipliziert mit der Lautstarkeinformation, die ausdem Abstand des Klanges von und seinem Winkel zu einem Lautsprecher (Spalte n) gewonnenwird. 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 derName andeutet, arbeitet z.matrix ebenfalls mit einer Matrix von Eingangs- und Ausgangs-kanalen, die Große ist auf 16 × 16 beschrankt. Auch hier hat man sich auf eine Hardware-Plattform festgelegt, die DSP-Karten der Firma Creamware (Pulsar und Scope), was demProgramm ahnlich wie Σ 1 fast zum Verhangnis 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 Oberflache ist die Surface, wieder ein zweidimensionales Momentanbildmit beweglichen Icons fur Lautsprecher und Klangquellen. Daneben existieren Level-Meterfur die Ein- und Ausgange. Ein Element, das in Σ 1 nicht vorhanden ist, ist der Sweat Spot,der optimale Abhorpunkt, der bei Mehrkanalbeschallung automatisch entsteht, wenn Pan-ning nach dem Prinzip der Phantomschallquellen arbeitet. z.matrix gleicht unterschiedlicheEntfernungen der Lautsprecher zum Sweat Spot durch ein gegensatzliches Delay aus, so daß– vorausgesetzt der Horer sitzt in einer identischen Kopie der Szenerie tatsachlich im SweatSpot – alle direkten Wellenfronten koharent (gleichzeitig) beim Horer ankommen. Da aus derForschung zum raumlichen Horen bekannt ist, daß unterschiedliche Indizien bei der Ortung inkomplexer Weise zusammenwirken, versucht man hier, die Ortung durch Laufzeitunterschie-de zu minimieren, so daß sie sich nur an den Intensitaten orientieren kann. Interessant istferner die Moglichkeit, 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 Pixelauflosung der Surface, sie laßt sich beliebigvergroßern, und Quellen konnen frei benannt werden.

In z.matrix lassen sich die Lautsprecher-Charakteristiken nicht explizit einstellen, allerdingsgibt es einen Divergenz-Parameter fur jede Quelle und die Moglichkeit einer Lautstarken-

29Das Handbuch erwahnt außerdem, daß ein MIDI Joystick oder Dataglove verwendet werden konnen, machtdazu allerdings keinerlei weitere Angaben, so daß davon auszugehen ist, daß diese Funktion noch in Planungist (zumal das Handbuch als

”preliminary“ bezeichnet wird).

12

1 Einfuhrung

Abnahme in Abhangigkeit der Distanz einer Quelle vom Mittelpunkt der Surface. Zusatzlichist 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 ofElectronic Music in Realtime“. Es stellt eine Oberflache fur das Faltungsprogramm BruteFIRdar, das gemaß den Prinzipien der Wellenfeldsynthese die Eingangssignale verzogert, dampftund filtert, bevor sie auf die einzelnen Kanale eines Lautsprecher-Arrays gegeben werden.

Um Klange im virtuellen Raum zu bewegen, mussen die Wellenfelder dynamisch erzeugtwerden, das heißt die FIR Filter kontinuierlich uberblendet werden. Mit einem Raster wirdfestgelegt, von welchen Orten aus der Klang abstrahlen kann. Die Abstrahlung kann alternativkugelformig (als Punktquelle) oder planar (als ebene Welle) erfolgen. Zusatzlich konnen ersteReflexionen simuliert werden.

Die Bewegungen konnen linear zwischen manuell eingegebenen Breakpoints stattfinden oderim Realtime Modus als Mausbewegung aufgezeichnet werden. Um zu gewahrleisten, daß dieBewegungen synchron mit der Audiowiedergabe abgespielt werden, wird Wonder durch einevon 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 gangigen Harddisk-Recording-Programmen um Surround-Fahigkeiten erweitert worden. Mit den Automations-Engines dieser Programme vereint, stel-len sie einfache Raumklangsteuerungen dar. Der Aufbau in den verschiedenen Programmenahnelt sich dabei sehr stark. Die Automation geschieht meist spurorientiert, das heißt furjeden Kanalzug des Mischers existieren neben der Audiospur zusatzlich Spuren fur jedenautomatisierten Parameter, wie Lautstarke, Equalizer oder Panorama. Die Automation kannin der Regel live aufgezeichnet werden, also durch Bewegen von Software-Reglern mit derMaus – oder externen Controllern wie MIDI-Fadern –, wahrend der Transport lauft. Fureine Offline-Editierung wird eine Breakpoint-Darstellung der Automationsdaten uber oderunter den Audio-Regionen im Arrangier-Fenster eingeblendet. Mehrdimensionale Parameterwie ein Surround-Pan werden aus separaten eindimensionalen Werten zusammengesetzt, wiezum Beispiel Front↔Rear.

Die Panner orientieren sich alle an den Filmformaten, so daß man sich lediglich entscheidenkann, ob man ”5.1“ oder ”10.2“ usw. mischen mochte. Die graphische Oberflache ist eine zwei-dimensionale Flache, auf der die Lautsprecher als Icons abgebildet sind, angeordnet entwederim Rechteck oder kreisformig. Entsprechend wird das Panorama in das Informations-PaarAzimut/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 enthalt.31 Abbildung 1.2 zeigt die Surround-Panner von DigitalPerformer.

Von Drittanbietern gibt es diverse Plug-Ins fur diese Harddisk-Recording-Programme, dieauf Surround-Formate abgestimmt sind, so zum Beispiel das ”360◦ Surround Tools“ Paketder Firma Waves, das Mixer-, Reverb-, Spatializer- und Dynamik-Plug-Ins fur die TDMSchnittstelle enthalt.32 Ein weiteres Beispiel ist das Reverb-Plug-In RealVerb 5.1 der FirmaKind Of Loud. Alle erhaltlichen Surround-Plug-Ins hier aufzufuhren, wurde den Rahmensprengen, 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 speziellerHardware realisiert werden. Da das Anwendungsfeld kaum kommerzielles Potential besitzt –wenn man von Surround-Joysticks fur Digitalpulte absieht –, handelt es meist um einzelneSpezialanfertigungen 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. Inder ursprunglichen Fassung von 1971 wurden die Lautstarken von vier Lautsprechern mittelsspannungsgesteuerter Verstarker (VCA) geregelt.33 Jeder VCA ist mit einem Oszillator ver-

31Inwieweit hier eine HRTF Filterung stattfindet, ist unklar. Leider stand mir das Programm nicht zurVerfugung, und MOTU bietet keinerlei Demoversionen an. Auch spricht die Produktbeschreibung voneinem vierten kartesischen Panner mit der Bezeichnung n-Panner ; worin er sich von dem im Bild gezeigtenTriPan unterscheidet, bleibt ebenfalls unklar.

32siehe http://waves.com/default.asp?url=content.asp?id=5633Die Erlauterung folgt den Ausfuhrungen in [Haller 1995], S. 77–90

14

1 Einfuhrung

bunden, der bestimmte Hullkurvenverlaufe realisieren kann. Durch zeitlich programmiertenAblauf der Hullkurven und Umschalten der Zuordnung von Kanalen zu Lautsprechern lassensich bewegte Phantomschallquellen realisieren. Das Gerat wurde im Laufe der Zeit an neuetechnische Entwicklungen angepaßt und die Kanalzahl erhoht. Haller griff die Ideen Chow-nings auf (vgl. Abschnitt 1.2), erweiterte den Signalweg im Halaphon um Harmonizer zurSimulation von Doppler-Effekten, einen Frequenz-Filter und ein Hallgerat. Die Hullkurvenkonnten schließlich graphisch an einem Bildschirm erstellt, abgespeichert und wieder gela-den werden. Fur den Einsatz des Halaphons in Konzert-Situationen kann der Ablauf livegesteuert werden. So kann eine Klangbewegung zum Beispiel direkt durch die Dynamik desMikrophonsignals 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 beschrankte Zahlvon Ausgangskanalen und die eingeschrankten Routingmoglichkeiten. Fur den Raumklang-einsatz mussen gerade die Verteilmoglichkeiten groß sein, wahrend die Zahl der Eingangs-kanale untergeordnet ist. Ein solches ”umgedrehtes“ Mischpult ist der Topoph24, den Sukan-dar Kartadinata fur die Installations-Projekte des Duos <sabine schafer // joachim krebs>gebaut hat.34 Ein Hauptrechner steuert mit einem Sequenzer sowohl die Klangerzeuger – zumBeispiel Sampler – als auch per MIDI einen zweiten Computer, der Raumbeschreibungen ineinzelne Steueranweisungen umrechnet, die wiederum per MIDI an den Steuercomputer desMischpults geleitet werden. Das Mischpult verteilt die Audiosignale mit Hilfe von VCAs, dievom Steuercomputer kontrolliert werden.

Ebenso verteilt die Raumklangsteuerung RKS.1 von Werner Schaller Ausgangssignale miteinem VCA-Mischer auf bis zu 24 Lautsprecher.35 Mit einem graphischen Editor konnen

”Figuren“ erstellt und per MIDI an den Mischer ubertragen werden. Die fur eine Figur ver-wendeten Kanale konnen beliebig gewahlt werden und mussen nicht benachbarte Lautspre-cher reprasentieren. Das Mapping von Kanalen auf Lautsprecher kann spater leicht angepaßtwerden.

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 uberMIDI ansteuerte. Einige Jahre fruher, 1988, wurde an der TU Berlin ein MIDI Mischergebaut, der bis zu 15 Eingangssignale auf 4 Ausgangskanale verteilen konnte. Um einenhohen Rauschabstand zu gewahrleisten, wurden dabei multiplizierende D/A Wandler stattVCAs eingesetzt. Das Programm arbeitete mit einem Nulldurchgangs-Detektor, der Knack-gerausche minimierte, die durch die grobe Rasterung der Lautstarke-Stufen entstanden. DerMIDI Mischer von Torsten Radtke wurde dann 1990 von Thomas Seelig um eine graphi-sche Benutzeroberflache erweitert, die auf einem Atari Computer lief. Dadurch konnten dieKlangquellen geometrisch plaziert und bewegt werden.36

34http://www.topophonien.de/2.5-w-d-topoph24.html35vgl. [Hein 1999], S. 10636[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-Ansatze fur Raumklang darstellen, von sich aus jedoch keine oder kaumgraphische Steuermoglichkeiten bieten. Im Zusammenhang mit der Entwicklung einer Steuer-oberflache 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 laßt, keine feststehende Soft-ware, sondern ein bestimmtes Modell von raumlicher Klangverteilung. Dieses wurde von demFinnlander 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 desStereo-Pannings auf eine beliebige zweidimensionale (2-D VBAP) oder dreidimensionale (3-DVBAP) Anordnung von Lautsprechern. Dabei erfolgt ein Amplitudenpanning uber die jeweilszwei respektive drei Lautsprecher, die der Klangquelle am dichtesten sind. VBAP liefertnur die Gain-Werte, die Programm-Umgebung, in der VBAP eingesetzt wird, muß selbstdafur sorgen, daß unterschiedliche Abstande der Lautsprecher zum Horer durch entspre-chende Delays nivelliert werden, damit als auditorischer Cue nur die Intensitatsunterschiedewirken.38 Die durch die Tupel oder Tripel aufgespannten Teilebenen bzw. -raume werden soberechnet, daß sie sich nicht uberschneiden und im Falle einer Bewegung der Klangquelleautomatisch ein weicher Ubergang von einem Teilraum in den anderen stattfindet.39

Da die Forschung ergeben hat, daß bei diesem Verfahren der Eindruck der Ausdehnung derQuelle (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 reprasentiert wird, wird dabei durch einen Trick aufrecht erhalten: Aus einer Quellewerden mehrere beieinander liegende Quellen gemacht, die intern summiert werden. Der Ab-stand dieser Quellen voneinander hangt von der Hohe der gewahlten Divergenz ab.40

VBAP als Plug-In allein ist noch keine vollwertige Raumklangsteuerung, allerdings laßt sicheine 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 Panellinks oben bewegt wird. Alternativ wird durch Klicken auf ”start rotation“ eine gleichmaßigeKreisbewegung ausgefuhrt.41 Als Klang wird ein Mono-Soundfile verwendet.

Grundsatzlich verarbeitet ein VBAP Objekt die Steuerdaten fur einen Quellklang; sollenmehrere Klange unabhangig bewegt werden, mussen weitere VBAP Instanzen erzeugt werden.

37http://www.acoustics.hut.fi/~ville/software/ . Dort ist auch noch ein alteres Standalone-Demo furSGI Computer zu finden.

38vgl. [Pulkki 2001], S. 16f39Im Falle der dreidimensionalen Anordnung wird der Klang im Ubergangspunkt nur noch von den zwei

Lautsprechern abgestrahlt, die beiden Teilraumen gemeinsam sind.40ebd., S. 1841vorausgesetzt naturlich, die Lautsprecher sind, wie im define_loudspeakers Objekt zu sehen, kreisformig

angeordnet.

16

1 Einfuhrung

Abbildung 1.3: VBAP Anwendung in Max/MSP

Das Lautsprecher-Setup im abgebildeten Patch ist kreisformig in der horizontalen Ebene (2D),daher wird die Bewegung in der Vertikalen (Elevation42) nicht benutzt. Die Divergenz laßtsich mit dem Schieberegler einstellen.

1.5.2 IRCAM Spat˜

Das Spat˜ Plug-In, von Jean-Marc Jot und Olivier Warusfel am IRCAM entwickelt,43 hateinen integrierteren Ansatz als VBAP. Das kommerziell vertriebene Paket besteht aus einerReihe zusammengehoriger Objekte fur Max/MSP oder IRCAM’s jMax. Insgesamt vier Stufendurchlauft ein Klang, bis er an den Ausgangskanalen 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 Ausgangskanalen geleiteten Klange mit einer optionalen Ent-zerrung und einstellbarem Delay und kompensiert so Nichtlinearitaten im Frequenzgangder Lautsprecher und deren Abstand vom Horer

Prinzipiell lassen sich die Objekte einzeln benutzen, beispielsweise kann ein Klang direkt inden Panner geschickt und dessen Output direkt an Lautsprecher gegeben werden, wenn manauf psychoakustische Modellierung und virtuellen Hall verzichten mochte. Etwas ungewohn-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 formatunabhangigen Hall, der dann in Pan~ je nach Aufstellung derLautsprecher mit einer Ambisonics-Matrizierung verteilt wird.

42im VBAP External das dritte Inlet43siehe [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 miteinstellbaren Winkeln. Fur Kopfhorer-Wiedergabe kann auch eine Binaural-Faltung benutztwerden. Die Positionierung der Quelle wird wie beim VBAP mit den Parametern Azimut undElevation eingestellt, allerdings laßt sich ein Quellsignal im Source~ Objekt verzogern undmit dem Raumprozessor so bearbeiten, daß Nahe- oder Ferne-Effekte entstehen.

Fur jede der vier genannten Signal-Stufen gibt es ein Low-Level Kontroll-Objekt, mit demdie wichtigsten Parameter eingestellt werden konnen, 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 enthalt

”perzeptions-basierte“ Parameter, die dann intern auf die DSP Parameter umgerechnet wer-den. Statt direkt die Raumgroße in physikalischen Einheiten bestimmen zu konnen, hat mansich dafur entschieden, qualitative Parameter zu benutzen.

Interessant ist vor allem der Subpatcher, der sich hinter der Bezeichnung radiation verbirgt.Er enthalt 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 richtungsabhangiger Abstrahlung bewegt wird.

Eine einfache Steueroberflache wird bereits in Form des Circ Patchers von Gerhard Eckelmitgeliefert. Bis zu drei Klangquellen konnen auf einem quadratischen Feld bewegt werden.Neben Azimut und Distanz wird auch die Abstrahlcharakteristik in Form eines Kreissegmentsdargestellt. Die Kontrolldaten von Circ konnen mit den Spat_Circ und Pan_Circ Patchesso umgerechnet werden, daß die Klangquelle entsprechend der Mausbewegung folgt und dieRadiation-Filterkurven verandert werden.

1.5.3 Spatialisierung mit CSound

Fur CSound existieren verschiedene Verraumlichungs-Opcodes. Neben dem beschriebenenVBAP 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 benotigt als Parameter die Position der Klangquelle (x, y, z). EineVerzogerung ist ebenfalls vorgesehen, diese laßt sich allerdings nicht dynamisch verandern– in diesem Fall muß ein anderer CSound Opcode wie vdelayx benutzt werden. Fur dieGenerierung von Nachhall kann eine spezielle Tabelle angegeben werden, die die Distanzenund Absorptionswerte fur die sechs Wande eines virtuellen kubischen Raumes beschreibt.

18

1 Einfuhrung

spat3d erzeugt ausgangsseitig die vier B-Format Signale W,X, Y, Z. Diese kann man sichals virtuelle Aufnahmen eines Soundfield-Mikrophons vorstellen, das aus drei orthogonalenAchter-Charakteristiken und einer Kugel besteht. Mit geeigneten Matrizierungsformeln lassensich daraus Signale fur beliebig angeordnete Lautsprecher gewinnen.44 spat3d beinhaltetaußerdem eine Stereo-Mixdown Option.

Der Binaural-Panner hrtfer benotigt eine Datei mit Impulsantworten fur die Kopfubertra-gungsfunktion. Das Format ist leider nicht dokumentiert, jedoch gibt es eine entsprechendeDatei auf dem CSound FTP Server. Die Synthese-Parameter sind Azimut und Elevation, eineentfernungsabhangige Dampfung 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 Komponistselbst umfangreiche Programmierarbeiten erledigen muß, ist also recht ubersichtlich. Auf dieEinfuhrung der DVD und die zunehmende Verbreitung kleiner Surroundsysteme in Wohn-zimmerkinos haben zwar alle Hersteller gangiger kommerzieller Software mit der Erweite-rung ihrer Produkte um Surround-Ausgabe-Moglichkeiten reagiert. Viel mehr als eine leichteExtrapolation der bisherigen Stereo-Technologien hat dabei aber kaum stattgefunden.

Eine Raumklang-Steuerung, die einfach zu bedienen ist, dabei jedoch großtmogliche Flexibi-litat bietet und den Benutzer nicht auf ein enges Anwendungsfeld beschrankt, die außerdemeinen kompositorischen Umgang mit Raumgestaltung nicht nur erlaubt sondern auch fordert,und mit der an bereits bestehende Klangsynthese-Software angeknupft werden kann, ist eineLucke, 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 gegenwartigen 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 zuganglich sind unddie oft in gemeinsamer Arbeit mehrerer Programmierern entstehen. Zu nennen sind CSound– an Universitaten entstanden, war es bereits vor der Entwicklung im Open-Source Ver-fahren kostenlos zuganglich –, SuperCollider, das im Zuge des Wechsels des Autors JamesMcCartney zu Apple Inc. in ein Open-Source Projekt umgewandelt wurde, zahlreiche kleinereProgramme wie RTcmix, und auch ein Teil der IRCAM Software – vielleicht am beachtlich-sten, wenn man die ansonsten eher verschlossene Vertriebspolitik bedenkt –, darunter diegraphische Klangsynthese-Sprache jMax und eine Umgebung fur algorithmische Komposi-tion, OpenMusic. Fur das Betriebssystem Linux, das selbst Open-Source ist, entwickelt sichmomentan eine eigene Audio Community. Mit den Soundeditoren snd und Audacity, demMIDI Sequenzer Rosegarden und dem Harddisk-Recording-Tool Ardour, den plattformuber-greifenden Klangsynthese-Programmen jMax, SuperCollider, CSound und Pure Data sowieder Unterstutzung professioneller Soundkarten u.a. von RME steht eine gunstige Arbeits-umgebung bereit.

Eine logische Folge daraus ist, daß Programmierer viel mehr Moglichkeiten haben, Schnitt-stellen zwischen diesen Programmen zu entwerfen. Auch kommerzielle Musiksoftwarefirmensind sich bewußt, daß sie den Mehrwert ihrer gewerblich angebotenen Programme erheblichsteigern konnen, 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 Rechnerplattformenund uber die Basisapplikation Cubase hinaus durchgesetzt hat.

Der Wunsch, mehrere Audioprogramme miteinander zu verbinden, manifestiert sich seitdemin zahlreichen Schnittstellen. Im kommerziellen Sektor ist ReWire zu nennen, einer gemein-samen Entwicklung der Firmen Propellerhead und Steinberg. Im Open-Source Bereich ist einahnlicher Versuch mit dem virtuellen Patchsystem Jack zu beobachten, einer zunachst aufLinux entwickelten Audiotreiber-Schnittstelle, die mittlerweile auch auf den anderen Rechner-plattformen verfugbar ist und die u.a. von SuperCollider, jMax, PD, Ardour, Rosegarden undsnd unterstutzt wird. Die durchschlagendste Entwicklung im Open-Source Bereich dagegenbeschaftigt sich nicht direkt mit dem Transport von Audiostromen, sondern der gegenseitigenKontrolle und Highlevel-Steuerung von Programmen. Es handelt sich um ein Kommunika-tionsprotokoll mit dem Namen Open Sound Control (OSC), das von Matt Wright und AdrianFreed am Zentrum fur Neue Musik und Audiotechnologie CNMAT (Universitat Berkeley)entwickelt wurde.

20

2 Entwicklung des Programms Meloncillo

In gewisser Weise als inoffizieller Nachfolger von MIDI1 gedacht, werden in OSC mit einemTextkommando beginnende Nachrichten versandt. Definiert ist nur die Syntax, welche kon-kreten Befehle eine Applikation versteht, ist dabei nicht festgelegt. OSC eignet sich damitbesonders fur offene Systeme, die der Benutzer zum Teil oder vollstandig selbst programmie-ren kann, wie SuperCollider, dessen Synthese-Engine in der Version 3 vollstandig uber OSCgesteuert wird und das damit als Paradebeispiel fur OSC gelten kann, Max/MSP oder PureData (PD). Damit wird es zum ersten Mal moglich, daß zum Beispiel ein Max/MSP PatchTeile oder die gesamte Klangsynthese an SuperCollider delegiert und sich auf die graphischeOberflache als wesentliche Starke von Max konzentrieren kann.2 Und dies, ohne daß der An-wender einen C-Compiler bedienen und eigene sogenannte Externals oder Unit-Generatorenprogrammieren muß.

Ein wichtiger Aspekt in der Entwicklung neuer Musiksoftware wird damit die Anstrengungsein, Starken 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 Oberflache und Signalverarbeitung. Dabei weitgehende Beschrankungauf eine graphische Benutzeroberflache und Ruckgriff auf externe klanggenerierendeProgramme

• Abstraktion der Oberflache 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 mochten

• Betriebssystemunabhangige Implementierung

Desweiteren wurden folgende Entscheidungen zur Programmarchitektur gefallt:

• Komplementaritat aus zwei grundlegenden Objekttypen

• Komplementaritat aus Echtzeit und Offline Anwendung mit Schwerpunkt auf Nicht-Echtzeit-Betrieb

• Diskretisierung von Datenstromen

Die genannten Aspekte werden im folgenden erlautert:

2.2.1 Trennung von Oberflache und Signalverarbeitung

Da fur die Entwicklung einer graphischen Benutzeroberflache und eines Signalverarbeitungs-Kernels grundsatzlich andere Programmiertechniken verwendet werden – weil auch verschie-

1Ein Uberblick uber die MIDI Schnittstelle ist zum Beispiel in [Ruschkowski 1998], S. 371–412 zu finden.2Tatsachlich war

”Pyrite“, ein Vorlaufer 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ß großere Ande-rungen in einem Teil vorgenommen werden konnen, ohne in den jeweils anderen Part eingrei-fen zu mussen. Dieselbe Oberflache kann moglicherweise mit unterschiedlichen austauschbarenSignalverarbeitungs-Modulen arbeiten und umgekehrt. Außerdem konnen Alterungserschei-nungen abgefedert werden:

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

Die gegenwartigen Klangsynthese Programme sind vom Gesichtspunkt der Signalverarbei-tung sehr ausgereift und effizient. Dies kann dagegen nicht von ihren Benutzeroberflachengesagt werden, wenn man SuperCollider oder CSound betrachtet. Max/MSP hat eine sehrausgereifte Benutzeroberflache, die Programmierung großer angelegter Patches kann jedochleicht unubersichtlich werden, und das Programm ist sehr stark auf den Echtzeit Betrieb aus-gerichtet. Von normalen Desktop Anwendungen erwartete Features wie Drag-and-Drop oderClipboard Austausch sind hochstens rudimentar vorhanden. Eine klare Trennung von einemPatch als Instrument und den eingestellten Parametern als Dokument oder Stuck ist nichtvorhanden.

Die zu entwickelnde Software soll sich aus dieser Uberlegung heraus weitgehend auf die Ober-flache konzentrieren und im Falle der Signalverarbeitung die Starken der vorhandenen Pro-gramme nutzen.

2.2.2 Abstraktion vom Synthesemodell

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

Das bedeutet zum Beispiel, daß Meloncillo weder zu wissen braucht, in welchem exaktenFormat und in welcher Reihenfolge die Syntheseengine die Quelldaten benotigt, noch, ob beider Synthese eine reine Amplituden-Matrizierung oder eine Kombination mit Filtern oderDelays verwendet wird. Dies ist die Voraussetzung dafur, daß verschiedene Programme alsSyntheseengines benutzt werden konnen, ohne auf deren Eigenheiten und Starken verzichtenzu mussen.

3Wahrend es in der Signalverarbeitung vor allem um Recheneffizienz und -genauigkeit geht, muß eine Ober-flache in erster Linie Anforderungen an Ergonomie und Konsistenz mit betriebssystemspezifischen Style-Guides erfullen. Die Programmierung des Oberflache legt grundsatzlich viel starkeres Gewicht auf dieWartbarkeit und Flexibilitat des Quellcodes, auch wenn dies nicht immer mit bestmoglicher Performanzvereinbar ist. Da das Event-Handling nicht auf exaktes Timing angewiesen ist, konnen hier andere Ent-wurfsschemata verwendet werden.

4[Zmolnig et al. 2003]. Der Autor weist auch auf den Vorteil hin, Oberflache und Audio-Engine auf verschie-denen Rechnern laufen lassen zu konnen.

22

2 Entwicklung des Programms Meloncillo

Diese Abstraktion ist zugleich der Garant dafur, daß ein Komponist mit Meloncillo neue Ideenverwirklichen kann, ohne daß jede Idee in der Programmstruktur a priori vorgedacht wordensein muß. Das weiche Element zwischen Oberflache und DSP Instanz federt die Erfordernisab, bei Entwurfen zu neuen Klangsynthese-Verfahren wieder in den Quelltext von Meloncilloeingreifen 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 – odermusikalische Strukturen mit Hilfe von Algorithmen zu erzeugen. Sie besitzen Programmier-erfahrung und begegnen rein graphisch orientierten Programmen mit Skepsis. Die andereGruppe entwickelt ihre kompositorischen Vorstellungen eher unabhangig von den techni-schen Rahmenbedingungen der Software und sucht nach Mitteln, diese Vorstellungen mitmoglichst intuitiv zu bedienenden Programmen umzusetzen. Der Gedanke, asthetische Ideeningenieursmaßig auf technische Ablaufe herunterzubrechen, schreckt sie ab.

Die graphische Oberflache soll so gestaltet werden, daß sie von Benutzern bedient werdenkann, deren Computer-Kenntnisse nicht viel weiter reichen als notig ist, um mit ProTools zuarbeiten. Der tiefere Eingriff in das Programm und die Verknupfung mit anderen Program-men wie CSound oder SuperCollider soll durch Definition von Plug-In Schnittstellen geoffnetwerden.

2.2.4 Unabhangigkeit vom Betriebssystem

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

Die momentan wichtigsten Betriebssysteme im Musikkontext sind Mac OS X, Linux undWindows XP. Mit den meisten Sprachen laßt sich plattformunabhangig programmieren.Schwierigkeiten entstehen dann, wenn uber eine reine Consolen-Ausgabe hinaus zum Beispieleine graphische Oberflache oder Interaktion mit der Computer-Peripherie (Audio-Hardware)gewunscht sind. Folgende Moglichkeiten stehen zur Verfugung:

23

2 Entwicklung des Programms Meloncillo

• eine Sprache mit plattformunabhangigen Bibliotheken wie Java.

• kommerzielle Produkte wie Xanalysis LispWorks5, die auf den drei genannten Platt-formen einschließlich der Bibliotheken kompilieren. Der Preis von LispWorks betragt1000 $, eine Weiterentwicklung als Open-Source Projekt scheidet damit auch aus.

• eine plattformunabhangige Sprache wie ANSI C oder C++, die mit freien Bibliothekengelinkt wird. Verbreitet ist Trolltech’s QT Bibliothek6, die allerdings entweder unterder GPL (siehe Abschnitt 3.1) oder kostenpflichtig lizensiert ist. Eine Alternative istdie Verwendung von Tk/Tcl; die Flexibilitat und Asthetik der erstellten GUIs ist eherbescheiden.7

2.2.5 Zwei grundlegende Objekttypen

Bei der Betrachtung der vorhandenen Raumklang-Software fallt auf, daß die graphische Ober-flache meist zwei Typen von Objekten kennt: Klangquellen und Lautsprecher. Diese korre-spondieren im Signalfluß mit den Eingangen und Ausgangen. Die Beschrankung auf zweiinteragierende Objekte tragt dazu bei, daß die Struktur des Programmes sehr klar bleibt. Diefeste Rollenzuteilung steht einer flexiblen Anwendung jedoch im Wege. Diese zwei Objektesollen also rollenunabhangig sein und dennoch komplementare, sich erganzende Eigenschaftenbesitzen:

• Ein Receiver ist ein statisches Objekt, das eine flachenformige Ausdehnung besitztund seine Charakteristik – genannt Sensitivitat – aus einer Funktion des Ortes aufdieser Flache gewinnt.

• Ein Transmitter ist ein punktformiges Objekt, das seine Charakteristik aus einerBewegung als Funktion der Zeit gewinnt.

Die Bezeichnungen wurden aus Ermangelung besserer Begriffe gewahlt und sollen nichtdaruber hinweg tauschen, daß ein Receiver keinesfalls die Rolle eines passiven und ein Trans-mitter keinesfalls die Rolle eines aktiven Elements ubernehmen muß. Vielmehr stehen beidein einer Beziehung zueinander, die je nach gewahltem Synthesemodell nutzbar gemacht wer-den kann. Obgleich zum Beispiel die Receiver rein optisch den virtuellen Lautsprechern vonΣ 1 ahneln, konnen sie auch Klangfelder reprasentieren, die durch Transmitter als ”bewegteMikrophone“ 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, dieeinzelnen Sektionen mussen nicht chronologisch gewachsen sein. Der Vorteil von schnellenComputern – der auch ein Nachteil sein kann – ist die Moglichkeit, unmittelbar die Re-sultate eines halbfertigen Stuckes anhoren zu konnen. 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 Oberflache 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 undbeispielsweise Teile verkurzt oder umgruppiert werden, und zugleich in Echtzeit kontrolliertwerden kann, ob das Ergebnis den Wunschen entspricht. Da vielfach auch eine gestischeBeschreibung von raumlichen Bewegungen gewunscht ist, sollen solche Gesten in Echtzeitaufgezeichnet werden konnen. Ein Offline Modus ist auch vom signalverarbeitungstechni-schen Gesichtspunkt wunschenswert, weil dadurch Modelle realisiert werden konnen, derenBerechnung in Echtzeit aus Grunden der CPU-Kapazitat derzeit ausscheidet.

2.2.7 Diskrete Datenstrome

Die Funktionswerte der in Abschnitt 2.2.5 genannten Basisobjekte konnen analytischer unddiskretisierter Natur sein. Eine analytische Beschreibung eines Receivers ware etwa: Die Sen-sitivitat ist umgekehrt proportional zur Entfernung (f(d) ∼ 1/d). Eine diskretisierte Beschrei-bung ware: gegeben sei eine Tabelle mit 1000 Punkten, die durch Abtastung der Funktionf(dn) = 1/dn; dn = n · extent/1000 entstanden ist. Die Sensitivitat an einem Punkt mit demAbstand d vom Receiver entspricht dem Tabellenwert mit dem Index round(d ·1000/extent).

Entsprechend kann die Bewegung eines Transmitters analytisch durch eine beliebige Kettevon 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 ware eine Abtastung dieser analytischenFunktion an gleichmaßig voneinander entfernten Stutzpunkten.

Der Vorteil einer analytischen Beschreibung ist die Exaktheit, denn durch die Abtastungentstehen zwangslaufig Aliasing-Fehler. Eine analytische Beschreibung ist auch viel kom-pakter, denn im vorangegangenen Beispiel wird die Linie durch zwei Punkte beschrieben,wahrend eine Abtastung bei 100 Hz fur die Bewegung uber zehn Sekunden bereits 1000Punkte benotigt. Soll zu einem spateren Zeitpunkt die Linie verkurzt oder verlangert oderverlagert werden, so entstehen keine Artefakte und die gesamte Komposition bleibt sehr

”sauber“.

Die Abtastung hat jedoch entscheidende Vorteile: Der Datenstrom kann an beliebigen Stellenzerschnitten und umgeordnet werden, ohne daß dadurch kompliziertere Berechnungen notigsind. Bei einer Beschreibung mit Hilfe von Breakpoints mussen in diesem Fall neue Punkte ein-gefugt werden. Soll jetzt zusatzlich eine Sektion rotiert werden, beginnt die Umrechnung derBreakpoint-Funktionen kompliziert zu werden, es sind trigonometrische Funktions-Abschnittenotig. Soll weiterhin eine Unregelmaßigkeit erzeugt werden, kann dem diskreten Datenstromeinfach Rauschen hinzugefugt werden; in der Breakpoint-Darstellung ist dies nicht moglich,es mußten also zahlreiche zufallige Punkte erzeugt werden, womit man de facto bei einer ge-sampelten Funktion endet und zugleich einen immensen Verwaltungsaufwand hat. Der Vorteilder diskreten Datenstrome ist ferner, daß der Datendurchsatz unabhangig von der Editierungkonstant bleibt. Aus diesen Grunden soll zumindest den Transmittern ein diskretes Modellzugrundegelegt werden. Fur die Receiver spielt die Wahl eine eher untergeordnete Rolle.

Obwohl bekannt ist, daß das Ohr eine relativ schlechte raumliche Auflosung besitzt, sollendie Samples der Transmitter-Trajektorien eine Auflosung von 32-Bit Floating Point und einebeliebige Abtastrate haben. So wird auch durch wiederholte Transformationen die Signal-qualitat nicht fruhzeitig beeintrachtigt. Der Benutzer kann die Rate seinen Wunschen gemaßanpassen und beispielsweise mit Modulationen im Audio-Frequenzbereich experimentieren.

25

3 Programmarchitektur

Konventionen

Im Fließtext werden programmiersprachliche Schlusselworter, Namen von Klassen, Paketenund Variablen in Schreibmaschinenschrift gesetzt. In den Klassendiagrammen wird eineAuszeichnung nach Abbildung 3.1 vorgenommen.

3.1 Sprache und Arbeitsumgebung

Abstract Class

Interface

instanceof

subclassimplementor/

Class

Collection

instance variable

Abbildung 3.1: Legende

Meloncillo wurde mit Java 1.4.2 SE entwickelt1. Als integrierte Pro-grammierumgebung (IDE) diente Apple Xcode Version 1.12. DieEntwicklung fand auf einem G4/800 mit Mac OS 10.3 statt.

Ein Kernelement von Java ist jedoch die Moglichkeit, vollkommenplattformunabhangige Programme zu erstellen. Voraussetzung ist,daß auf der Zielplattform eine sogenannte Virtual Machine (VM)verfugbar ist. Die VM enthalt einen Just-in-Time (JIT) Compi-ler, der die vorkompilierten Java Klassen in dem Moment, in demsie benotigt werden, ubersetzt. Eine Vielzahl der Bibliotheken desStandard-API arbeitet sehr eng mit nativen (plattformabhangigen)Bibliotheken zusammen – dies gilt beispielsweise fur die Graphik-Ausgabe –, so daß die Performance von Java Applikationen im all-gemeinen sehr hoch ist. Als fur Echtzeitanwendungen hinderlichwird oft angesehen, daß der Programmierer keine Kontrolle uberden automatischen Garbage-Collector hat3. Tatsachlich entschei-dender ist das Fehlen von prazisen Clock Objekten, die erst furkommende Java Versionen angekundigt sind. Dieses Problem wirdbei der Echtzeit-Schnittstelle erlautert.

1Zur Sprachspezifikation von Java siehe [Gosling et al. 2000]. Diese hat sich uber die verschiedenen Versionenpraktisch nicht geandert, 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 Vorgangerversio-nen bestehen stets aus der Erweiterung der Bibliotheken. Wichtige Bibliotheken von Version 1.4, auf diein Meloncillo zuruckgegriffen wird, sind u.a. die java.util.prefs (fur Preferences) und java.nio (New-I/O fur Eingabe- und Ausgabestrome) Packages. SE ist die Standard-Edition von Java, deren SDK freierhaltlich ist, daneben gibt es noch eine Enterprise-Edition (EE), die hier jedoch keine Rolle spielt.

2kurz vor Fertigstellung wurde auf Version 1.5 gewechselt3Im Gegensatz zu C++ werden in Java nur in Ausnahmefallen finalize Methoden, d.h. Methoden zur Frei-

gabe von Ressourcen nicht mehr benotigter 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 unregelmaßigen Intervallen und konnen damit das Echtzeit-Timing beeintrachtigen.

26

3 Programmarchitektur

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

Java wurde als Sprache gewahlt, weil der objekt-orientierte Ansatz (OOP) sich hervorragendfur die Entwicklung modularer Systeme eignet. Da der Hauptaspekt von Meloncillo auf derProgrammierung der graphischen Oberflache liegt, spielt Java hier mit den TechnologienSwing 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 undeine Vielzahl von Layout-Managern6 an. Fur das tatsachliche Aussehen der GUI Elementewird ein austauschbares Look-and-Feel verwendet, so daß sich Java Programme an die Optiknativer Programme anlehnen konnen.

Java2D ist eine Graphikbibliothek fur zweidimensionale Oberflachen, auf die spater nochgenauer 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/OutputFunktionen und Buffer) zuruckgegriffen werden. Durch die automatische Garbage-Collectionund umfangreiche Debugging Moglichkeiten zur Laufzeit (Java Reflection) wird die Pro-grammentwicklung und -wartung erheblich erleichtert. Nicht zuletzt ausschlaggebend fur dieSprachwahl 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 Programmsich besser an das Look-and-Feel von Mac OS anpassen kann, ohne dadurch seinePlattformunabhangigkeit 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 erlautert.

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

4http://www.blackdown.org/java-linux/java2-status/index.html5Events sind hier Ereignisse, die durch Aktionen des Benutzers an GUI Elementen ausgelost werden. EinActionEvent kann z.B. durch Klicken auf einen Button ausgelost werden, ein ComponentEvent durch Ver-großern eines Objekts bei Anderung der Fenstergroß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 Abhangigkeit von der Fenstergroße, Schriftgroß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 diebekanntere General Public License (GPL) die Rechte des Benutzers – er darf zum Beispiel die Softwareselbst modifizieren –, hat jedoch aus Sicht des Programmierers, der diese Bibliothek benutzen will, denVorteil, 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 zusammengehorige Klassen werden zu Paketen (packages) zusammengefaßt, dabeiwird ublicherweise eine durch Punkte getrennte, von links nach rechts absteigende Hierarchiebenutzt, die an Internet-URLs anlehnt ist. Dadurch konnen spater andere Pakete erganztwerden, ohne daß Namenskonflikte auftreten. Das hierarchisch oberste Paket (root) heißtde.sciss.meloncillo. Es enthalt die Klasse Main, die von der VM gestartet wird und dieKlasse Session, die das Dokument des Programms beschreibt (Abschnitt 3.3). Die unterge-ordneten Packages sind:

• debug : Fehlerkontrolle wahrend der Programmentwicklung

• edit : Editierungen, die ruckgangig gemacht werden konnen (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 Benutzerhat es stets mit einem aktuellen Dokument zu tun, das alle relevanten Datenobjekte enthalt.Diese Objekte werden beim Loschen des Dokuments entfernt, beim Laden des Dokumentsausgetauscht, 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.2gezeigt. Diese sind direkt als offentliche Instanzvariablen zuganglich.

9Ein Gegenbeispiel fur eine Multi-Document-Application ist Emagic Logic Pro, bei dem grundsatzlich be-liebig viele Dokumente gleichzeitig geoffnet sein konnen. Dies erhoht allerdings die Anforderungen an denProgrammierentwurf erheblich, so daß auf ein MDA Design verzichtet wurde.

10Collection ist ein grundlegendes, im Paket java.util enthaltenes interface, das die Gruppierungvon Elementen beschreibt und Methoden zum Hinzufugen und Entfernen von Elementen definiert.ReceiverCollection und TransmitterCollection enthalten ahnlich benannte Wrapper-Methoden fur dieGruppe von Receivern und Transmittern, die sie verwalten.

28

3 Programmarchitektur

trns

Receiver

AbstractReceiver

rcv

receiverCollection

transmitterCollection

timeline

Session

selectionSpan

visibleSpan

position

length

rate

Timeline

mte

rotationTable

distanceTable

SimpleTransmitter SimpleTransmitterEditor

TransmitterEditor

AbstractTransmitterEditor

SigmaReceiver SigmaReceiverEditor

AbstractReceiverEditor

ReceiverEditor

collTransmitters

TransmitterCollectionReceiverCollection

collReceivers

collSelection collSelection

Transmitter

AbstractTransmitter

Abbildung 3.2: Session Struktur

Sowohl Session, als auch ReceiverCollection, TransmitterCollection und Timelineimplementieren 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 oderseine Elemente aus einer XML Node regeneriert werden konnen13. Diese Methoden werdenbenutzt, um die Session abzuspeichern und zu laden. XML bietet zahlreiche Vorteile, darunterdie 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 Fahigkeiten handelt, die nicht spezifisch fur eine bestimmte Klassesind, sondern eher die Schnittstelle zu einer anderen Technologie beschreiben. Wahrend eine Klasse nureine Superclass beerben kann, kann sie beliebig viele Interfaces implementieren. Das zweite Interface, dasSession implementiert, heißt FilenameFilter und ist im Paket java.io definiert. Es besagt, daß Session

die Fahigkeit besitzt, Dateinamen nach einem bestimmten Prinzip zu filtern. Dies wird benutzt, um beimOffnen 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 Entwicklungeiner DTD ist ein nicht ganz triviales Unterfangen, und Meloncillo Sessions benutzen imMoment noch keine explizite DTD.

Wird die Session abgespeichert, enthalt die XML Datei die entsprechenden Reprasentationender Session Objekte und der Collection-Elemente – Receiver und Transmitter –, die ihrer-seits das Interface unterstutzen. Mit abgespeichert werden ferner Programm Preferences, diefur die Session relevant sind. Große binare Datenmengen wie die Trajektorien der Transmit-ter konnen nicht zufriedenstellend mit XML dargestellt werden und werden daher in einemspeziellen Unterordner unabhangig 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 dieseCollection-Operationen in Hinblick auf eine Untergruppe der Receiver, namlich die Gruppeder ausgewahlten Receiver. Dies bezieht sich auf die graphische Oberflache, auf der der Be-nutzer ein oder mehrere Receiver auswahlen kann. Die ausgewahlten Receiver werden optischanders dargestellt und stellen die Untergruppe der Receiver dar, auf die Editierungs-Befehlewie Ausschneiden, Kopieren, Umbenennen oder Bewegen wirken. Die selektionsbezogenenMethoden beginnen mit dem Term selection. Kann zum Beispiel mit ReceiverCollection.contains() befragt werden, ob ein Receiver in der Gruppe aller Receiver enthalten ist, soliefert ReceiverCollection.selectionContains() Auskunft daruber, ob ein Receiver derGruppe der ausgewahlten Receiver angehort usw.

Die eigentlichen Receiver Objekte werden fast ausschließlich uber das Receiver Interfaceangesprochen, 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 denAbstraktionsgrad, 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 kreisformige Ausmaßehaben muß und seine Charakteristik aus einer Distanz- und einer Rotationstabelle schopft,sondern nur zu definieren,

• daß der Receiver uber einen Ankerpunkt und ein außeres, seinen Umriß umspannendesRahmenrechteck 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 ortsabhangige Sensitivitat besitzt (getSensitivities).points ist eine Liste von kartesischen Koordinaten; die Sensitivitaten 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 vollstandig implementieren zu mussen,wurde die Klasse AbstractReceiver entworfen, von der dann spezielle Receiver wie derspater beschriebene SigmaReceiver erben konnen.

Die File bezogenen Methoden waren notig, um das Laden und Abspeichern der Daten,die den Receiver konstituieren, zu ermoglichen. Sie hatten vielleicht besser in einem eigenenInterface untergebracht werden sollen.

DataFlavor gehort zum Paket java.awt.datatransfer und beschreibt die Moglichkeit, einObjekt fur Clipboard- oder Drag-and-Drop Operationen zu formatieren. Das Feld receiver-Flavor beschreibt das Wrapper-Format, mit dem Receiver beim Benutzen der FunktionenAusschneiden / Kopieren / Einfugen dargestellt werden.

3.5 Transmitter, TransmitterCollection

Die theoretische Komplementaritat von Receivern und Transmittern soll auch in der Pro-grammstruktur deutlich werden. TransmitterCollection beschreibt damit spiegelbildlichalle Gruppierungsfunktionen, die in ReceiverCollection vorhanden sind, wendet sie jedochauf die Transmitter einer Session an. Entsprechend ist Transmitter ein Interface, das ver-schiedene konkrete Transmitter mit unterschiedlichen Datenmodellen unterfuttern konnen:

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 oderFlachen 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 spate-ren Programmversion andere Datenmodelle zu verwenden als das gegenwartige der KlasseSimpleTransmitter, 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, vonder konkrete Transmitter erben konnen.

3.6 Timeline

Das Timeline Objekt beschreibt die Lange der Session, die gegenwartige Zeitposition und dieSample-Rate der Trajektorien. Sie verwaltet zwei Teilbereiche, selectionSpan – der aktuellausgewahlte 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 moglich wissen, sie kennennur die offentlich gemachten Methoden.15 Um die Flexibilitat zu wahren, sollte die Interaktionzwischen Objekten ”von unten“ realisiert werden; das bedeutet, daß ein Objekt sich moglichstselbst darum kummern sollte, an benotigte Informationen zu gelangen, statt diesen Vorgangdurch 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 Schnittstellean, uber die sich Interessenten registrieren lassen konnen. Die einzig erforderliche Gemeinsam-keit dieser Interessenten ist die Implementierung eines Listener Interfaces. Hier das Beispieldes ReceiverCollectionListeners:

Quelltext 3.4: ReceiverCollectionListener.java (receiver package)public interface ReceiverCollectionListenerextends 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 Veranderung eines Receivers oder einer Gruppe vonReceivern auftritt, so werden alle angemeldeten Listener benachrichtigt, indem eine der imQuelltext 3.4 gezeigten Callback-Methoden aufgerufen wird. Klickt der Benutzer zum Beispieleinen Receiver an, so stellt dies eine Veranderung der Gruppe der selektierten Receiver dar,

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

32

3 Programmarchitektur

und die Methode receiverCollectionSelected jedes einzelnen Listeners wird aufgerufen.Genauere Informationen zu dem Ereignis kann er dem ReceiverCollectionEvent Argumententnehmen.

Der Vorteil von diesem Konzept, das in ahnlicher Art auch von den Java AWT und Swing Pa-keten verwendet wird, ist die Moglichkeit, daß sich neue Objekte dynamisch in die Eventverar-beitung einklinken konnen. Alle Objekte, die Events generieren – neben den drei Bestandtei-len der Session sind dies vor allem GUI Elemente wie VectorEditor usw. –, implementierendas Interface EventManager.Listener. Sie generieren ein Hilfsobjekt, den EventManager,der den eigentlichen Dispatcher darstellt, das heißt die Verwaltung der Listener und desEvent-Queue ubernimmt und neu eingetroffene Ereignisse weiterleitet. Um das Multitaskingberechenbar zu machen, werden in Analogie zum Event System von Java Swing alle Eventsvon 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 zunachst innerhalb des Event Threads bearbeitet. Preferences Anderungen, die zumin-dest in der Apple VM einen separaten Dispatcher verwenden, werden mit der HilfsklasseLaterInvocationManager ebenfalls an den GUI Event Thread delegiert.

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

Ein weiterer wichtiger Thread ist der Transport, ein Objekt, das die Echtzeit-Verarbeitungverwaltet. Dieser Thread wird zum Programmstart generiert und pausiert, wenn der Trans-port gestoppt ist; wahrend des Wartens auf Transport-Befehle findet keine CPU Belastungstatt. Damit der Rhythmus der Uhr-Ticks im Echtzeit-Betrieb nicht beeintrachtigt 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 eigenstandige Threads ist der Empfang von OSC Nachrichten,der von der Klasse OSCReceiver bewerkstelligt wird. Der Thread pausiert automatisch, wennkeine Nachrichten eintreffen. Erreicht ein neues Datagramm den Empfanger, wird der Thread

16Threads sind nebenlaufige 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 konnen. In Java ist ein bestimm-ter Thread – der Event Dispatcher Thread – fur die gesamte GUI Verwaltung zustandig, einschließlichder Bekanntmachung von Eingabe-Ereignissen (z.B. Mausbewegungen, Button-Klicks) und dem Aufrufvon 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 wahrenddessen angehalten, so daß Veranderungen erst im Anschluß weitergeleitetwerden. Zum Beispiel werden beim Offnen einer Session viele verschiedene Anderungen an der Grup-pe der Receiver und Transmitter vorgenommen. Diese Veranderungen werden weitergeleitet, wenn derLade-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.2beschrieben.

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

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

34

4 Graphische Benutzeroberflache

4.1 Surface : zweidimensionale Momentansicht

Das graphische Hauptelement der meisten Raumklangsteuerungen ist eine schematische Sichtauf das raumliche 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. Wahrendeinige Programme auch dreidimensionale Raumansichten bieten1 oder als Middleware fur Vir-tual Reality 3D-Applikationen fungieren2, folgt die planare Editierung aus der ausschließli-chen Zweidimensionalitat gegenwartiger Computersysteme (Bildschirm, Maus/Joystick/Tablett).

Die Surface Klasse ist zustandig fur die 2D-Sicht in Meloncillo. Eine solche Darstellung istin Abbildung 4.1 abgedruckt. Receiver und Transmitter werden durch kleine rote respek-tive grune Fadenkreuze dargestellt, die mit dem Namen der Objekte versehen sind. DieUmrißlinie der Receiver ist gestrichelt dargestellt. Optional wird die Sensitivitat der Re-ceiver in Grauschattierungen gezeigt. Wird die Zeitachsen-Position verandert, bewegen sichdie Transmitter entsprechend. Um die Trajektorien besser beurteilen zu konnen, werden sieoptional eingeblendet: Ein gruner gestrichelter Pfad stellt den Verlauf der Trajektorien derausgewahlten Transmitter im ausgewahlten Zeitabschnitt dar. Die Auflosung, d.h. die Zahlder Stutzpunkte, wird automatisch heruntergeschaltet, wenn der Zeitabschnitt großer wird,um eine ausreichende Geschwindigkeit der Graphikdarstellung zu gewahrleisten. Das Konzeptder stufenweise aufgelosten Trajektoriendaten wird im Abschnitt 4.2.1 erlautert.

Alle Graphikbefehle sind im Rahmen von Java2D realisiert, dadurch laßt sich das SurfaceFenster stufenlos vergroßern. Alle Objektkoordinaten werden in einem virtuellen Raum ausge-druckt, der auf die Große 1.0×1.0 normalisiert ist. Dazu implementiert Surface das InterfaceVirtualSurface:

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 [Zmolnig 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 Anwendunggeschrieben wurde.

35

4 Graphische Benutzeroberflache

Abbildung 4.1: Surface Fenster Abbildung 4.2: Hilfspaletten

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

Mit einer AffineTransform lassen sich geometrische Skalierungen, Scherungen und Rota-tionen beschreiben. Diese konnen auf Point2D und Shape Objekte angewandt werden. Diegraphische Realisation findet in einem Graphics2D Kontext statt. Die Methode fill zeich-net dabei mit beliebiger Farbe, Verlauf oder Muster die Flacheninhalte von Shapes. DieMethode draw zeichnet mit beliebiger Strichstarke und Form die Umrißlinie von Shapes.Das Graphics2D Objekt bietet die Moglichkeit, sogenannte RenderingHints zu setzen unddamit die Qualitat der Graphik, zum Beispiel bei Skalierungen oder der Verwendung vonAnti-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 dannrelativ schnell wiederholt gezeichnet werden kann. Die Darstellung der Receiver-Sensitivitat

36

4 Graphische Benutzeroberflache

selbst ist eine grob aufgeloste Bitmap-Graphik (8-Bit Graustufen), deren Berechnung relativlangsam ist.

4.1.1 Hilfs-Paletten und Werkzeuge

In der Abbildung 4.2 sind zwei Hilfs-Paletten zu sehen, die weitere Funktionalitat fur dieSurface und andere Objekte bereitstellen. Die ObserverPalette stellt kontextsensitive Text-Informationen dar. Sie enthalt verschiedene Karten, die in Abhangigkeit von der Benutzer-Aktion umgeschaltet werden. Wahlt der Benutzer beispielsweise einen Receiver aus, wirddie ”Rcv“-Karte angezeigt. Sie enthalt die exakten Koordinaten des Anker-Punktes (Mittel-punktes) des Receivers, seine Ausdehnung und seinen Namen. Diese Angaben konnen durchTexteingabe geandert werden. Durch Anwahlen einer Gruppe von Receivern konnen diesegleichzeitig verandert und ausgerichtet werden. Die weiteren Karten des Observers betreffendie ausgewahlten 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. Vonlinks nach rechts zu sehen sind

• Auswahl-Werkzeug : Es dient der Auswahl und dem Bewegen von Receivern

• Linien-Werkzeug : Zum Generieren linearer Trajektorien-Verlaufe

• Kurven-Werkzeug : Generiert Trajektorien-Verlaufe 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 unabhangig vomTransport. 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 Kontrollpunktedie Form anpassen. Mit Tastaturbefehlen (Escape und Return) wird die Geste abgebrochenoder ausgefuhrt (gerendert). Uber eine spezielle Tastenkombination kann eine Serie von zu-sammenhangenden Segmenten gezeichnet werden.

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

37

4 Graphische Benutzeroberflache

Quelltext 4.2: AbstractGeomTool.java (gui package)public abstract class AbstractGeomToolextends AbstractToolimplements KeyListener{

[...]

protected boolean canAccelerate(){

return true ;}

protected boolean initFunctionEvaluation( Point2D[] ctrlPoints ){

return false ;}

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

[...]}

Die Fahigkeit, 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 MethodeevaluateFunction wird ein Array von Zeit-Werten ubergeben, die monoton steigend abernicht linear verteilt sein mussen. Die Bezeichnung warpedTime besagt, daß die Eingangs-Zeitwerte ungleichmaß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 alszum Schluß, so ergibt sich eine lineare Bewegung des Transmitters, deren Geschwindigkeitzunimmt.3 Durch Doppelklick auf die Surface wird dem Benutzer eine einfache Moglichkeitgegeben, die Start- und Endgeschwindigkeit der geometrischen Form anzupassen. Der Verlaufder Geschwindigkeit wird mit einer kubischen Funktion so berechnet, daß unabhangig vonden Einstellungen des Benutzers der gewahlte Zeitabschnitt exakt ausgefullt wird. Die Ge-schwindigkeit wird durch eine transparente gelbe Hullkurve dargestellt, die der geometrischenGrundform folgt (Graudarstellung in Abbildung 4.3).

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

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

Um beim Einzeichnen von Trajektorien-Abschnitten zu vermeiden, daß ein Transmittersprunghaft 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 Fallen eineUnstetigkeit an den Randern des gefilterten Zeitausschnittes erzeugen. Ebenso kann mit einer

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

38

4 Graphische Benutzeroberflache

Abbildung 4.3: Bezier-Kurve mit variabler Geschwindigkeit

langen Blending-Dauer der Output einfacher Filter ein- und ausgeblendet werden, so daß einedynamische Transformation stattfindet, obwohl die Filter selbst keine zeitvariablen Parameterbesitzen.

4.1.2 ReceiverEditor

Mit Doppelklick auf den Anker eines Receivers wird ein Editor geoffnet (Abbildung 4.4), mitdem die Sensitivitat des Receivers eingestellt werden kann. Grundsatzlich sind Receiver undReceiverEditor Interfaces in Meloncillo, so daß sich verschiedene Modelle fur die Berechnungder Sensitivitat integrieren lassen. In der aktuellen Version ist lediglich eine Klasse von Recei-vern vorhanden, der SigmaReceiver, der in Analogie zu Σ 1 eine Kreuzung zweier Tabellenvorsieht: Die Distance-Tabelle beschreibt die Empfindlichkeit des Receivers in Abhangigkeiteines Abstandes vom Anker-Punkt. Die Rotation-Tabelle beschreibt die Abhangigkeit vomWinkel, den ein Transmitter zum Anker-Punkt des Receivers einnimmt. Die Tabellen-Wertesind 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. Dadie Tabellen hinreichend groß sind (jeweils 1024 Punkte4), lassen sich durch harte Kantenoder Rauschen auch experimentelle nicht-stetige Empfindlichkeitsverlaufe realisieren. Dazustehen per Popup-Menu verschiedene Signalgeneratoren und mathematische Operationen zurVerfugung. Um Zipper-Noise bei langsamen Bewegungen und tieffrequenten harmonischenTonen zu vermeiden, werden die Tabellen-Werte linear interpoliert.

Im klassischen Amplituden-Panning werden die Sensitivitaten direkt auf Lautstarken ge-mappt. Durch Vergroßern der Receiverflache und Editieren der Tabellen lassen sich praktischalle Panning-Verlaufe umsetzen und Divergenzen simulieren. Wird ein anderes Verfahrenbenutzt, beispielsweise VBAP, so sind fur das reine Panning nur die Receiver-Koordinatenvon Bedeutung; die Sensitivitat kann in diesem Fall ganz anders genutzt werden, etwa alsParameter 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 Sensitivitats-Daten

generiert und somit effektiv ist, wenn darauf ohnehin verzichtet wird, wie z.B. in einer HRTF Synthese.

39

4 Graphische Benutzeroberflache

Abbildung 4.4: Editor fur SigmaReceiver Abbildung 4.5: Matrix Meter

4.1.3 Matrix Meter

Der Observer zeigt wahrend der Tabellen-Editierung die exakte Sensitivitat eines Receiversan. Um zu kontrollieren, wie der Ubergang von einem Receiver zum nachsten verlauft, kanndas sogenannte Matrix Meter Fenster eingeblendet werden (Abbildung 4.5). Es zeigt jeweilseine Zeile oder Spalte der aus Transmittern und Receivern gebildeten Matrix an. Durch Klickauf einen Transmitter Namen werden die momentanen Empfindlichkeiten aller Receiver an derStelle dargestellt, an der sich dieser Transmitter befindet. Umgekehrt werden durch Klick aufeinen Receiver Namen die Sensitivitaten dieses Receivers zu allen momentanen Transmitter-Positionen dargestellt. In einer zukunftigen Version wird das Meter optional logarithmischdargestellt6, 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 derKomposition sorgt das TimelineFrame (Abbildung 4.6). Ahnlich dem Arrangier-Fenster einesHarddisk-Recording-Programms ist hier die Zeitachse horizontal aufgetragen, wahrend dieverschiedenen 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. Moglicherweise zeigt eine zukunftige Version optional einePolar-Koordinaten-Sicht. Die kartesische Darstellung hat jedoch den Vorteil, daß sie der inter-nen Datendarstellung entspricht und somit schnell gezeichnet werden kann, davon abgesehenmußten Winkel mit der Periode 2π umgebrochen werden.

6Die jetzige Darstellung ist linear.

40

4 Graphische Benutzeroberflache

Abbildung 4.6: Timeline FensterAbbildung 4.7: Transport

Palette

Die Darstellung der Koordinaten-Vektoren erfolgt mit einem VectorEditor, dadurch ist dasdirekte Einzeichnen mit der Maus moglich. Komfortabler ist jedoch die Editierung auf derSurface oder mittels Filterung, wie sie im Plug-In Kapitel beschrieben wird. Die Editierung,die typischerweise im Timeline Fenster gemacht wird, ist das Ausschneiden, Kopieren undEinfugen von Trajektorien-Abschnitten. Am oberen Rand des Fensters ist eine Zeitachse zuerkennen. Durch Klicken mit der Maus kann die gegenwartige Zeitposition, die durch dievertikale rote Linie symbolisiert wird, verschoben werden. Durch Halten der Umschalttastekann eine Region selektiert werden, die durch dunklere Schattierung hervorgehoben wird.Durch Klick auf die Namen der Transmitter-Spuren konnen diese Transmitter selektiert unddeselektiert werden. Die Cut- und Copy-Befehle wirken auf die Trajektorien-Ausschnitte, diedurch die selektierten Transmitter und den selektierten Zeitausschnitt bestimmt sind. DiePaste-Operation fugt den Clipboard-Inhalt in die Trajektorien der gewahlten Transmitterein, an der Stelle, an der sich die Zeitposition befindet.

4.2.1 Trajektorien Daten-Format

Die Darstellung des Timeline Fensters kann horizontal und vertikal vergroßert und verklei-nert werden. Durch die Diskretisierung der Trajektorien kann der Fall auftreten, daß durchHerauszoomen ein Ausschnitt dargestellt wird, dem mehrere Tausend bis Hunderttausendevon Frames entsprechen. Eine solch große Zahl von Frames einzulesen ist sowohl zu zeit- alsauch zu speicherintensiv. Die Losung besteht in einer Unterabtastung der Trajektorien. Diesgeschieht in mehreren Schritten, um stets eine optimale Auflosung zur Verfugung zu haben.Jede Dezimations-Stufe verringert die Frame-Rate um den Faktor vier. Da VectorEditor dieDaten als Vektorgraphik darstellt, wird der Umschaltpunkt so gelegt, daß maximal doppeltsoviele 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 Großenordnung von Audioraten liegt,zum Beispiel 48 kHz, so besitzt der am starksten dezimierte Track (Faktor 1/4096) eine Rate

41

4 Graphische Benutzeroberflache

1/4

1/1

1/16

: 4

: 4

Abbildung 4.8: Dezimation von Trajektorien

von ca. 12 Hz. Wenn innerhalb einer Fensterbreite eine halbe Stunde dargestellt werden sollte,ware damit eine Puffergroße von 21094 Frames verbunden. In dem wahrscheinlicheren Falleiner Framerate von 4800 Hz oder weniger konnte eine volle Stunde mit gerade 4219 dezi-mierten Frames dargestellt werden, was einen geringen RAM-Verbrauch und geringe CPUBelastung bedeutet.

Die gespeicherte Session enthalt die Trajektorien in Form von Floating-Point Dateien in einemseparaten Unterordner trns. Die dezimierten Dateien werden momentan nicht gespeichert,sondern beim Laden einer Session adhoc erstellt, was akzeptabel schnell verlauft. Die im tem-poraren Verzeichnis gespeicherten dezimierten Trajektorien benotigen ca. 1/3 der Große derOriginaldatei. Die Editierung der Trajektorien geschieht nicht-destruktiv, das heißt, die Origi-naldatei wird bis zum Abspeichern der Session nicht verandert. Die Verwaltung dieser nicht-linearen und nicht-destruktiven Editierung ubernimmt die Klasse MultirateTrackEditor(MTE), die im wesentlichen sieben SubsampleTrackEditoren verwaltet. Diese reprasentierendie Trajektorien-Daten in voller respektive dezimierter Rate. Um auch bei starkerer Dezima-tion eine moglichst gute Annaherung an die Signaleigenschaften zu erhalten, wird in jederStufe 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 TrackSpanObjekten, 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 haufig in Meloncillo benutzt wird. Sie beschreibt eine Zeitspannedurch Angabe eines Start- und Endframes. Die Spannen der Track-Liste fugen sich nahtlosaneinander. Wird eine Session geoffnet, so besteht die Liste lediglich aus einem TrackSpan, derdie 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 Schnittbeschreiben. Die Datei vom Typ InterleavedFloatFile, die die Trajektorien-Daten enthalt,

42

4 Graphische Benutzeroberflache

bleibt unverandert. Das Feld offset wird jedoch stets so angepaßt, daß es auf den richtigenPunkt innerhalb dieser Datei zeigt. Wird jetzt eine Trajektorie zum Beispiel mit dem Linien-Werkzeug uberzeichnet, so wird der neue Abschnitt in einer temporaren Datei gerendertund in Form einer neuen TrackSpan in die Track-Liste eingefugt. Gegebenenfalls wird amInsert-Punkt die alte TrackSpan in zwei separate Objekte aufgeteilt.

Der MTE sorgt dafur, daß nach jeder Editierung der Trajektorien die Dezimations-Filesauf den aktuellen Stand gebracht werden. Die SubsampleTrackEditoren enthalten ebenfallseine Liste von TrackSpans, deren Spannen jedoch durch die spezialisierte BiasedSpan Klassebeschrieben 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 engmit der Realtime-Engine des Programms verknupft. Er enthalt einen eigenen Event-Dispat-cher, der registrierte Listener uber Start- und Stop-Vorgange informiert. Die Palette enthalteinen Play- und Stop-Button und einen Loop-Umschalter. Das ballformige Symbol ganz rechtsaktiviert das Realtime-Plug-In, das im nachsten Kapitel beschrieben wird.

Der Transport dient neben dem Realtime-Preview auch dem Aufzeichnen von Transmitter-Bewegungen in Echtzeit. Wahrend der Transport lauft, kann mit dem Freihand Werkzeugauf der Surface entlanggefahren werden. Die Bewegung wird zwischen den Stutzpunktenlinear interpoliert. Die Editierung wird gerendert, wenn der Mausknopf losgelassen wird. Dasimpliziert, daß die Bewegung im Moment des Zeichnens noch nicht uber das Preview-Plug-Inzu horen ist. Eine Losung dafur wird in der nachsten 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 Interfaceimplementieren: Es sind FilterDialog, BounceDialog und RealtimeFrame. Das Diagramm5.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 RenderPlugInextends 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-Oberflache (getSettingsView()), die vom RenderHost innerhalb eines Fensters dargestelltwird. Der Host reagiert auf die Aktionen des Benutzers. Wenn dieser den Render-Vorgangstartet, ruft er nacheinander nach dem Push-Verfahren die Methoden producerBegin, pro-ducerRender und producerFinish des Plug-Ins auf, wobei producerRender gegebenenfallsmehrfach mit Teilblocken der zu rendernden Zeit aufgerufen wird.

44

5 Plug-In Schnittstellen

PlugInHost

RenderConsumer

LispRenderPlugInLispRealtimePlugIn

Transport BasicRenderDialog

BounceDialog FilterDialog

VectorTransformFilterTimeWarpFilter

LispBounce LispFilter

PlugIn

RealtimeConsumer

RealtimePlugIn RenderPlugIn RealtimeHost RenderHost

Abbildung 5.1: Plug-In Interfaces und Klassen

Im Falle des Trajektorien-Filters mussen die gefilterten Daten wieder zuruck zur Applikationfließen. Dazu ubergibt der Host dem Plug-In ein Objekt, das das Interface RenderConsumerimplementiert. 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. DerFilterDialog ist bidirektional aufgebaut – das heißt, er empfangt die gefilterten Trajektorienund fugt sie wieder in die Session ein –, implementiert daher sowohl RenderHost als auchRenderConsumer. Grundsatzlich werden zwei Typen von Daten unterschieden, die wahrendder Plug-In Bearbeitung Informationen liefern: statische Daten, die in einem PlugInContextObjekt zusammengefaßt sind – beispielsweise die gesamte zu bearbeitende Zeitspanne, diebeteiligten Transmitter und Receiver. Und dynamische Datenstrome, die blockweise generiertwerden und in Form des RenderSource Objekts zur Verfugung stehen.

Wenn das Plug-In durch Aufruf von producerBegin initialisiert wird, kann es sogenannteRequest-Felder im RenderSource ausfullen und gibt damit bekannt, welche Datenstrome

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 (wieim Falle der Filter-Klassen) oder nur an den Sensitivitaten der beteiligten Receiver interessiertsein.

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) denAusgangszeitwerten (Abszisse) zu, d.h. traj′(t)← traj(f(t)). Eine absteigende Geradebewirkt, daß die ursprunglichen Bewegungen ruckwarts wieder gegeben werden. EineParabel wurde ein Vorwarts- und Ruckwartslaufen simulieren, ein Sagezahn mit dreiPerioden wurde die ausgewahlte Trajektorie dreimal mit dreifacher Geschwindigkeitwiederholen.

• Der VectorTransformFilter bietet die Moglichkeit, x und y Werte (alternativ Radiusund Winkel zu einem Bezugspunkt) mit einer mathematischen Funktion zu bearbei-ten. Unter anderem steht ein Funktionsgenerator zur Verfugung, mit dem sich einfachegeometrische Figuren wie Spiralen und Linien oder das Hinzufugen von Unregelmaßig-keiten (Rauschen) realisieren lassen.

• Der LispFilter stellt ein frei programmierbares Plug-In dar, das uber Common LispScripte gesteuert wird. Es wird in Abschnitt 5.3 erklart.

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 lauft,wenn der Play-Knopf der Transport-Palette gedruckt wird. RealtimeConsumer konnen sichbei ihm registrieren, so daß sie im Benachrichtigungs-Rhythmus mit neuen Informationen

46

5 Plug-In Schnittstellen

Klasse Request Rate AktivitatSurface traj 30 Hz Nachfuhrung der Transmitter BewegungenMeterFrame sense 15 Hz Monitoring der SensitivitatenTimelineFrame clock 30 Hz Animation der Zeitachsen-Positions-LinieTransportPalette 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 denThread fur eine bestimmte Zahl zu pausieren. Die suggerierte Genauigkeit im Bereich vonNanosekunden ist jedoch uberhaupt nicht gegeben. Selbst wenn eine Millisekunde lang ge-wartet wird, ist nicht garantiert, daß der Thread wirklich nach einer Millisekunde fortgesetztwird. Deshalb wird im Transport-Kern ein Mechanismus benutzt, der laufend die aktuelleund die geforderte Rate vergleicht und entsprechend kurzer oder langer wartet. Der entste-hende Jitter ist optisch irrelevant und tangiert die externe Klangsynthese nicht, die Datenblockweise erhalt und ihren eigenen Scheduler hat.

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

Je nach Anwendung sind also unterschiedliche Datenraten gefragt. Die tabellierten Klassensind alle Teil der graphischen Oberflache und benotigen daher nur Raten, die einen optischfließenden Eindruck vermitteln. Die verschiedenen Requests werden dynamisch verwaltet voneinem Objekt, das eng mit Transport zusammenarbeitet, dem RealtimeProducer:

Quelltext 5.3: RealtimeProducer.java (realtime package)public class RealtimeProducerimplements 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 EventThreads. Eine neue Anfrage wird vom Transport durch Aufruf der requestProduction Me-thode gestellt. Der RealtimeProducer soll darin die Daten, die zur Zeitspanne blockSpangehoren, produzieren. Um Dropouts zu vermeiden, darf er dafur maximal deadline Milli-

47

5 Plug-In Schnittstellen

160

transport palette notif. : 1/32

plugin notification : 1/8

plugin sense read : 1/2

surface traj read / timeline frame notif. : 1/16

traj : 1/1128

sense : 1/2

1129680644832

Abbildung 5.4: Realtime Datenstrome

sekunden benotigen. Mit anderen Worten, der RealtimeProducer wird bereits im vorausbeauftragt, einen neuen Block Daten zu generieren. Diese Daten sind in Arrays des sourceObjekts gespeichert. Die Consumer streichen im Clock-Rhythmus zirkular durch diese Puffer.Jedesmal, wenn die aktuelle Zeit den Puffer-Anfang oder die Puffer-Mitte uberschreitet, wirddie jeweils obsolete Puffer-Halfte, spezifiziert durch den even Parameter, aktualisiert.

Wenn der Transport gestartet wird, muß ein voller Block vorproduziert werden, dazu dient dieMethode produceNow. Da die Oberflache auch auf manuelles Ziehen der Zeitachsen-Positions-Linie durch den Benutzer reagieren soll, ohne daß der Transport lauft, wurde die MethodeproduceOffhand eingefuhrt, die nur ein einzelnes Zeitframe produziert. Wenn der Benut-zer die Session verandert, zum Beispiel Receiver loscht oder hinzufugt, mussen die Pufferneu angelegt werden. Dazu werden die Consumer kurzzeitig angehalten, der Kontext mittelschangeContext aktualisiert, und ein neues Profil von allen Consumern angefordert.

Wie findet die Koordination zwischen mehreren gewunschten Datenraten statt? Nehmen wirdazu an, daß neben den in Tabelle 5.3 aufgefuhrten Consumern ein Lisp-Echtzeit-Plug-Inlauft. Die Session habe eine Trajektorien-Datenrate von 500 Hz1. Nehmen wir an, das Plug-In steuert den SuperCollider-Synthesizer, dessen Controlrate ca. 690 Hz betragt. Das Plug-Infordere aus Grunden der CPU Belastung Sensitivitaten mit maximal 345 Hz an. Nehmen wirweiter an, ein voller Datenpuffer entsprache etwa 1/4 Sekunde, namlich 128 Frames. Dannergibt sich ein Datenstrom-Produktions- und Konsumptions-Schema nach Abbildung 5.4.

Der RealtimeProducer produziert prinzipiell Trajektorien-Daten (traj ) mit voller Datenrate– also durchgangig alle 128 Frames eines Blocks –, da sie direkt von der Harddisk gelesen wer-den und eine Unterabtastung eher Rechenzeit vergeuden als sparen wurde. Sensitivitats-Daten(sense)werden nur produziert, wenn sie nachgefragt werden. Der einzige Request kommt vomRealtime Plug-In (345 Hz). Grundsatzlich mussen die Faktoren der Unterabtastungen einerZweierpotenz entsprechen, somit ergeben sich hier 250 Hz beziehungsweise eine Schrittwei-te von zwei Frames. Alle ungeraden Frame-Indices des Puffers werden ignoriert und habenkeinen 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 verandertenFrequenzen von 31.25 Hz bzw. 15.625 Hz ergeben. Im Falle von blockverarbeitenden Con-

1Die Voreinstellung betragt 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 Rateder angeforderten Daten-Strome. Im gezeigten Beispiel betragt sie 1/8 der vollen Rate. DieErklarung dafur wird im Abschnitt 5.4.3 in Zusammenhang mit der SuperCollider Anbindunggeliefert.

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 Programmsein XML-Script zur Steuerung der externen Programme benutzt. XML erweist sich jedoch alsunpraktisch, wenn programmiersprachliche Konstrukte wie Schleifen (do-while) oder Bedin-gungen (if-then-else) benotigt werden. Diese hatten alle ”zu Fuß“ in den XML Interpretereingebaut werden mussen. Stattdessen wurde eine einfach strukturierte, kompakte, in Javaintegrierbare Interpreter-Sprache gesucht.

Die Wahl fiel auf Common Lisp: Die Syntax ist sehr uberschaubar3, mehrere algorithmischeMusiksprachen basieren auf Lisp4, und es gibt mit Jatha eine einfache freie Implementationin Java. Micheal Hewett entwickelte Jatha uber die letzten zehn Jahre, und es erweist sichals zuverlassig im Betrieb. Ein paar der Vorteile von Jatha:

• maximale rechtliche Freiheit durch GLPL Lizenz

• kompakte Bibliothek (232 KB)

• plattformunabhangig

• 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 konnen 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ßtes sehr zuruckhaltend, Jatha implementiere ”a large part of the core of Common Lisp“5. Dasbedeutet unter anderem, daß praktisch keine weitergehenden APIs eingebaut sind. Zum Bei-spiel gibt es keine Funktionen zum Lesen und Schreiben von Files. Auch Standard-Konzeptewie Streams, Arrays und Macros fehlen komplett. Im Rahmen der Anforderung als einfachesScripting-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 Oberflache bereit, die eine Auswahl-Box fur die konkretenLisp Scripte (Sourcecodes) enthalt und die Moglichkeit bietet, GUI Elemente darzu-stellen, die direkt von den Scripten erzeugt werden (vgl. Abb. 5.2 rechts).

• Sie verwaltet die Jatha Umgebung und stellt zusatzliche Funktionen und Symbole zurVerfugung.

• Sie stellt die Methode executeLisp zur Verfugung, mit der zur Renderzeit beliebigeim Script definierte Funktionen ausgefuhrt werden konnen.

Die Namen dieser Funktionen hangen 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 ermoglicht demScript, grundlegende Initialisierungen durchzufuhren und Requests anzumelden. render wirdim Gegensatz zu RenderPlugIn→producerRender() nur einmal ausgefuhrt. Dies geschieht,nachdem die angeforderten Datenstrome in Form von temporaren Dateien bereitgestelltwurden, so daß hier ublicherweise der Aufruf des externen Klangsynthese-Programms, z.B.CSound, erfolgen kann. Aufraumarbeiten wie das Schließen oder Loschen von Dateien werdenin der cleanup Funktion erledigt.

Die zusatzlich 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 mitRegularen 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-sitivitatsdaten benotigt und zuruckgeliefert werden)

• Ausfuhren von externen Programmen

• Erzeugen von GUI Elementen

Die GUI Elemente dienen dazu, dem Benutzer die wichtigsten Script Parameter in Formvon Checkboxes und Textfeldern zu prasentieren, ohne daß dieser fur jede Session separateScript-Dateien editieren muß. GUI Elemente werden in der speziellen Funktion create-guidefiniert.

Das Script erhalt außerdem ein Dictionary6, das die wichtigsten statischen Parameter enthalt.Hier kann das Script nachschlagen, wieviele Transmitter und Receiver beim Rendern beteiligtsind, 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

Wahrend die Besonderheiten fur Echtzeit-Scripte im folgenden Abschnitt erlautert werden,wird hier das Beispiel einer Trajektorien Filterung mit CSound durchgegangen. Nehmen wiran, CSound soll die Trajektorien tiefpaßfiltern, so daß die Transmitter-Bewegungen wenigerhektisch und dafur flussiger werden.7 Das Lisp Script ist in der Datei "csfl-smooth.lisp"gespeichert. Wenn es im Filter Dialog ausgewahlt wird (Abb. 5.2 rechts), wird der Quell-text geladen und ubersetzt. Anschließend wird die Funktion create-gui ausgefuhrt, die einnumerisches 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-makesind (1) ein Lisp-Symbol, das stets den aktuellen Wert des GUI-Elements – in diesem Fall dieFrequenz – enthalt, (2) der Gadget-Typ, (3) die Position des Gadget auf der Oberflache, (4)der voreingestellte Wert, (5) spezifische Optionen – hier die physikalische Einheit der Werteund die erlaubten Minimum- und Maximum-Werte. Die Funktion liefert T (wahr) zuruck umzu signalisieren, daß keine Fehler aufgetreten sind.

Durch Klick auf den Process-Knopf wird die Filterung gestartet. Ein RenderContext dergerade ausgewahlten Transmitter und des Zeitausschnitts wird erstellt. Die Lisp-Funktionprepare 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 Listeder Transmitter colltrns, die Zahl der Transmitter numtrns, die Lange des Zeitausschnittsduration und die Datenrate sense-rate werden ermittelt. In einer Schleife8 wird fur je-den Transmitter eine Eingabe- und Ausgabe-Datei im temporaren Verzeichnis erzeugt. Mitaudio-file-open wird das Eingabeformat festgelegt, hier eine ”raw“9 Datei fur 32bit Floa-ting-Point Samples und zwei Kanale. Diese Datei wird uber den Identifier bufidx als Zielfur die Quelldaten bestimmt (source-request). Dem Lisp-Plug-In wird mitgeteilt, daß dieZieldaten in einer Datei temp-output-file zu erwarten sind. Fur die spatere Verwendungin der render Funktion werden die Dateinamen in der Hashtable gespeichert, die fur jedenTransmitter existiert.

Nachdem die Funktion zuruckkehrt, arbeitet das Lisp-Plug-In die Requests ab und schreibtdie angeforderten Trajektorien-Daten in die temporaren Dateien. Anschließend ruft es dieScript 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

"<CSoundSynthesizer >\\n<CsInstruments >\\n""nchnls = 2\\n""#include \"smooth.orc \" \\n""</CsInstruments >\\n<CsScore >\\n""i88 0 " duration " \\n""i14 0 " duration " \"" ( gethash "INPUT −FILE" trns) " \" "

filter −freq " \\n""</CsScore >\\n</CSoundSynthesizer >\\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 Funktiontrnsiter definiert, die die Variable trnsidx von 0 bis numtrns - 1 hochzahlt.

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 ScriptCSound jeweils getrennt fur die einzelnen Transmitter auf; in jedem Durchgang der Iterationwird eine Text-Datei geoffnet (file-open), in der die CSound Score generiert wird. Das Scriptbindet das bereits auf der Harddisk gespeicherte Orchestra-File "smooth.orc" ein (sieheQuelltext 5.4) und schreibt zwei Instrumenten-Aufrufe: i88 und i14. Instrument 88 ist einHilfsinstrument, 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 gewahltenFrequenz und schreibt das Ergebnis in das CSound Ausgabefile.

CSound selbst wird durch die Lisp-Funktion execute gestartet. Der Pfad zu CSound wirddurch Auslesen des Preferences-Feldes CSOUNDAPP ermittelt. Das erste Argument von executeist eine Callback-Funktion im Script, die die Console-Ausgabe des ausgefuhrten Programmesauswertet. 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 mitprogression-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. DasLisp-Plug-In kopiert nun die von CSound generierten neuen Trajektorien-Dateien zuruck indie 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 swappedaty atx diskin p4, 1, 0, 0, 6 ; path, pitch, offset, wrap, formataoutx reson atx, 0, p5, 1aouty reson aty, 0, p5, 1

outch 1, aoutxoutch 2, aouty

endin

53

5 Plug-In Schnittstellen

; print progress information every 2 secondsinstr 88

iweight = 1.0 / p3kschoko times

printks "CILLO %.2f \\n", 2, kschoko ∗ iweightendin

5.4 Open Sound Control

Open Sound Control (OSC) wurde am CNMAT in Berkeley von Matt Wright und AdrianFreed entwickelt. Es ist als Kommunikationsprotokoll gedacht, mit dem sich Computer undComputeranwendungen, insbesondere Multimedia-Hardware und -Software verstandigen kon-nen. Das Grundkonzept wurde von den Autoren auf der ICMC 1997 vorgestellt.10 Nachdemder Boom im Bereich von Software-Synthesizern begonnen hatte und neue schnelle Computer-Schnittstellen wie Firewire und USB sich durchzusetzen begannen, stellte sich die Frage, wievoneinander 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 Beschrankungen des damals 14-jahrigenMIDI Standards zu umgehen: MIDI ist unskalierbar – der Befehlssatz ist festgelegt unduberdies hochproblematisch11 –, hat eine viel zu geringe Datenrate (31.25 kbs), kennt nureine beschrankte Zahl von Adressaten (MIDI-Kanale) und kann praktisch keine zwei Befehlegleichzeitig ausfuhren.

5.4.1 Protokollubersicht

In der Erkenntnis, daß Transport-Protokolle und Hardware-Interfaces sich schneller andernkonnen als ein Musik-Kommunikations-Protokoll, wurde OSC transportunabhangig definiert.Es ist jedoch an die Erfordernisse von Netzwerk-Transport wie UDP angepaßt und geht voneiner 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 werdenunterschieden: 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 demdie enthaltenen Messages auszufuhren sind.13

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

10[Wright/Freed 1997]11Dazu zahlt 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 mussensich 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-Objektgeschickt wird, das sie an die Oszillator-Sektion weitergibt, die wiederum an den Sagezahn-Generator, der dann den Befehl zum Andern der Frequenz ausfuhrt. Im Gegensatz zu MIDIkann sich der Adreß-Raum grundsatzlich dynamisch verandern. Das ursprungliche OSC Pro-tokoll sieht folgende spezielle Message-Adressen vor:

• Wildcards wie ’*’ oder ’?’, die es erlauben, eine Nachricht an mehrere Adressaten zuverschicken, 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 Benutzergelesen 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 unterstutztwerden, variiert jedoch erheblich. Eine klarere Rollen-Teilung der kommunizierenden Objektewird in den Ausdrucken OSC-Server und OSC-Client deutlich.15 Im Client/Server-Modellstellt der Server Dienste zur Verfugung, ein oder mehrere Clients benutzen diese Dienste,die Kommunikation verlauft uberwiegend in Richtung Server, der gegebenenfalls Antwort-Nachrichten zuruckschickt.

Das CNMAT fuhrt eine Liste an Applikationen, die OSC unterstutzen,16 sie ist allerdingsunvollstandig und zum Teil obsolet. Zu den Musik- und Klang-Programmen zahlen Super-Collider, Max/MSP, PD, jMax, OpenMusic, RTcmix und Siren. Im Bereich Multimediasind OSC-Anbindungen an Macromedia Flash (flosc) und Director (OSCar) zu nennen. AmIRCAM wurde mit EtherSense ein Sensor-Gerat fur Live-Performances entwickelt, das direktOSC uber Ethernet an einen Computer ubertragt. Das vom CNMAT herausgegebene OSC-Kit, eine OSC-Bibliothek in C, wurde in weitere Sprachen wie Java, Objective-C, CommonLisp 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: Diewenigsten Implementationen unterstutzen derzeit das Type-Querying, also das Abfragen derDaten-Typen fur Message-Parameter. In der Praxis ist dem Client oder Anwender bereitsbekannt, 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 zudekodieren, bevor sie vom eigentlichen Adressaten weiterverarbeitet werden.17 Daher wurdeder 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-Layererfragt 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. OhneType-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 lineareganze Zahlen, ’f’ fur 32bit Floating-Point Zahlen, ’s’ fur Strings oder Symbole und ’b’ fur densogenannten ’Blob’, einen binaren Datenblock. Type-Tags machen komplizierte Argument-Prufung und Heuristiken uberflussig.

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 enthalt

• OSCMessage : Die Message Klasse, die Java-Primitives in Binarform kodiert bzw. ausder binaren empfangenen Nachricht dekodiert

• OSCBundle : Die Bundle Klasse. Messages und Bundles werden zunachst einzeln hin-zugefugt und anschließend in Binarform 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 konnen in einem eigenen Thread auf das Eintreffenvon Nachrichten warten

• OSCListener : Listener fur einen OSCReceiver, der beim Empfang von Nachrichteninformiert wird

• OSCException : Klasse fur OSC-bezogene Fehler

Wahrend sich die Klassen zunachst an die bereits existente Java-Bibliothek JavaOSC18 an-lehnten, wurden sie aus Grunden der Effizienz und etwas umstandlichen Art von JavaOSCneu programmiert und auf die notigsten Elemente beschrankt. Sie unterstutzen momentankein Pattern-Matching19 und keine mit Brackets (’[’, ’]’) getypten Arrays20, außerdem gibt eskeinen separaten Dispatcher. Stattdessen wird mit entsprechenden Methoden der java.netund java.nio Pakete einfach ein DatagramChannel geoffnet, die zu versendenden Pakete ineinen ByteBuffer kodiert (dies erledigt OSCPacket) und mit write in den DatagramChannelgeschickt.

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

18http://www.mat.ucsb.edu/~c.ramakr/illposed/javaosc.html19Dies macht nur fur OSC-Server Sinn. Ein Client-Listener kann jedoch auf die machtigen Funktionen von

java.util.regex zuruckgreifen. Den gegenwartigen Diskussionen des Forums osc_dev@create.ucsb.edu

kann daruber hinaus entnommen werden, daß sich das Pattern-Konzept in zukunftigen OSC Versionenvoraussichtlich andern wird.

20Dies auch vor dem Hintergrund, daß sclang ebenfalls keine Brackets benutzt, sondern Arrays einfach direktin die einzelnen Elemente auflost.

56

5 Plug-In Schnittstellen

5.4.3 Anbindung an SuperCollider

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

Diese knappe Beschreibung der ersten Version von SuperCollider aus dem Jahre 1996 trifftim wesentlichen noch fur Version 3 zu, obwohl das Programm konzeptuell einige Anderungenerfahren hat.21 Wahrend SuperCollider 1 gerade aus der Fusion zweier Vorlauferprogrammehervorging, einer Klangsynthese-Sprache (Synth-O-Matic) und einer Interpreter-Umgebungfur Max (Pyrite), besteht der wesentliche Unterschied von Version 3 zu Version 2 darin, daßes sich eigentlich wieder um zwei unabhangige 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 zurKlanggenerierung mit scsynth uber OSC kommuniziert. scsynth hat grundsatzlich nichtsmit SmallTalk oder uberhaupt einer hoheren Sprache zu tun. Der einfache Befehlssatz, deraus ca. 50 einzelnen Kommandos eines flachen Adreßraums besteht22, und die Effizienz derDSP Algorithmen pradestinieren scsynth dazu, von Frontends verschiedenster Art als reineRechenmaschine verwendet zu werden, mit der der Anwender nicht direkt etwas zu tun be-kommt. In dieser Konstellation wird SuperCollider als Server und die Steueranwendung alsClient bezeichnet.

Ein Beispiel fur einen SuperCollider Client ist die in einer Fußnote in Abschnitt 4.1 erwahnteScream 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 Applikationenaufsetzen konnen.

Da Meloncillo fast nichts von SuperCollider weiß – dies liegt in der Obhut der Scripte –,laßt sich prinzipiell auch sclang als Server benutzen, wodurch komplexere algorithmischeVerfahren moglich sind. Der Einfachheit halber wird jedoch nur ein Beispiel fur die direkteKommunikation mit scsynth dargestellt. Im Gegensatz zu sclang wurde der Synth Serverbereits auf andere Plattformen portiert und kann unter Mac OS X, Linux i386, Linux PPCund Win32 benutzt werden. Da Meloncillo die OSC Messages uber UDP an SuperColliderversendet, kann SuperCollider auch auf einem anderen Rechner als Meloncillo laufen, wenndiese Rechner uber ein LAN verbunden sind. Die Synchronisation der Uhren beider Rechnerist hingegen noch ungelost (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 dabeisequentiell 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 Schragstriche getrennt werden, also ein Puffer beispielsweise direkt mit "/b_free 789" statt"/buffer/789/free" freigegeben wird.

57

5 Plug-In Schnittstellen

0...numTrns−1

0...numRcv−1

Sense−Buf Sense−Buf Sense−Buf

Sense−BufSense−BufSense−BufSense−Buf

Sense−Buf Sense−Buf Sense−Buf Sense−Buf

Sense−BufSense−BufSense−BufSense−Buf

Sense−Buf Sense−Buf Sense−Buf Sense−Buf

Audio−Bus

Audio−Bus

Audio−Bus

Audio−Bus

Audio−Bus

Audio−

Hardw

are−O

utput

Audio−

Hardw

are−O

utput

Audio−

Hardw

are−O

utput

Audio−

Hardw

are−O

utput

Audio−File Buffer

Audio−File Buffer

Audio−File Buffer

Audio−File Buffer

Audio−File Buffer

Phasor Synth

Root Node

Master Group

Matrix aus Sensitivitäts−Puffern

Input Group Mix Group

Matrix aus Mix SynthsVektor aus Input Synths

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

Control−Bus

Sense−Buf

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. NebenSynth-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 oderdas 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 Entwurfeines Patches – wird zum Beispiel ein Soundfile eingelesen (Input-Knoten) und auf einenBus geschickt, auf den ein Mixer zugreifen soll (Mix-Knoten), so muß der Input-Knoten vordem Mix-Knoten ausgefuhrt werden. In den OSC Messages werden Synthesizer und Gruppendurch eine eindeutige ganze Zahl, die Node-ID, angesprochen, die jedoch keinen Einfluß aufdie 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 einemAudio-Bus zusammengemischt werden konnen. Neben Bussen gibt es Puffer, die intern oderper OSC blockweise beschrieben werden konnen.

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. Dreiverschiedene 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 busSynthDef ( "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 busSynthDef ( "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 cycleSynthDef ( "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 Lautstarke wird aus Puffern gelesen, die blockweise mit dem OSC Befehl "/b_setn"von Meloncillo gefullt werden. Der Phasor-Synthesizer generiert ein Sagezahn-Signal, dasdiese Puffer zyklisch abtastet. Die Instantiierung der Gruppen und Synthesizer erfolgt vomLisp-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 0input −group 0 master −groupmix −group 1 master −group)

( list "/d load" synthdefs))"/done" 2000

))( println "TIMEOUT! group creation, definition load")

; elseNIL

)

1977 ist der Identifier fur den in der ersten Zeile geoffneten Datagramm-Kanal. Das Bundleenthalt die zwei Messages "/g_new" zur Erzeugung der Gruppen-Knoten und "/d_load" zumEinlesen 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.

Wahrend der Realtime Modus aktiv ist, werden die Transport-Befehle an das Lisp-Scriptweitergegeben. Es muß dafur die Funktionen position, play und stop definieren. AusPerformance-Grunden wird das Script nicht damit beauftragt, kontinuierlich OSC-Nachrichtenzum Auffullen der Sense-Puffer zu erzeugen. Stattdessen ubergibt es der im Realtime-Modusetwas 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 Pufferausgefuhrt 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 dieSensitivitatsdaten ("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

Sensitivitats-Puffer ausgelost. Wurde Meloncillo nach seiner internen Uhr die Puffer versenden, konnten 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 uberprufen,

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 losen laßt.

Das Script und die SynthDefs konnen als Ausgangspunkt dienen, mit neuen Synthese-Modellenzu experimentieren. Die Input-Synths konnten zum Beispiel durch Live-Inputs ersetzt wer-

23(target-request "SYNC" 0 <datagram-channel-id>)

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 Ausgangeauf weitere Busse statt direkt auf die Hardware-Outputs geschickt werden.

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

61

6 Resume

6.1 Anwendungsbeispiel

Abschließend sollen an einem SuperCollider Patch ein paar Moglichkeiten des Programmsdemonstriert werden. Ausgangspunkt ist ein Synthesizer nach Abbildung 5.5. Er soll wiefolgt erweitert werden:

• zuschaltbarer Doppler-Effekt fur die Transmitter-Bewegungen

• zuschaltbarer raumlich gerichteter Verzerrer

• zuschaltbarer Hall

• optionale Umkehrung des Modells, so daß die Receiver die Ausgangsklange symbolisie-ren und die Transmitter diese Klangfelder als ”bewegte Mikrophone“ abtasten und zuden Lautsprechern leiten

Doppler-Effekt

Der Doppler-Effekt beschreibt das Phanomen, daß sich die wahrgenommene Tonhohe einesKlangkorpers in Abhangigkeit von seiner Bewegung relativ zum Beobachter verandert. Nahertsich der Klangkorper dem Beobachter, so wird die Wellenlange effektiv verkurzt und dieTonhohe steigt, der umgekehrte Fall tritt auf, wenn sich der Klangkorper wegbewegt. Umeinen 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 betragt 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 mitReplaceOut.ar zuruckgeschrieben wird. Zur Berechnung des Doppler-Shifts werden im LispScript mit weiteren (source-request) Befehlen nun zusatzlich zu den Sensitivitaten auchdie Trajektorien-Koordinaten angefordert. Fur die Beobachter-Position wird vereinfachendder Surface-Mittelpunkt (0.5, 0.5) angenommen, dies laßt sich spater leicht parametrisieren.Die Trajektorien-Daten werden analog zum Mix-Synth (Quelltext 5.5) mit einem durch denPhasor betriebenen BufRd abgetastet. Das aus X- und Y-Koordinaten bestehende Stereo-Signal wird mit Select UGens aufgetrennt und die Distanz nach dem Satz des Pythagorasberechnet:

62

6 Resume

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-Große auf der graphischen Oberflache 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 internePuffergroße und muß so gewahlt sein, daß keine Verzogerungen auftreten, die großer als dieserWert sind.

Verzerrer

Unter Verzerrung kann man allgemein eine Signaltransformation verstehen, die nicht durchein lineares System beschrieben werden kann. Eine einfache Verzerrung ist beispielsweise dieTransformation y ← x2. Ein Verzerrer kann mit einem Median-Filter gebaut werden. Wennman jeweils von wenigen benachbarten Samples den Median berechnet, werden kurze Spikeseliminiert. Subtrahiert man nun das Originalsignal, bleiben hauptsachlich diese kurzen Signal-spitzen ubrig. Das Differenz-Signal wird mit dem geglatteten Median-Signal moduliert. Miteinem Amplituden-Envelope-Follower kann das verzerrte Signal grob an die ursprunglicheLautstarke angepaßt werden.

Der Verzerrer soll von einem Richtungsvektor gesteuert werden. Ein zusatzlicher Transmitterwird dafur benutzt. Er bekommt den speziellen Namen ’d’ (Distortion) und wird aufgrunddieses Namens vom Lisp Script erkannt und separat behandelt. Fur jeden Ausgangskanal wirdein Distortion-Synth erzeugt, der in Abhangigkeit von diesem d-Transmitter zwischen demtrockenen und verzerrten Signal uberblendet. Das Mischungsverhaltnis wird aufgrund desWinkels, den der d-Transmitter und der jeweilige Receiver zum Surface-Mittelpunkt bilden,gewahlt. Wenn A die gegenwartige Position des d-Transmitters, B der Surface-Mittelpunktund 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 Mischungsverhaltnis wird daraus so berechnet, daß bei einem Winkel von 0◦ nur dieVerzerrung, bei 180◦ nur das trockene Signal zu horen ist. Mit einem Divergenz-Parameteri_narrow laßt sich die Verlauf zwischen 0◦ und 180◦ einstellen. Hier die Synthesizer-Definition:

63

6 Resume

Quelltext 6.2: cillo-distortion.scSynthDef ( "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 verzogert 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 zusatzlichen Receiver mit demspeziellen Namen ’e’ (Echos). Angenommen, die normalen Receiver befinden sich in einerkreisformigen 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 dieHall-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, daseine zufallige variierende Delay-Zeit hat:

64

6 Resume

numOutputs

nu

mI

np

ut

s

Sense−Bufs

Distortion−Synth

Distortion−Synth

Traj−Buf(d−Transmitter)

Sense−BufMatrix

MatrixMix−Synths

Echo−Synth

Echo−Synth

Doppler−Synth

Doppler−Synth

(insert)

MatrixTraj−Buf

Aud

io−

Out

put

Aud

io−

Out

put

Normaler Modus

Echo + Distortion GroupMix GroupDoppler Group

...

...

...

...

...

Input−Synth

Input−Synth

Input Group

numInputs = Zahl der TransmitternumOutputs = Zahl der Receiver

(inse

rt)

(e−Receiver)

numOutputs

nu

mI

np

ut

s

(d−Transmitter)

Distortion−Synth

Distortion−Synth

Sense−BufMatrix

MatrixTraj−Buf

Doppler−Synth

Doppler−Synth(inse

rt)

...

Aud

io−

Out

put

...A

udio−

Out

put

numInputs = Zahl der ReceivernumOutputs = Zahl der Transmitter

Input−Synth

Input−Synth

...

...

Doppler GroupDistortion Group

Umgedrehter Modus

Mix GroupInput Group

(insert)

MatrixMix−Synths

Traj−Buf

Abbildung 6.1: Erweiterter SuperCollider Synthesizer

65

6 Resume

Abbildung 6.2: Steuerelemente und Script Oberflache fur den erweiterten Synth

Quelltext 6.3: cillo-echo.scSynthDef ( "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 verandert 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.Zusatzlicher Aufwand entsteht dadurch, daß die Indices der Transmitter und Receiver beider Quelldaten-Anforderung mit (source-request) nicht umgedreht werden durfen. Auchmussen die Gruppen-Knoten unterschiedlich angeordnet werden, damit die Reihenfolge derDSP-Blocke korrekt bleibt. Wenn man davon ausgeht, daß die Verzerrer unabhangig vomModell immer die Receiver bearbeiten und der Doppler immer auf die Transmitter einwirkt(die Receiver sind ja unbewegt und konnen daher keinen Doppler-Shift erzeugen), ergebensich die beiden Schemata nach Abbildung 6.1.

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

66

6 Resume

meter sind in Abbildung 6.2 rechts zu sehen. Der Normal-Modus, in dem die Transmitterden Soundfiles zugeordnet sind, ist angewahlt. Die Surface links zeigt einen Ausschnitt derd-Transmitter Trajektorie zum Steuern der Verzerrung. Zu sehen ist auch der kreisformigeUmriß des in der Mitte plazierten e-Receivers zum Ansteuern des Halls.

6.2 Probleme

Wahrend der Entwicklung der vorliegenden Arbeit sind keine ungelosten 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 giltfur 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 lauft, und daß die Ereignisse keine Informationendaruber tragen, wer die Preferences verandert hat, so daß umfangreiche Vorkehrungen zurVerhinderung von Deadlocks getroffen werden mußten. Die interne Umstellung aller Objektebeim Laden einer Session hatte eleganter durch einen zentralen Mechanismus gelost werdenkonnen.

Das Programm enthalt in der aktuellen Version 0.66 noch zahlreiche kleinere Bugs, die nichtvital fur die Benutzung sind. Mit dem Update der Apple Java VM von Version 1.4.2 03 nach1.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 aufeine Anderung des Double-Buffering Mechanismus zuruckzufuhren und muß in der nachstenVersion von Meloncillo dringend beseitigt werden.

Ungelost 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-Grundenspater 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 dieClock-Unterschiede eigentlich so klein sein sollten, daß bei entsprechend gewahlten Puffer-Großen ein Synchronisationsverlust erst nach einer Zeitspanne in der Großenordnung vonStunden auftreten kann, muß die Ursache im Timing-Schema des OSC-Datenversands ge-sucht werden. Moglicherweise laßt sich das Problem losen, indem die OSC-Befehle zumPuffer-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 ermoglichen.

1Man kann sich momentan nur behelfen, indem das Fenster zeitweilig geschlossen wird. Ein positiver Aspektdes VM Updates ist das Verschwinden eines Bugs, der sich in gelegentlichen Stack-Overflows außerte, dieinnerhalb der Bibliotheken auftraten und damit unmoglich zu eliminieren waren.

2Ein Vorteil des gegenwartigen 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 vonMax/MSP behandeln Time-Tags derzeit nicht automatisch.

67

6 Resume

6.3 Ausblick

Die weitere Entwicklung des Programms kann in Detailverbesserungen und großere Erganzun-gen und Umstrukturierungen unterteilt werden. Zur ersten Kategorie zu zahlen sind

• Anpassung der Oberflache 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 großeren Erganzungen hangen im wesentlichen davon ab, wie sich das Programm in derPraxis bewahrt. 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 Netzwerkfruher oder spater zusammen. Obwohl sich das Problem voraussichtlich leicht losen laßt,wird eine Unterstutzung von OSC-Time-Tags angestrebt. Wenn eine Slave-Synchronisierungin Meloncillo eingebaut wird, sollte zugleich ein grundlegendes Konzept fur eine OSC-ServerSchnittstelle 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 Programmmoglich wird; momentan mussen die zu spatialisierenden Klange zunachst gebounct werden,was sehr hinderlich ist. Eine Zwischenlosung kann wahrscheinlich mit sclang erreicht werden.Es laßt sich ebenso wie scsynth von einem OSC-Client steuern. Ein OSCresponderNodeObjekt mußte auf den Transport-Start in Meloncillo reagieren und einen entsprechendenMIDI Befehl an eine Applikation wie Logic Pro weiterleiten.

Das Ansteuern von Max/MSP macht momentan wenig Sinn, weil das OSC-Objekt otudpread von Matt Wright alle Message-Argumente in primitive Max-Typen ubersetzt, was furdas 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 dieSensitivitats-UDP-Pakete empfangt und direkt in MSP-Puffer schreibt.

Um ein Stuck besser uberblicken zu konnen, sind Zeitmarker erforderlich. Diese konntenauch mit Scripten generiert werden oder von Scripten ausgelesen und zur Klangsynthesebenutzt werden.

68

6 Resume

Wenn, wie im letzten Beispiel gezeigt, mit mehreren Klangtransformationen gearbeitet wird,kann die Surface schnell unubersichtlich werden. Zu uberlegen ist, wie moglichst einfach dieForm einer Ebenen-Struktur in die Session gebracht werden kann. Diese Ebenen konntenentweder optisch umgeschaltet oder uberlagert dargestellt werden.

Receiver und Transmitter sollten mit einer Attribute-Mappe ausgestattet werden. Umeinfache Features zu integrieren, wie zum Beispiel die Moglichkeit, Transmitter stummzu-schalten oder solo abzuhoren, mussen die Scripte momentan spezielle GUI Felder auf ihrePlug-In Oberflachen addieren. Er ware effektiver, mit einem einfachen get und set Mecha-nismus den Transmittern und Receivern beliebige Attribute hinzuzufugen, die dann auchvon den Editoren unterstutzt werden. Ein Transmitter Editor konnte dann Solo- und Mute-Buttons direkt im Timeline Fenster darstellen. Getrennte Methoden wie getName, setName,getAnchor, setAnchor wurden in diesem allgemeinen Attribute-System aufgelost werden.

Von Beta-Testern ist der Wunsch geaußert worden, eine Input/Output Konfiguration furdie Audio-Hardware in Meloncillo vornehmen zu konnen. Das kollidiert zunachst mit derGrundidee, daß das Programm nichts uber konkrete Signalverarbeitung weiß. Eine Alternativewaren Preferences-Karten, die dynamisch von Scripts generiert werden. Wenn in einer dernachsten Versionen die Anbindung an Max/MSP realisiert ist, mußten die Preferences nichtinnerhalb des Programmes erweitert, sondern lediglich ein zusatzliches Preferences-Scriptangemeldet werden.

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

69

Literaturverzeichnis

[Chowning 1971] John Chowning, The Simulation of Moving Sound Sources. Journalof the AES Vol. 19, No. 1, Januar 1971 (Nachdruck in ComputerMusic 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 Follmer, Musik..., verwandelt– Das Elektronische Studio der TU Berlin 1953–1995. Hofheim1995

[Gosling et al. 2000] James Gosling / Bill Joy / Guy Steele / Gilad Bracha, The JavaLanguage 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 Erforschungder Elektronischen Klangumformung und ihre Geschichte (Band 1,Zur Technik der Elektronischen Klangumformung). Baden-Baden1995

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

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

[Kleiner et al. 1993] Mendel Kleiner / Bengt-Inge Dalenback / 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 – Entwurfsprinzipienund 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, Winter2002, S. 61–68

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

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

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

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

[de la Motte-Haber 1993] Helga de la Motte-Haber, Die Musik von Edgard Varese. Hofheim1993

[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 Berlin1988

[Ruschkowski 1998] Andre Ruschkowski, Elektronische Klange und musikalische Ent-deckungen. Stuttgart 1988

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

71

Literaturverzeichnis

[Seelig 1990] Thomas Seelig, Entwicklung einer grafischen Benutzeroberflachefur ein MIDI-gesteuertes quadrophones Mischpult. MagisterarbeitTU Berlin 1990

[Stuart 1996] J. Robert Stuart, The Psychoacoustics of Multichannel Audio. AESUK 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 andAnalysis 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 Introductionto Practical Sound Composition. York 1994

[Wright/Freed 1997] Matthew Wright / Adrian Freed, Open SoundControl : A NewProtocol for Communicating with Sound Synthesizers. Proc. ofthe 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 NewInterfaces for Musical Expression (NIME-03), Montreal, S. 153–159

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

72

Anhang: Abbildungen, Quelltexte

Abbildungsverzeichnis

1.1 Σ 1 Oberflache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Panning Objekte in Digital Performer . . . . . . . . . . . . . . . . . . . . . . 141.3 VBAP Anwendung in Max/MSP . . . . . . . . . . . . . . . . . . . . . . . . . 171.4 Perzeptive Parameter in Spat˜ . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Legende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Session Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Surface Fenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2 Hilfspaletten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3 Bezier-Kurve mit variabler Geschwindigkeit . . . . . . . . . . . . . . . . . . . 394.4 Editor fur SigmaReceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5 Matrix Meter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.6 Timeline Fenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.7 Transport Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.8 Dezimation von Trajektorien . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 Plug-In Interfaces und Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Plug-Ins zur Trajektorien-Filterung . . . . . . . . . . . . . . . . . . . . . . . . 465.3 RealtimeConsumer Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.4 Realtime Datenstrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.5 Nodes, Busse und Buffer fur einen Amplituden-Mixer in SuperCollider . . . . 58

6.1 Erweiterter SuperCollider Synthesizer . . . . . . . . . . . . . . . . . . . . . . 656.2 Steuerelemente und Script Oberflache fur den erweiterten Synth . . . . . . . 66

Quelltexte

3.1 XMLRepresentation.java (io package) . . . . . . . . . . . . . . . . . . . . . . 293.2 Receiver.java (receiver package) . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Transmitter.java (transmitter package) . . . . . . . . . . . . . . . . . . . . . . 313.4 ReceiverCollectionListener.java (receiver package) . . . . . . . . . . . . . . . . 324.1 VirtualSurface.java (gui package) . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 AbstractGeomTool.java (gui package) . . . . . . . . . . . . . . . . . . . . . . 384.3 TrackSpan.java (io package) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.1 RenderPlugIn.java (render package) . . . . . . . . . . . . . . . . . . . . . . . 445.2 RenderConsumer.java (render package) . . . . . . . . . . . . . . . . . . . . . . 45

73

Quelltexte

5.3 RealtimeProducer.java (realtime package) . . . . . . . . . . . . . . . . . . . . 475.4 smooth.orc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.5 synthdef-sources.sc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.1 cillo-doppler.sc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2 cillo-distortion.sc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.3 cillo-echo.sc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

74