In diesem Artikel stelle ich meine Ideen, kreativen Prozesse und technischen Daten zum für die Klasse „Symbolische Klangverarbeitung und Analyse/Synthese“ bei Prof. Marlon Schumacher programmierter Patch vor. Die Idee dieses Textes ist es, die technischen Lösungen für meine kreativen Ideen aufzuzeigen und das gewonnene Wissen zu teilen und so dem Leser bei seinen Ideen zu helfen. Der Zweck dieses Patches ist, Klänge aus dem Alltag zu nehmen und sie mit Hilfe mehrerer Prozesse innerhalb von Open Music in eine eigene Komposition umzuwandeln.
Die Ausgangsidee des Stücks war es, Alltagsgeräusche, zum Beispiel ein Geräusch eines Wasserkochers, in einen anderen, bearbeiteten Klang zu verwandeln, indem technische Lösungen in Open Music implementiert wurden. Dieser Patch verarbeitet und führt mehrere Dateien zu einer Komposition zusammen. Es gibt drei Iterationen des Patches, an dem ich während des Semesters gearbeitet habe. Ich werde sie chronologisch nacheinander beschreiben.
Die ursprüngliche Idee für den Patch stammt von musique concréte. Ich wollte aus konkreten Klängen (nicht in Open Music synthetisiert, sondern aufgenommen) ein 2-Minuten-Stück machen. Dieser Patch besteht aus drei Subpatches, die mit der Maquette im Hauptpatch verbunden sind.
Dieser Beitrag handelt über die drei Iterationen einer akusmatischen Studie von Zeno Lösch, welche im Rahmen des Seminars „Symbolische Klangverarbeitung und Analyse/Synthese“ bei Prof. Dr. Marlon Schumacher an der HFM Karlsruhe durchgeführt wurden. Es wird über die grundlegende Konzeption, Ideen, aufbauende Iterationen sowie die technische Umsetzung mit OpenMusic behandelt.
Meine Inspiration für diese Study habe ich von dem Freeze Effekt der GRM Tools.
Dieser Effekt ermöglicht es ein Sample zu layern und ihn gleichzeitig in verschiedenen Geschwindigkeiten abzuspielen.
Mit diesem Prozess kann man eigenständige Kompositionen, Sound-Objekte, Klanggebilde u.s.w. erstellen.
Meine Idee ist es dasselbe mit Open Music zu programmieren.
Dazu habe ich die Maquette verwendet und om-loops.
In der OpenMusicPatch findet man die verschiedenen Prozesse des layern des Ausgangsmaterials.
Das Ausgangsmaterial ist eine „gefilterte“ Violine. Diese wurde mit dem Prozess der Cross-Synthesis erstellt. Dieser Prozess des Ausgangsmaterials wurde nicht in Open Music erstellt.
Musik kann nicht ohne Zeit existieren. Unsere Wahrnehmung verbindet die verschiedenen Klänge und sucht einen Zusammenhang. In diesem Prozess, auch vergleichbar mit Rhythmus, wird das einzelne Objekt mit anderem Objekten in Verbindung gesetzt. Digitale Klangmanipulation ermöglicht es mit Prozessen aus einem Klang andere zu erstellen, welche im Zusammenhang zu dem gleichen stehen.
Zum Beispiel ich Präsentiere den Klang in einer Form und verändere ihn an einem anderen Zeitpunkt in der Komposition. Es entsteht meistens ein Zusammenhang, insofern der Hörer diesen nachvollziehen kann.
Man kann ähnlich wie bei Noten eine Transposition bzw. die Tonhöhe verändern.
Bei einer Note wird dadurch die Frequenz verändert. Bei einem digitalen Material kann es zu sehr spannenden Ergebnissen führen. Bei einem Klavier sind die Obertöne bei jeder Note in einem Zusammenhang zum Grundton. Diese sind festgelegt und sind mit traditionellen Noten nicht veränderbar.
Bei digitalen Material spielt der Effekt, der transponiert, eine sehr wichtige Rolle. Je nach Art des Effekts habe ich verschiedene Möglichkeiten das Material zu manipulieren nach meinen eigenen Regeln.
Der Nachteil bei Instrumenten ist es, dass zum Beispiel bei einer Violine, der Spieler nur einmal die Note spielen kann. Zehnmal die gleiche Note bedeutet zehn Violinen.
In OpenMusic ist es möglich das „Instrument“ beliebig oft zu spielen (insofern es die Rechenleistung des Computers schafft).
Prozess
Um das Grm-Freeze nachzubauen, wurde zuerst eine moquette mit leeren Patches gefüllt.
Anschließend wurde aus der Moquette mit einem om-loop das soundfile an die Positionen der leeren Patches gerendert.
Um clipping zu vermeiden wurde folgender Code verwendet.
Layer Study erste Iteration
Das Ausgangsmaterial wird am Anfang präsentiert. Im Laufe der Studie wird es immer wieder verändert und verschiedenartig gestapelt.
In der Studie selbst wird auch mit der Dynamik gespielt. Je nach Algorithmus der Klangstapelung wird die Dynamik in jedem Soundobjekt verändert. Da es sich um mehr als einen Klang in der Zeit handelt werden diese Klänge normalisiert, je nach wie viele Klänge in dem Algorithmus präsent sind um Clipping zu vermeiden.
Die Studie beginnt mit dem Ausgangsmaterial. Dieses wird anschließend in einer verschiedenen zeitlichen Abfolge präsentiert.
Dieser Layer wird dann gefiltert und er ist auch leiser. Der nächste Entwickelt sich zu einem „halligerm“ Klang. Ein Kontinuum. Das Kontinuum bleibt es ist wird wieder anders Präsentiert.
Im vorletzten Klang sind eine Form von glissandi zu hören, welche wieder in einem Klang enden, der ähnlich ist wieder zweite, aber lauter ist.
Der Prozess um den Klang zu stapeln und zu verändern ist bei jeder Sektion sehr ähnlich.
Die Position wird von der leeren Patch in der Moquette gegeben.
Anschließend wird die y-Position und x-Position Parameter für eine Modulation
Layer Study zweite Iteration
Ich habe für jede Sektion versucht ein anderes Stereobild zu erzeugen.
Es wurden verschiedene Räume simuliert.
Eine Technik, die dabei verwendet wurde ist das Mid/Side.
Bei dieser Technik wird aus einem Stereosignal das Mid und Side mit folgendem Prozess extrahiert:
Mid = (L + R) * 0.5
Side = (L – R) * 0.5
Zudem wurde ein Aural Exciter werdet.
Bei diesem Prozess wird das Signal mit einem Hochpassfilter gefiltert, verzerrt und dem Eingangssignal wieder hinzugefügt. Man kann dadurch eine bessere Definition erreichen.
Durch das Mid/Side wird der Aural Exciter nur auf einem der beiden angewendet und es wird als „definierter“ Wahrgenommen.
Um den Prozess wieder zu einem Stereo signal zu kommen wird folgender Prozess angewendet:
L = Mid + Side
R = Mid – Side
Um den Klang weiter zu verräumlichen wurde mit Hilfe eines Allpassfilters und einem Kammfilter die Phase von Mid oder Side Anteil verändert.
Layer Study dritte Iteration
Bei dieser iteration wurde das Stereofile auf acht Lautsprecher aufgeteilt.
Es wurden die verschiedenen Sektionen der Stereokomposition extrahiert und verschiedene Techniken der Aufteilung verwendet.
Bei einen dieser wurde ein unterschiedliches fade in und fade out für jeden Kanal verwendet.
In einer akousmatischen Ausführung einer Komposition kann man dieses fade in und fade out mit den Reglern eines Mixers erziehlen.
Dazu wurde ein mapcar und repeat-n verwendet.
Bei den anderen Prozessen wurde die Position der jeweiligen Kanäle verändert. Es wurde ein Delay verwendet.
Dieser Beitrag handelt über die drei Iterationen einer akusmatischen Studie von Christoph Zimmer, welche im Rahmen des Seminars „Symbolische Klangverarbeitung und Analyse/Synthese“ bei Prof. Dr. Marlon Schumacher an der HFM Karlsruhe durchgeführt wurden. Es wird über die grundlegende Konzeption, Ideen, aufbauende Iterationen sowie die technische Umsetzung mit OpenMusic behandelt.
Verantwortliche: Christoph Zimmer, Master Student Musikinformatik der HFM Karlsruhe
Grundlegende Idee und Konzept:
Ich arbeite normalerweise viel mit Hardware für Musik, besonders gerne auch im Bereich von DIY. Das trifft sich auch oft mit der damit verbundenen Organisation und Optimierung des Workflows die mit dieser Hardware verbunden ist. Als es uns Stundenten zur Aufgabe wurde eine akusmatische Studie in Form von Musique concrète zu produzieren war ich zu beginn orientierungslos. Bisher habe ich mich nur wenig mit „experimentellen“ Musikgenre beschäftig. Die Existenz von Musique concrète war mir bis zu diesem Punkt ehrlich gesagt nicht einmal bekannt. Ich wurde mit dieser Aufgabe also aus meinem üblichen Workflow, der Klangsynthese mit Hardware, und somit auch meiner Komfortzone herausgeworfen. Jetzt mussten Feldaufnahmen als Samples her.
Meine DIY einstellung hat mich intuitiv zu dem Entschluss gebracht die Samples selber aufzunehmen. Es sollte fokus auf eine Variation an Samples gelegt werden. Von dem Gedanken, mich von meiner bisherigen Arbeit komplett abzukapseln war ich jedoch aber immernoch abgetan. Ich wollte eine „Meta-Verbindung“ zu meinem Hardware fokusierten arbeiten in das Stück einbringen. Basierend auf dieser Idee entstand dann das Stück „chris baut einen rollwagen für seine hardware“
Der fertige Rollwagen für Hardware. Weitere Bilder unter: https://www.reddit.com/r/synthesizers/comments/ryyw8e/i_finally_made_a_proper_stand_for_my_synth_rack/
Erste Iteration
Das Stück sollte also aus Samples bestehen welche nicht willkürlich produziert oder aus dem Internet heruntergelden wurden, sondern als „Nebenprodukt“ einer tatsächlich selbst durchgeführten Arbeit entstehen, in diesem Fall das Konstruieren eines Rollwagens für Musik-Hardware. Im Laufe von zwei Wochen habe ich mit meinem Smartphone die bei dem Durchlaufen verschiedenster Arbeitsschritte entstehende Klänge aufgenommen. Da ich mir in diesen Arbeitsschritten unterschiedliche Materialien und Bearbeitungsmethoden zu nutze machte, entstand nicht nur eine große Variation an Klangtexturen, sondern es bildete sich auch von selbst die makroskopische Struktur des Stückes. Es hat sich damit sozusagen von selbst komponiert. Die gewünschte Meta-Verbindung ist somit entstanden. Als der Rollwagen nun komplett war, wurde es Zeit mit der Produktion des Stückes zu beginnen.
Die Rohaudio-Dateien der Aufnahmen sind jeweils mehrere Minuten lang. Um die Handhabung in OpenMusic zu vereinfachen, wurden die einzelnen Klangelemente als .wav Dateien exportiert. Dafür wurde die DAW REAPER genutzt. Das Resultat waren etwa 350 einzenlne Samples. Unter folgendem Link sind diese verfügbar:
Hier ein paar Beispiele der verwendeten Klangelemente:
Mit den vorbereiteten Samples konnte nun das Arbeiten in OpenMusic beginnen.
Wie es für Musique concrète üblich ist, sollten die Samples mit verschiedenen Effekten bearbeitet werden um den musikalischen Kontext zu stützen. Für mich war es aber auch wichtig, dass diese nicht so dominieren, dass die Klänge unerkennbar werden und der Kontext verloren geht. Deswegen kam mir die Idee, für das Arrangement ein Workspace innerhalb eines OpenMusic Patches zu programmieren, um die Samples dynamisch bearbeitbar zu machen. Dafür stellte sich das „Maquette“ Objekt als optimal heraus. Grundlegend ermöglicht diese es andere Objekte innerhalb in einer x-Achse (Zeit) und y-Achse (parametrisierbar) zu platzieren. Diese Objekte können dann auf ihre eigene Eigenschaften im Kontext zu der Maquette zugreifen. Diese Funktionen habe ich dann zu nutzte gemacht um vier verschiedene „Template Temporal Boxes“ zu erstellen welche in verschiedener Weise die parametrisierung der Maquette nutzen um Effekte auf die jeweiligen Samples anzuwenden. Das nutzen von mehreren Vorlagen reduziert weiterhin die Komplexität, während eine Variation an Modulationsmöglichkeiten erhalten bleibt:
tempboxa
Position y –> Reverbance
Size y –> Playback speed
Random –> panning
OM Patch der tempboxa
tempboxb
Position y –> Delay time
Size y –> Playback speed
Random –> panning
OM Patch der tempboxb
tempboxc
Position y –> Tremolo speed
Size y –> Playback speed
Random –> panning
OM Patch der tempboxc
tempboxd
Position y –> Lowpass cutoff frequency
Size y –> Playback speed
Random –> panning
OM Patch der tempboxd
Mit dem Erstellen dieser Boxen konnte die Komposition des Stückes beginnen.
Wie schon erwähnt wurde, sollte die makroskopische Struktur des Ablaufs der Konstruktion beibehalten werden. Praktisch wurden bestimmte Samples der Sektionen (Recherche, Skizzieren, Stahl verarbeitung, Schweißen, Stahl bohren, 3d Druck, Holz Bohrung, Holz schleifen, Streichen und Montage) ausgewählt um diese mit den parametrisierten Tempboxes zu interessant klingenden Kombinationen zu verarbeiten, welche den aktuellen Arbeitsschritt beschreiben sollen.
Ausschnitt der Maquette mit Arrangement
Das Resultat der ersten Iteration:
Zweite Iteration
Mein Ziel der zweiten Iteration war es Akzentierungen auf Samples, welche Ankerpunkte des Stückes darstellen, zu setzen. Genauer gesagt, sollte das in der ersten Iteration verwendete Panning überarbeitet werden, indem die vorhandene Logik mit einem provisorischen Haas Effekt (Delay zwischen dem linken und rechten Kanal) ausgestattet wird. Hierfür wird das Resultat des bisherigen Pannings invers dupliziert und dann mit einem Delay (bis 8 ms) und Level adjustment erweitert, welche sich dynamisch zu der stärke des Pannings verhalten. Schließlich werden beide Sounds gemerged und aus der tempbox ausgegeben.
OM Patch des erweiterten Pannings
Das Resultat der ersten Iteration:
Dritte Iteration
Für die dritte und letzte Iteration wurde es zur Aufgabe, das Stück für ein beliebig wählbares Setup von 8 Kanälen zur Verfügung zu stellen. Die Struktur sollte dabei nicht verändert werden. Dies gab mir wieder die Möglichkeit an dem Panning zu arbeiten. Anstatt die Grenze des Panning Randomizers auf 8 Kanäle zu setzten, kam mir der Gedanke die makroskopische Struktur noch weiter vorzuheben. Dafür habe Ich das folgende Setup von Lautsprechern gewählt:
Setup der Lautsprecher (mit Nummerierung der Kanäle)
Mit diesem Setup ist es möglich abhängig von den Sektionen des Stückes das Panning auf jeweils zwei gegenüberliegende Lautsprecher zu verteilen. Im Ablauf des Stückes soll sich der Klang dann als langsame Rotationsbewegung um den Zuhörer bewegen.
Teil 1 des makroskopischen Pannings
Teil 2 des makroskopischen Pannings
Teil 3 des makroskopischen Pannings
Dieses Prinzip trifft parallel auf die Akzentierung mancher Samples von der zweiten Iteration: Während sich die anderen Samples (je nach Sektrion) auf verschiedene Lautsprecher-Paare verteilen, bleiben die Anker-Elemente auf den Kanälen 1 und 2 bestehen.
Die finale Version ist auch im 2 Kanal Format verfügbar:
Vierte Iteration
Bei dieser Iteration wurde es zur Aufgabe mit den Tools welche wir im Rahmen der Veranstaltung „Visuelle Programmierung der Raum/Klangsynthese“ (VPRS) bei Prof. Dr. Marlon Schumacher und Brandon L. Snyder erlernt haben das Stück zu Spatialisieren
„chris baut einen Rollwagen für seine hardware“ war an diesem Punkt schon so weit ausgebaut, dass ich dieses bei Metamorphoses 2022 (ein Wettbewerb für akusmatische Stücke) eingereicht habe. Hierfür war es notwendig, das Stück auf ein 16 Kanal Setup zu mixen. Aufgrund der baldigen Deadline blieb mir nur wenig Zeit um das Stück auf die Anforderungen anzupassen. Deswegen wurden die Kanäle einfach in REAPER verdoppelt und ein LFO Panning auf die jeweiligen Paare hinzugefügt. Leider wurde das Stück im Nachhinein nicht akzeptiert, da die Länge des Stückes nicht den Anforderungen entsprachen. Da auch die Spatialisierung zu wünschen übrig lies, kam mir die Gelegenheit also gerade recht die neu gelernten Tools zu nutzen um diese zu verbessern.
Ich entschloss mich die Metamorphoses 16-Kanal Spatialisierung zu verwerfen und den Stand der dritten Iteration wieder aufzugreifen. Mein Ziel war eine Spatialisierung, welche nicht nur auf die makroskopische Struktur (wie z.B. die Abschnitte Stahl Verarbeitung, 3D Druck…) eingeht, sondern auch in die mikroskopische Struktur, also einzelne Klänge dynamischer auszulegen. Als Ausgangsmaterial diente das aus OM exportierte Audio (8 Kanal), welches dann mithilfe der Ambisonics (IEM) VSTs bearbeitet werden sollte.
Die Ambisonics Template für REAPER wurde als Workspace Vorlage verwendet ,da diese schon ein Setup für die Audio Busse bereitstellte um schließlich ein Ambisonics File 5. Ordnung und ein Binauralen Stereo Downmix zu rendern. Im ersten Schritt wurden die 8 Kanal Audio Datei so geroutet, dass sich diese separiert bearbeiten ließen. Hierfür wurden jeweils Kanal 1-2 , 3-4, 5-6 und 7-8 zu neuen Tracks geschickt und der Master-Send deaktiviert. Diese Tracks wurden dann als Multikanal Tracks mit 36 Kanälen definiert und der Stereo Encoder (IEM) in die Effekt Chain eingefügt. Die Parameter für die Spatialisierung (Azimuth, Elevation, Roll und Width) wurden dann als Envelopes in die Timeline von REAPER hinzugefügt um deren dynamisch Bearbeitung zu ermöglichen. Schließlich können alle Tracks in den Ambisonics Bus zusammengeführt werden. Der Binaurale Downmix wurde dabei als Monitoring Ausgang verwendet.
Eine vereinfachte Darstellung des Routings in REAPER
Praktisch wurden Punkte per Hand in die Envelope Tracks eingefügt, zwischen welchen dann linear Interpoliert wurde um dynamische Veränderungen der Parameter hervorzurufen. Hierbei bin ich intuitiv Vorgegangen und habe mir Abschnitte vereinzelt angehört um mir eine grundlegende Vorstellung zu bilden, welche Art von Spatialisierung diesen Abschnitt unterstreichen würde. Dann wurde auf die einzelnen Klänge und ihre Herkunft eingegangen, und versucht mit Hilfe der Parameter diese zu Beschreiben. Beispiele dafür sind: beim Bohren eine schneller werdende Drehbewegung, bei dem Piepsen der digitalen Eingabe des 3D-Druckers ein hin und her Springen oder beim Zusammenknüllen von Papier ein komplettes Durcheinander. Mir war diese Form von Workflow bereits gängig, nicht nur durch das Verwenden von DSP VSTs in der DAW, sondern auch bei dem Programmieren von DMX Lichtern über den Envelope.
Bei der Bearbeitung Empfand ich das visuelle Feedback des EnergyVisualizer (IEM) nicht nur sehr hilfreich um den Überblick zu behalten. Ich entschloss mich deswegen diese Aufzunehmen und zu dem Binauralen Downmix zuzufügen:
Alle unkompremierten Dateien finden sie unter folgendem Link: https://drive.google.com/drive/folders/1bxw-iZEQTNnO92RTCmW_l5qRFjeuVxA9?usp=sharing
In diesem Projekt entstand im Rahmen der Lehrveranstaltung „Studienprojekte Musikprogrammierung“ eine audio-only Augmented Reality Klanginstallation an der Hochschule für Musik Karlsruhe. Wichtig für den nachfolgenden Text ist die terminologische Abgrenzung zur Virtual Reality (kurz: VR), bei welcher der Benutzer komplett in die virtuelle Welt eintaucht. Bei der Augmented Reality (kurz: AR) handelt es sich um die Erweiterung der Realität durch das technische Hinzufügen von Information.
Motivation
Zum einen soll diese Klanginstallation einem gewissen künstlerischen Anspruch gerecht werden, zum anderen war auch mein persönliches Ziel dabei, den Teilnehmern das AR und besonders das auditive AR näher zu bringen und für diese neu Technik zu begeistern. Unter Augmented Reality wird leider sehr oft nur die visuelle Darstellung von Informationen verstanden, wie sie zum Beispiel bei Navigationssystemen oder Smartphone-Applikationen vorkommen. Allerdings ist es meiner Meinung nach wichtig die Menschen auch immer mehr für die auditive Erweiterung der Realität zu sensibilisieren. Ich bin der Überzeugung, dass diese Technik auch ein enormes Potential hat und bei der Aufmerksamkeit in der Öffentlichkeit, im Vergleich zum visuellen Augmented Reality, ein sehr großer Nachholbedarf besteht. Es gibt mittlerweile auch schon zahlreiche Anwendungsbereiche, in welchen der Nutzen des auditiven AR präsentiert werden konnte. Diese erstrecken sich sowohl über Bereiche, in welchen sich bereits viele Anwendung des visuellen AR vorfinden, wie z.B. der Bildung, Steigerung der Produktivität oder zu reinen Vergnügungszwecken als auch in Spezialbereichen wie der Medizin. So gab es bereits vor zehn Jahren Unternehmungen, mithilfe auditiver AR eine Erweiterung des Hörsinnes für Menschen mit Sehbehinderung zu kreieren. Dabei konnte durch Sonifikation von realen Objekten eine rein auditive Orientierungshilfe geschaffen werden.
Methodik
In diesem Projekt sollen Teilnehmer*innen sich frei in einem Raum, in welchem Gegenstände positioniert sind, bewegen können und obwohl diese in der Realität keine Klänge erzeugen, sollen die Teilnehmer*innen Klänge über Kopfhörer wahrnehmen können. In diesem Sinne also eine Erweiterung der Realität („augmented reality“), da mithilfe technischer Mittel Informationen in auditiver Form der Wirklichkeit hinzugefügt werden. Im Wesentlichen erstrecken sich die Bereiche für die Umsetzung zum einen auf die Positionsbestimmung der Person (Motion-Capture) und die Binauralisierung und zum anderen im künstlerischen Sinne auf die Gestaltung der Klang-Szene durch Positionierung und Synthese der Klänge.
Abbildung 1
Das Motion-Capture wird in diesem Projekt mit dem Polhemus G4 System realisiert. Die Richtung- und Positionsbestimmung eines Micro-Sensors, welcher an einer vom Teilnehmer getragenen Brille befestigt wird, geschieht durch ein Magnetfeld, welches von zwei Transmittern erzeugt wird. Ein Hub, der über ein Kabel mit dem Micro-Sensor verbunden ist, sendet die Daten des Motion-Captures an einen USB-Dongle, der an einem Laptop angeschlossen ist. Diese Daten werden an einen weiteren Laptop gesendet, auf welchem zum einen die Binauralisierung geschieht und der zum anderen letztendlich mit den kabellosen Kopfhörern verbunden ist.
In Abbildung 2 kann man zwei der sechs Objekte in je einer Variante (Winkel von 45° und 90°) betrachten. In der nächsten Abbildung (Abb. 3) ist die Überbrille (Schutzbrille die auch über einer Brille getragen werden kann) zu sehen, welche in der Klanginstallation zum Einsatz kommt. Diese Brille verfügt über einen breiten Nasensteg, auf welchem der Micro-Sensor mit einem Micro-Mount von Polhemus befestigt ist.
Abbildung 2
Abbildung 3
Wie schon zuvor erläutert, müssen für den Aufbau der Klanginstallation auch diverse Entscheidung vor einem künstlerischen Aspekt getroffen werden. Dabei geht es um die Positionierung der Gegenstände / Klangquellen und die Klänge selbst.
Abbildung 4
Abbildung 5
Die Abbildung 4 zeigt eine skizzierte Draufsicht des kompletten Aufbaus. Die sechs blau gefärbten Kreise markieren die Positionen der Gegenstände im Raum und natürlich gleichzeitig die der Klangquellen der Szene in Binauralix, welche in Abbildung 5 zu erkennen ist. Den farblosen Bereichen (in Abb. 4), im entweder 45° oder 90° Winkel, um die Klangquellen, können Richtung und Winkel der Quellen entnommen werden.
Die komplett kabellose Positionserfassung und Datenübertragung, ermöglicht den Teilnehmer*innen das uneingeschränkte Eintauchen in dieses Erlebnis der interaktiven realitätserweiternden Klangwelt. Die Klangsynthese wurde mithilfe der Software SuperCollider vorgenommen. Die Klänge entstanden hauptsächlich durch diverse Klopf- und Klickgeräusche, welche durch das SoundIn-Objekt aufgenommen wurden, und schließlich Veränderungen und Verfremdungen der Klänge durch Amplituden- und Frequenzmodulation und diverse Filter. Durch Audio-Routing der Klänge auf insgesamt 6 Ausgangskanäle und „s.record(numChannels:6)“ konnte ich in SuperCollider eine zweiminütige Mehrkanal Audio-Datei erstellen. Beim Abspielen der Datei in Binauralix wird automatisch der erste Kanal auf die Source eins, der zweite Kanal auf die Source 2 usw. gemappt.
Technische Umsetzung
Die technische Herausforderung für die Umsetzung des Projekts bestand zuerst grundlegen aus dem Empfangen und dem Umformatieren der Daten des Sensors, sodass diese in Binauralix verwertet werden können. Dabei bestand zunächst das Problem, dass Binauralix nur für MacOS und die Software für das Polhemus G4 System nur für Windows und Linux verfügbar sind. Da mir zu diesem Zeitpunkt neben einem MacBook auch ein Laptop mit Ubuntu Linux als Betriebssystem zur Verfügung stand, installierte ich die Polhemus Software für Linux.
Nach dem Bauen und Installieren der Polhemus G4 Software auf Linux, standen einem die fünf Anwendungen „G4DevCfg“, „CreateSrcCfg“, „g4term“, „g4display“ und „g4export“ zur Verfügung. Für mein Projekt muss zuerst mit „G4DevCfg“ alle verwendeten Devices miteinander verbunden und konfiguriert werden. Mit der Terminal-Anwendung „g4export“ kann man durch Angabe der zuvor erstellten Source-Configuration-File, der lokalen IP-Adresse des Empfänger-Gerätes und einem Port die Daten des Sensors über UDP übermitteln. Die Source-Configuration-File ist eine Datei, in welcher zum einen Position und Orientierung der Transmitter durch einen „Virtual Frame of Reference“ festgelegt werden und zum anderen Einstellungen zu Eintritts-Hemisphäre in das Magnetfeld, Floor Compansation und Source-Calibration-File vorgenommen werden können. Zum Ausführen der Anwendung müssen zu diesem Zeitpunkt die Transmitter und der Hub angeschaltet, der USB-Dongle am Laptop und der Sensor am Hub angeschlossen und der Hub mit dem USB-Dongle verbunden sein. Wenn sich nun das MacBook im selben Netzwerk wie der Linux-Laptop befindet, kann mit der Angabe des zuvor genutzten Ports die Daten empfangen werden. Dies geschieht bei meiner Klanginstallation in einem selbst erstellen MaxMSP-Patch.
Abbildung 6
In dieser Anwendung muss zuerst auf der linken Seite der passende Port gewählt werden. Sobald die Verbindung steht und die Nachrichten ankommen, kann man diese unter dem Auswahlfeld in der raw-Form betrachten. Die sechs Werte, die oben im mittleren Bereich der Anwendung zu sehen sind, sind die aus der rohen Nachricht herausgetrennten Werte für die Position und Orientierung. In dem Aktionsfeld darunter können nun finale Einstellung für die richtige Kalibrierung vorgenommen werden. Darüber hinaus gibt es auch noch die Möglichkeit die Achsen individuell zu spiegeln oder den Yaw-Wert zu verändern, falls unerwartete Probleme bei der Inbetriebnahme der Klanginstallation aufkommen sollten. Nachdem die Werte in Nachrichten formatiert wurden, die von Binauralix verwendet werden können (zu sehen rechts unten in der Anwendung), werden diese an Binauralix gesendet.
Das folgenden Videos bieten einen Blick auf die Szene in Binauralix und einen Höreindruck, während sich der Listener — gesteuert von den Sensor-Daten — durch die Szene bewegt.
Im folgenden möchte ich einen Einblick in die künstlerische und technische Entwicklung meines Stückes „Warten auf die Nacht“ geben. Dieser Beitrag wird fortlaufend aktualisiert und wird so den Entwicklungsprozess dokumentieren.
Das Stück soll von einer Performerin und einer Zeichnerin ausgeführt werden.
Technischer Bericht
Setup
Auf der Bühne steht die Performerin. Der Beamer muss so positioniert werden, dass das Bild über die Performerin hinweg auf die Projektionsfläche geworfen wird. Es sollte kein Schattenwurf der Performerin entstehen.
A link to download the applications can be found at the end of this blogpost. This project was also presented as a paper at the 2022 International Conference on Technologies for Music Notation and Representation (TENOR 2022).
Modularity in Sound Synthesis Tools
This blogpost walks through the structure and usage of two applications of machine learning (ML) methods for sound notation and synthesis. The first application is a modular sample replacement engine that uses a supervised classification algorithm to segment and transcribe a drum beat, and then reconstruct that same drum beat with different samples. The second application is a texture synthesis engine that uses an unsupervised clustering algorithm to analyze and sort large numbers of audio files.
The applications were developed in OpenMusic using the OM-SoX modular synthesis/analysis framework. This was so that the applications could be as modular as possible. Modular, meaning that they could be customized, extended, and integrated into a user’s own OpenMusic workflow. We believe this modularity offers something new to the community of ML and sound synthesis/analysis tools currently available. The approach to sound synthesis and analysis used here involves reading and querying many separate audio files. Such an approach can be encompassed by the larger term of „corpus-based concatenative synthesis/analysis,“ for which there are already several effective tools: the Caterpillar System, Audioguide, and OM-Pursuit. Additionally, OM-AI, ml.*, and zsa.descriptors are existing toolkits that integrate ML methods into Computer-Aided Composition (CAC) environments. While these tools are very precise, the internal workings of them are not immediately clear. By seeking for our applications to be modular, we mean that they can be edited, extended and integrated into existing CAC programs. It also means that they can be opened and up, examined, and reverse-engineered for a user’s own education.
One example of this is in figure 1, our audio analysis engine. Audio descriptors are implemented as subpatches in lambda mode, and can be selected as needed for the input audio.
Figure 1: Interchangeable audio descriptors are set as patches in lambda mode. Here, a patch extracting 13 MFCCs is being used.
Another example is in figure 2, a customizable distance function in our texture synthesis application. This is the ML clustering algorithm that drives the application. Being a patch built from smaller OpenMusic objects, it is not only a tool for visualizing the algorithm at work, it also allows a user to edit it. For example, the n-dimension euclidean distance function could be substituted with another distance function, if needed.
With the modularity of the project introduced, we will on the next page move on to the two specific applications.
Bis letzten August, waren meine Vorstellung zu Anwendungen maschinellen Lernens meist funktional, getrennt von einer ästhetischen Referenz zu meiner künstlerischen Praxis: PKWs, die Verkehrsampeln erkennen, oder Radiolog*innen die bösartige Regionen in menschlichem Gewebe entdecken – das sind die ersten Dinge, die mir einfallen. Es gibt bestimmt eine Kunst hinter der Programmierung dieser Anwendungen. Jedoch war mir noch nicht klar, wie sich maschinelles Lernen auf meine Welt der zeitgenössischen Musik beziehen könnte. Deswegen war meine Hauptinteresse, als ich anArtemi-Maria GiotisMachine Learning Workshop bei der 2021 impuls Akademie teilgenommen habe, persönliche künstlerische Verbindungen zu diesem Forschungsbereich herzustellen und zu sehen, auf welche Weise ich meine zugrundeliegenden ästhetischen Annahmen über künstlerischen Anwendungen von maschinellen Lernen hinterfragen kann. Das Ziel dieses Textes ist es, mit euch die Verbindungen zu teilen, die ich hergestellt habe. Ich werde den Kompositionsprozess meines Stücks für Stimme und Live-ElektronikShepherddurchgehen und es als Rahmen verwenden, um grundlegende Theorien und Methoden von maschinellen Lernen vorzustellen und zu skizzieren, wie ich ästhetisch auf sie reagiert habe. Ich werde nicht tief in technische Details gehen. Jedoch möchte ich anmerken, dass der technische Inhalt dieses Blogposts stark von Artemi-Maria Gioti inspiriert ist, die diesen Workshop geleitet hat und deren Forschung sich mit den kreativen Anwendungen von maschinellen Lernen in einer viel tieferen Weise beschäftigt. Ein tieferes Eintauchen in die vielfältigen Beziehungen zwischen maschinellen Lernen und Musik kann auf ihrerWebsitebegonnen werden.
Die grundlegende Idee von maschinellen Lernen lautet „Verbesserung durch Erfahrung“. Der Informatiker Tom M. Mitchell beschreibt es so: „Der Bereich maschinellen Lernen befasst sich mit der Frage, wie man Computerprogramme konstruiert, die sich durch Erfahrung automatisch verbessern.“ (Mitchell, T. (1998). Machine Learning. McGraw-Hill.). Diese Prämisse der „Verbesserung“ hat mich bereits mit nicht-trivialen Fragen konfrontiert. Wenn zum Beispiel maschinelles Lernen eingesetzt wird, um einen improvisierenden Duopartner zu schaffen, was genau versteht der Computer dann als „gute“ oder „schlechte“ Improvisation, wenn er an Erfahrung gewinnt? Das Beantwort dieser ersten Frage ist nötig, bevor man überhaupt mit der Entwicklung eines robusten Algorithmus für maschinelles Lernen beginnen kann. In meinem Stück Shepherd wurde die Elektronik darauf trainiert, meine Stimme zu erkennen, insbesondere ob ich flüstere, rede, schreie oder schweige. Mein Ziel war es jedoch nicht, einen perfekt genauen Erkennungsalgorithmus zu schaffen. Vielmehr wollte ich, dass die Effektivität und die Ineffektivität des Algorithmus bei der Konzeption des Stücks gleiche Wichtigkeit haben. Shepherd ist ein Performance-Stück nach einer Metapher von Jesus aus der christlichen Bibel: Schafe erkennen einen Hirten am Klang seiner Stimme (Johannes 10). Die Elektronik reagiert auf meine Stimme in einer Weise, die gleichzeitig sicher und unsicher ist. Diese Performance ist eine Reflexion über die Nuancen des spirituellen Glaubens, über die Art und Weise, wie Ungewissheit ein notwendige Teil an der Bildung von Überzeugung und Glauben ist. Hier war die Elektronik kein funktionales Instrument (etwas, das von meiner Stimme gesteuert werden sollte), sondern fungierte eher als zweiter Spieler (ein Duopartner, der auf meine Stimme mit einer eingeschränkte Unvorhersehbarkeit reagierte).
Momentan umfasst die Library zwei Funktionen, die sowohl mit CommonLisp, als auch mit schon bestehenden Funktionen aus dem OM-Package geschrieben sind.
Zudem ist die Komposition im Umfang der zu kontollierenden Parametern, momentan auf die Harmonik und die Stimmführung begrenzt.
Für die Zukunft möchte ich ebenfalls eine Funktion schreiben, welche mit den Parametern Metrik und Einsatzabstände, die Komposition auch auf zeitlicher Ebene erlaubt.
Entwicklung: Lorenz Lehmann
Betreuung und Beratung: Prof. Dr. Marlon Schumacher
Mein herzlicher Dank für die freundliche Unterstützung gilt Joseph Branciforte und
In dieser Einheit haben wir uns mit Variablen und Scoping (Gültigkeitsbereichen) beschäftigt. Insbesondere haben wir Konzepte zu lexicalische vs dynamische, sowie lokale vs. globale Gültigkeitsbereiche studiert. Hier finden Sie eine kurze Zusammenfassung. Im Zshg. mit diesem Thema findet sich am Ende des Beitrags noch ein interessantes Video zum Lambda Calculus, bzw. dem Unterschied zwischen zustands-basierten (state-based) und funktionalen (functional) Sprachen.
Variablen
Lokale Variablen
let => erzeugt lokale, lexikalische Variablen. Beispiel:
(let ((x 5) (y 10))
(+ x y)
)
=> 15 ; x und y können innerhalb des let-statements benutzt werden
Globale Variablen:
defvar => erzeugt Variable und weist einen Wert zu, allerdings nur wenn die Variable noch nicht definiert wurde. Beispiel:
(defvar *mydefvar* 'something)
defparameter => erzeugt Variable und weist ihr einen Wert zu. Beispiel:
(defparameter *mydefparameter* 'anotherthing)
defconstant => erzeugt eine Konstante. Beispiel:
(defconstant +pi+ 3.14)
; => globale Variablen sind (wie der Name schon sagt) global existent und überall benutzbar. PS Bitte beachten Sie die “earmuffs” Notation für globale *Variable*, bzw. +Konstanten+.
(* +pi+ 2)
=> 6.28
Setz-Operatoren
Die Werte von existenten lexikalischen und dynamischen Variablen lassen sich mit Setz-Operatoren (set, setq, setf) setzen*.
*Konstanten können nicht mit Setz-Operatoren verändert oder mit neuen Werten gebunden werden. Beispiel:
(setf +pi+ 1.0) ; => ERROR
Lexikalisch (statisch) vs Dynamisch (special)
Lexikalisch: Der Wert der Variablen wird durch den umgebenden Text (also “räumlich”) der Funktionsdefinition bestimmt. Beispiel:
(let ((x 5)) (defun return-x () x)
)
(let ((x 10)) (return-x)
)
=> 5 ; der Wert von x aus der Umgebung der Funktionsdefinition
Dynamisch: Der Wert der Variablen wird zur Funktionslaufzeit (also zeitlich) bestimmt. Beispiel:
(defparameter *x* 5)
(defun return-x () *x*)
(setf *x* 10)
(return-x)
=> 10 ; der Wert von *x* zur Laufzeit der Funktion
Closures
Als Closure wird ein Konstrukt (Umgebung und Funktionsdefinition) bezeichnet, welches Funktionen Zugriff auf (lexikalische) Variablen erlaubt, die ausserhalb der Funktionsdefinition selbst, jedoch innerhalb des lexikalischen Scopes in der die Funktionen definiert wurden, gebunden sind. Beispiel:
A fundamental distinction in scoping is what “part of a program” means. In languages with lexical scope (also called static scope), name resolution depends on the location in the source code and the lexical context, which is defined by where the named variable or function is defined. In contrast, in languages with dynamic scope the name resolution depends upon the program state when the name is encountered which is determined by the execution context or calling context. In practice, with lexical scope a variable’s definition is resolved by searching its containing block or function, then if that fails searching the outer containing block, and so on, whereas with dynamic scope the calling function is searched, then the function which called that calling function, and so on, progressing up the call stack.[4] Of course, in both rules, we first look for a local definition of a variable.
Most modern languages use lexical scoping for variables and functions, though dynamic scoping is used in some languages, notably some dialects of Lisp, some “scripting” languages like Perl, and some template languages.[c] Even in lexically scoped languages, scope for closures can be confusing to the uninitiated, as these depend on the lexical context where the closure is defined, not where it is called.
Lexical resolution can be determined at compile time, and is also known as early binding, while dynamic resolution can in general only be determined at run time, and thus is known as late binding.
Klicken Sie hier für eine deutsche Version dieses Textes.
Up until this past August, my impressions of what machine learning could be used for was mostly functional, detached from any aesthetic reference point within my artistic practice. Cars recognizing stop signs, radiologists detecting malignant legions in tissue; these are the first things to come to my mind. There is definitely an art behind programming these tasks. However, it wasn’t clear to me yet how machine learning could relate to my world of contemporary concert music. Therefore, when I participated in Artemi-Maria Gioti’s machine learning workshop at impuls Academy 2021, my primary interest was to make personal artistic connections to this body of research, and to see what ways I could interrogate my underlying aesthetic assumptions in artistic applications of machine learning. The purpose of this text is to share with you the connections I made. I will walk through the composition process of my piece Shepherd for voice and live electronics, using it as a frame to touch upon basic machine learning theories and methods, as well as outline how I aesthetically reacted to them. I will not go deep into the technicalities of machine learning – there are far more qualified people than I for that specific task. However, I will say that the technical content of this blogpost is inspired heavily from Artemi-Maria Gioti, who led this workshop and whose research covers the creative applications of machine learning in a much deeper way. A further dive into the already rich world of machine learning and music can be begun at her website.
A fundamental definition of machine learning can be framed around the idea of improvement through experience. As computer scientist Tom M. Mitchell describes it, “The field of machine learning is concerned with the question of how to construct computer programs that automatically improve with experience.” (Mitchell, T. (1998). Machine Learning. McGraw-Hill.). This premise of ‘improvement’ already confronted me with non-trivial questions. For example, if machine learning is utilized to create an improvising duo partner, what exactly does the computer understand as ‘good’ or ‘bad’ improvisation, as it gains experience? Before even beginning to build a robust machine learning algorithm, answering this preliminary question is an entire undertaking in and of itself. In my piece Shepherd, the electronics were trained to recognize the sound of my voice, specifically whether I was whispering, talking, yelling, or being silent. However, my goal was not to create a perfectly accurate recognition algorithm. Rather, I wanted the effectiveness and the ineffectiveness of the algorithm to both play equal roles in achieving the piece’s concept. Shepherd is a performance piece takes after a metaphor from Jesus in the christian bible – sheep recognize a shepherd by the sound of their voice (John 10). The electronics reacts to my voice in a way that is simultaneously certain and uncertain. It is a reflection, through performance, on the nuances of spiritual faith, the way uncertainty necessarily partakes in the formation of conviction and belief. Here the electronics were not functional instrument (something designed to be controlled by my voice), but rather were functioning more as a second player (a duo partner, reacting to my voice with a level of unpredictability).
Concretely in the program, the electronics returned two separate answers for every input it is given (see figure 1). It gives a decisive, classification answer (“this is ‘silence’, this is ‘whispering’, this is ‘talking’, etc.), and it gives an indecisive, erratic answer via regression (‘silence: 0.833; whispering: 0.126; talking: 0.201; yelling: 0.044’). And important for this concept of conceiving belief through doubt, the classification answer is derived from the regression answer. The decisive answer (classification) was generally stable in its changes over time, while the indecisive answer (regression) moved more quickly and erratically. Overall, this provided a useful material for creating dynamic control of the actual digital sounds that the electronics produced. But before touching on the DSP, I want to outline how exactly these machine learning algorithms operate, how the electronics learn and evaluate the sound of my voice.
Figure 1: Max MSP and Wekinator (off-screen) analyze an audio’s MFCCs to give two outputs on the nature of the input audio. The first output is from a regression algorithm, the second is from a classification algorithm.
In order for the electronics to evaluate my input voice, it first needs a training set, a collection of data extracted from audio of my voice, with which it could use to ‘learn’ my voice. An important technical point is that the machine learning algorithm never observes actual audio data. With training and testing data, the algorithm is always looking at numerical data (here called ‘descriptors’) extracted from the audio. This is one reason machine learning algorithms can work in realtime, even with audio. As I alluded to, my voice recognition program is underpinned by two machine learning concepts: classification and regression. A classification algorithm will return a discrete value from its input data. In my case, those values are ‘silence’, ‘whispering’, ’talking’, and ‘yelling’. To make a training set then, I recorded audio of each of these classes (4 audio files in total), and extracted MFCCs (Mel-Frequency Cepstrum Coefficients) from it. MFCC’s are a representation a sound’s spectral energy calibrated to the range of typical human auditory perception, and are already commonly used in speech recognition programs, music-information retrieval applications, and other applications based around timbre-recognition.
I used the Max MSP library Zsa.descriptors to calculate my MFCCs. I also experimented with other audio descriptors such as spectral centroid, spectral flatness, amplitude peaks, as well as varying numbers of MFCC’s. Eventually I discovered that my algorithm was most accurate when 13 MFCCs were the only descriptor, and that description data was taken only about fivetimes a second. I realized that, on a micro-level timescale, my four classes had a lot similarity. For example, the word ‘synthesizer,’ carried lots of ’s’ noise, which is virtually the same when whispered as when talked. Because of this, extracting data at an intentionally slower rate gave the algorithm a more general picture of each of my voice-classes, allowing these micro-moments of similarity to be smoothed out.
The standard algorithm used for my voice recognition concept was classification. However, my classification algorithm was actually built using a second common machine learning algorithm: regression. As I mentioned before, I wanted to build into my electronics a level of ‘indecision’, something erratic that would contrast the stable nature of a standard classification algorithm. Rather than returning discrete values, a regression algorithm gives a new ‘predictive’ value, based on a function derived from the training set data. In the context of my piece, the regression algorithm does not return a specific voice-class. Rather, it gives four percentage values, each corresponding to how close or far my input is to each of the four voice-classes. Therefore, though I may be whispering, the algorithm does not say whether I am whispering or not. It merely tells me how close or far away I am from the ‘whispering’ data that it has been trained on.
I used a regression algorithm in Wekinator, a simple and powerful machine learning tool, to build my model (see figure 2). Input audio was analyzed in Max MSP, and the descriptor data was sent via OSC to Wekinator. Wekinator built the predictive regression model from this data and then sent output back to Max MSP to be used for DSP control. In Max, I made my own version of a classification algorithm based on this regression data.
Figure 2: Wekinator is evaluating MFCC data from Max MSP and returning 4 values from 0.0-1.0, indicating the input’s similarity to the four voice classes (silence, whispering, talking, yelling). The evaluation is a regression model trained on 752 data samples.
All this algorithm-building once again returns me to my original concern. How can I make an aesthetic connection with these concepts? As I mentioned, this piece, Shepherd is for my solo voice and live electronics. In the piece I stand alone on a stage, switching through different fictional personas (a speaker at a farming convention, a disgruntled restaurant chef, a compilation video of Danny Wolfers saying the word ‘synthesizer,’ and a preacher), and the electronics reacts to these different characters by switching through its own set of personas (sheep; a whispering, whimpering sous chef; a literal synthesizer; and a compilation of christian music). Both the electronics and I change our personas in reaction to each other. I exercise some level control over the electronics, but not total. As I said earlier, the performance of the piece is a reflection on the intertwinement of conviction and doubt, decision and indecision, within spiritual faith. Within this concept, the idea of a machine ‘improving’ towards ‘perfection’ is no longer an effective framework. In the concept, and consequently in the music I attempted to make, stable belief (classification) and unstable indecision (regression) were equal contributors towards the musical relationship between myself and the electronics.
Based on how my voice was classified, the electronics operated one of four DSP modules. The individual parameters of a given module were controlled by the erratic output data of the regression algorithm (see figure 3). For example, when my voice was classified as silent, a granular synthesizer would create textures of sheep-like noises. Within that synthesizer, the percentage levels of whispering and talking ‘detected’ within the silence would manipulate the pitch shifting in the synthesizer (see figure 4). In this way, the music was not just four distinct sound modules. The regression algorithm allowed for each module to bend and flex in certain directions, as my voice subtly suggested hints of one voice class from within another. For example, in one section I alternate rapidly between the persona of a farmer talking at a farming convention, and a chef frustratingly whispering at his sous chef. The electronics moved consequently between my whispering and talking DSP modules. But also, as my whispering became more frustrated and exasperated, the electronics would output higher levels of talking in its regression algorithm. Thus, the internal drama of my theatricalperformances is reacted to by the electronics.
Figure 3: The classification data would trigger one of four DSP modules. A given DSP module would receive the regression values for all four vocal classes. These four values would control the parameters of the DSP module.
Figure 4: Parameter window for granular synth triggered when the electronics classifies my voice as ‘silent’. The amount of whispering and talking detected in the silence would control the pitch of the grain. The amount of silence detected in the silence controlled the grain’s duration. Because this value is relatively static during actual silence from my voice, a level of artificial duration manipulation (seen a the top of the window) was programmed.
I want to return to Tom Mitchell’s thesis that machine learning involves computer improvingautomatically through experience. If Shepherd is a voice recognition tool, then it is inefficient at improvement. However, Shepherd was not conceived as a tool. Rather, creating Shepherd was more so a cultivation of a relationship between my voice and the electronics. The electronics were more of a duo partner, and less of an instrument. To put this more concretely, I was never looking for ‘accurate’ results from the machine. As I programmed, I was searching for results that illustrated Shepherd’s artistic concept of belief intertwined with doubt. In this way, ‘improving’ the piece did not mean improving the algorithm’s accuracy. It meant ‘improving‘ the relationship between myself and the electronics. One positive from this approach is that the compositional process was never separated from the programming of the electronics. Both developed in tandem. The composing this piece brought me to the realization that creative applications of machine learning can be applied at every level of its discourse. If you ware interested in hearing a recording of this performance, a bootleg recording of the premiere can be found here.
References:
Artemi-Maria Gioti – composer and artistic researcher working in the field of artificial intelligence.
Wekinator – free, open-source software created by Rebecca Fiebrink that uses machine learning to create musical instruments, game interfaces, computervision, and other tools in sound and animation.
Zsa.descriptors – library for real-time sound descriptors analysis for Max MSP developed by Mikhail Malt and Emmanuel Jourdan.