Published in: zweikommasieben Magazin #17
Renick Bell - Code Potential
Renick Bell ist ein Computer Musiker. Nicht so, wie heutzutage viele mit dem Computer Musik machen, sondern wie jemand der die inhärenten Möglichkeiten der Maschine zur Musikkomposition nutzt. Durch das Nutzen von Algorithmen und Code für seine Arbeit befreit er sich von aufwendigen, meist grafischen Schnittstellen. Es geht auch ohne Ableton, im Studio und auf der Bühne. Etwas zu Release oder so…
Neben seiner Arbeit als Produzent und Performer elektronischer Musik war er Teil des Graduiertenprogramms der Tama Art University in Tokio, Japan, wo er seit 2006 lebt. Das nachstehende Gespräch mit Mathis Neuhaus fand statt in einem kleinen Südindischen Restaurant in Kanda, Tokio und berührt Fragen der Wahrnehmung von Algorithmen in der Gesellschaft, live coding als demystifizierende Strategie und die Unterschiede zwischen der Produktion und der Performance elektronischer Musik.
[1] http://empty-lake.u-i-q.org/
Mathis Neuhaus: Ich möchte unser Gespräch gerne beginnen, indem ich von meiner eigenen Perspektive auf Algorithmen in der Musik erzähle. Diese unterscheidet sich recht deutlich von deiner, aber dazu später dann mehr. Vor zwei Jahren war ich in New York, um eine Reportage mit dem Titel The Taste Machine zu recherchieren, die sich mit der Frage auseinandersetzt, ob Algorithmen fähig sind, Geschmack zu bilden oder zu beeinflussen.
Renick Bell: Und zu welchem Schluss bist du gekommen?
MN: Geschmack ist natürlich ein recht vager Begriff, aber Plattformen wie Spotify verändern definitiv die Art und Weise, wie Menschen Musik hören. Playlists und die Algorithmen, die im Verborgenen hinter diesen arbeiten, machen das, was früher eines der Alleinstellungsmerkmale vom Radio oder Plattenläden war: das Empfehlen neuer, überraschender und unbekannter Musik. Und hier spielt Spotify, zumindest im Mainstream, mittlerweile eine sehr wichtige Rolle. Ich kenne Menschen, die sich für das Entdecken neuer Musik ausschliesslich auf die algorithmischen Empfehlungen der Plattform verlassen. Es gibt natürlich noch immer die, die sich selber auf die Suche machen – aber das sind Ausnahmen. Und Spotify ist keine Ausnahme, sondern die Regel. Meine Perspektive auf Algorithmen ist also das Analysieren ihres kulturellen Einflusses, während du sozusagen von der anderen Seite des Bildschirms herdenkst.
RB: Es gibt natürlich eine Vielzahl unterschiedlicher Algorithmen, die in einer ebenso grossen Vielzahl verschiedener Gebiete ihre Anwendung finden. Aber letztendlich benötigen sie alle Programmierfähigkeiten, um implementiert zu werden.
MN: Wie kamst du zu der Entscheidung, Algorithmen für die Musikproduktion zu nutzen? Warst du von Anfang an interessiert am Potential der Maschine oder auch involviert in konventioneller Musik? Oder anders gefragt: Könntest du deinen musikalischen Werdegang skizzieren?
RB: Als kleines Kind habe ich in Knabenchören gesungen und mit neun fing ich an, Klavier zu spielen. Während der High-School habe ich dann auch Schlagzeug und Gitarre gespielt. Das erste Mal in Kontakt gekommen mit Musik, die von einer Maschine gemacht wurde, bin ich durch den Yamaha PortaSound PSS-560 Synthesizer aus dem Jahre 1990. Der hatte zum Beispiel eine Funktion, die einige Parameter der Stimme veränderte oder einen rudimentären Drumcomputer, mit dem 260 BPM Stücke oder andere merkwürdige Geräusche produziert werden konnten. Als Universitätsstudent wollte ich einfach nur Musik machen und war auf der Suche nach dem richtigen Outlet, ohne es jemals wirklich zu finden. Ich wollte all die Instrumente, die ich zuvor erwähnt habe, gleichzeitig nutzen und naheliegend war das Spielen in Bands. Ich spielte in Hardcore und Screamo Bands alle Instrumente in unterschiedlichen Kontexten – aber Bands sind auf Dauer schwer zu managen. Zeitgleich begann ich, gemeinsam mit einem Freund ein Studio einzurichten und wir produzierten für Hip-Hop Gruppen sowie unsere eigenen Techno-Tracks. Wir versuchten Musik zu machen, die klang wie das, was wir zur damaligen Zeit gerne hörten: für mich waren das Veröffentlichungen auf Mo’Wax und Drum‘n‘Bass. Ich habe dann lange solche Sachen produziert und die Stücke an BBC 1Xtra und an Labels geschickt, um auf irgendwelchen 12inches zu landen. Ich wollte aber auch unbedingt elektronische Musik live auf der Bühne spielen. Im Studio Snare Samples von A nach B zu ziehen ist natürlich so weit weg von live, wie nur irgendwie möglich. Also stellte ich mir die Frage, wie ich die Dinge, die ich machte, auf der Bühne umsetzen könnte.
MN: Wann war das?
RB: Noch vor Ableton, Mitte der 1990er Jahre. Im College studierte ich elektronische Musik, deswegen waren mir Werkzeuge wie CSound oder Max/MSP nicht fremd und ich dachte, dass ich diese möglicherweise für meine Performances nutzen könnte. Im Masterstudium habe ich dann letztendlich eine generative Musiksoftware mit grafischer Benutzeroberfläche in SuperCollider gebaut. Das hat ganz gut funktioniert, aber man verliess sich doch immer noch auf Knöpfe und Regler und musste alles mit der Maus machen. Es war wie Gitarre mit einem Finger zu spielen: nicht wirklich zufriedenstellend. Ich dachte, dass ich vielleicht die falschen Werkzeuge nutzte – d.h. die grafische Benutzeroberfläche – und schaute mir deswegen auch Programmiersprachen genauer an. Während meiner Recherche stiess ich 2004 auf den Artikel Hacking Perl In Nightclubs von Alex McLean. Ich las den Artikel, in dem es um live coding in Clubs ging, und dachte, dass das eine coole Idee sei, die sich aber gleichzeitig total absurd anhörte. Warum sollte man das machen? Ich habe den Kern der Sache nicht erkannt. Um 2006 programmierte ich viel in Haskell, einer Programmiersprache die ich noch immer hauptsächlich nutze, und merkte, dass ich Sounds produziere, direkt im Code und ohne überhaupt eine grafische Benutzeroberfläche nutzen zu müssen – und es funktionierte. Das war der Moment, an dem ich verstand was Alex McLean in seinem Artikel sagen wollte. Ich gab auf, eine Benutzeroberfläche bauen zu wollen und begann, direkt im Code zu komponieren.
MN: Du verzichtest auf den Mittelsmann.
RB: Genau. Und es funktionierte tatsächlich und war das Outlet, das ich lange gesucht habe. Als ich Klavier spielte, war ich nie wirklich gut darin, meine beiden Hände unabhängig voneinander arbeiten zu lassen. Mein Können am Schlagzeug reichte für ein Trap Set, aber nicht mehr. An der Gitarre war es ähnlich. Meine technischen Fähigkeiten waren immer begrenzt. Aber ich habe auch die ganze Zeit programmiert. Mein Vater hatte schon als ich fünf war einen TI-994a Computer zu Hause. Ich kann entsprechend ziemlich gut tippen und realisierte endlich, dass ich diese technische Fähigkeit direkt nutzen kann, um Musik zu machen. Es ergab Sinn. Ich entschied mich dazu, nicht jedes einzelne Sample hin und herziehen zu wollen und jedes einzelne Sample an genau die richtige Stelle ziehen zu müssen. Dafür habe ich keine Zeit. Ich will Musik generieren und nicht jedes Detail spezifizieren müssen. Obwohl das Komponieren mit Hilfe von Code natürlich exakte Spezifikationen jedes musikalischen Ereignisses in irgendeiner Form verlangt. Ein zufällig generiertes Detail ist präzise spezifiziert als zufällig. Der Komponist ist letztendlich verantwortlich für alle Details.
MN: Du erwähntest, dass du die Perfomance im Kopf hattest. Hast du das Potential des Komponierens im Code dafür auch unmittelbar erkannt?
RB: Mein Ziel war die Bühne, aber auf dem Weg dorthin realisierte ich, dass ich diese generativen Werkzeuge auch zum Komponieren nutzen kann. Und es stimmt: ich kann so viel mehr Musik produzieren als jemals zuvor. Der Computer kann all die Details generieren, für die ich vorher sechs Monate im Studio gebraucht habe. Ich kann die Maschine dazu bringen das in einer Sekunde zu erledigen. Ich habe diesen Vorteil erkannt – aber der ursprüngliche Grund war, den Code für die Perfomance zu nutzen. Das war auch im Sinne dessen, was Alex McLean und Nick Collins seit den frühen 2000er Jahren machten. Sie sind die Schöpfer der Algoraves, bei denen Menschen live auf der Bühne Code schreiben und andere zu der in Echtzeit produzierten Musik tanzen. Die Tanzenden können den Prozess nachverfolgen, indem ein Stream der Bildschirme an die Wand projiziert wird.
MN: Würdest du dich also eher als Performer denn als Produzent bezeichnen?
RB: Nein, denn bevor ich anfing, Code zu nutzen, war ich äusserst involviert als Produzent elektronischer Musik. Ich performte, bevor ich produzierte, aber als elektronischer Musiker produzierte ich bevor ich performte.
MN: Der Prozess des ‹Live Codings› erinnert mich an Jazz.
RB: Auf jeden Fall. Improvisation spielt eine wichtige Rolle. Es teilt viele Gemeinsamkeiten mit Jazz. In meiner Software kann ich das gleiche Stück nie zweimal produzieren, selbst wenn ich wollte. Dieses Feature existiert nicht. Ich versuche das zu ändern, aber momentan kann ich kein Stück reproduzieren. Die Art und Weise wie ich Code nutze und wie mein Setup aufgebaut ist sorgt dafür, dass ich nie komplett sicher sein kann, wie das Endergebnis genau klingen wird. Das Publikum und ich hören alles gemeinsam zum ersten Mal. Und wenn es mir nicht gefällt, ändere ich es. So navigiere ich meine Performance: ich versuche Dinge und wenn diese cool und überraschend sind, lasse ich sie laufen und wenn nicht wechsle ich so schnell wie möglich zu etwas Anderem.
MN: Ich möchte gerne über das Scheitern sprechen: Wie kann in deinem Modus überhaupt irgendetwas scheitern? Gibt es ein Potential dafür überhaupt noch?
RB: Ich war vor kurzem auf einer Konferenz, bei der Shelly Knotts, die Teil des Duos Algobabez ist, eine Keynote gehalten hat. In einem Teil ihrer Präsentation hat sie sich genau mit dieser Frage des Scheiterns auseinandergesetzt und betont, dass es ein Prinzip und akzeptierter Part des Live Codings ist. Die Community hat kein Problem damit. Das System, das man nutzt kann manchmal für Probleme sorgen. Es kommt vor, dass alles runterfährt, weil man all seinen RAM verbraucht hat. Es gibt eine technische Gefahr, aber die Leute kümmert das nicht wirklich. Ich versuche zwar, mein System so zu gestalten, dass es immun ist gegen solch technische Fehler, aber aus musikalischer Perspektive gibt es auch immer mal wieder Dinge, die seltsam klingen oder die mir gar nicht gefallen. Aber während ich sie ändere finde ich manchmal Elemente, die ich doch noch ein bisschen laufen lassen möchte. Wenn das passiert, bin ich vielleicht mit meiner ursprünglichen Idee gescheitert, habe sie aber auf andere Art und Weise nutzen können.
MN: Unterscheidet sich deine Herangehensweise an das Komponieren von Musik? Gibst du dir mehr Zeit oder arbeitest du mit Sketchen?
RB: Dancemusic ist bis zu einem gewissen Grad schablonenhaft. Aber es gibt für mich einen grossen Unterschied zwischen dem Komponieren und der Perfomance: wenn ich produziere, habe ich für ein Stück meist ein Sampleset und einen Rhythmus, weil mir zu dem Zeitpunkt ein bestimmtes Sampleset und ein bestimmter Rhythmus besonders gefällt. Damit improvisiere ich dann für eine gewisse Zeit und hoffentlich ergeben sich aus diesem Prozess Dinge, die ich mag. Ich lasse zum Beispiel nur die Drums laufen, dann nur die Synthesizer Parts und dann nur die Melodie. Ich nehme diese Teile einzeln auf, und editiere sie anschliessend zusammen, sodass es Sinn ergibt. Ich destilliere aus einem Prozess, der eine Stunde oder länger dauert, ein Ergebnis, das drei oder vier Minuten lang ist. Wenn ich hingegen auf der Bühne bin, lasse ich selten etwas länger als eine Minute laufen, bevor ich Dinge verändere. Ich versuche mich schnell zu bewegen.
MN: So wie ich das verstehe, ist das visuelle Element des Live Codings genauso wichtig wie die Musik selbst?
RB: Das stimmt. Eine Projektion hinter dem Perfomer zeigt, was er oder sie in genau dem Moment macht. Es geht darum, den Prozess offenzulegen.
MN: Es wird transparenter und der Schleier gelüftet.
RB: Ja, und das ist eine sehr wichtige Sache für die Community: den Prozess des Codens zugänglicher zu machen. Ein gutes Beispiel dafür sind Shelly Knotts, die ich schon erwähnt habe, und Joanne Armitage. Sie organisieren Workshops für Frauen, die Werkzeuge des live codings kennenlernen möchten. Nach ein paar Tagen sind alle Teilnehmerinnen in der Lage, Musik zu produzieren und es zeigt, dass das was wir machen vielleicht nicht extrem simpel, aber auch nicht unglaublich schwierig ist. Personen wie Shelly und Joanne helfen sehr dabei, den Prozess zu entmystifizieren. Jeder kann dieses Zeug.
MN: Ist der Code wichtiger als das Ergebnis?
RB: Ich kenne das Argument mancher die sagen, dass der Prozess zu sehr und zum Nachteil des Ergebnisses in den Mittelpunkt gerückt wird. Vielleicht stimmt das in einigen Fällen. Ich hoffe nicht in meinem, denn mir ist das Ergebnis äusserst wichtig. Aber es muss die Frage gestellt werden: was ist das Ergebnis? Nur die Musik? Das ist nicht der einzige und wichtigste Punkt beim Live Coding. Die meisten Teilnehmer eines Algoraves wollen, dass die Leute tanzen und sie wollen etwas produzieren, dass cool klingt. Aber sie wollen auch ihren Prozess offenlegen und eine Community aufbauen. Der Prozess ist nicht alleine entscheidend, weil es kein singuläres Ziel gibt, sondern viele verschiedene. Und wegen limitierter Fähigkeiten oder situativer oder anderer Gründe werden manchmal einige Ziele eher erreicht als andere.
MN: Die Algorave Community scheint grossen Wert auf Inklusion zu legen und einen anti-kommerziellen Zugang zu verfolgen. Algorithmen spielen natürlich eine grosse Rolle und mich würde interessieren, ob du der Beobachtung zustimmst, dass es eine Dialektik zwischen diesem Zugang und der Tatsache gibt, dass Algorithmen mehr und mehr zu sehr kommerziellen Zwecken genutzt werden?
RB: Algorithmen sind lediglich Werkzeuge und jeder kann diese für jeden selbstgewählten Zweck nutzen. Falls jemand die Werkzeuge nutzen möchte, um elektronische Musik zu kreieren ist das eine Sache und falls jemand die gleichen Werkzeuge für kommerzielle Zwecke nutzen möchte, eine andere. Es gibt unzählige Algorithmen, die einfach nur Befehlssätze sind. Aber wir können diese nutzen und ihre Aufgabe ändern. Zum Beispiel ist ein Algorithmus, den ich zur Komposition von Rhythmen nutze, ursprünglich geschrieben worden, um den Wachstum von Pflanzen zu beschreiben. Ich habe dieses sogenannte Lindenmayer System genommen und dessen Aufgabe geändert, sodass es nichts mehr mit der ursprünglichen Idee zu tun hat. Andersherum könnte auch jemand von uns geschriebenen Code für kommerzielle Zwecke nutzen. Eines meiner grössten Anliegen ist die Paranoia, die Algorithmen umgibt. Falls Menschen besser informiert wären darüber, wie und wo Algorithmen überall zur Anwendung kommen, würden sie möglicherweise anders urteilen. Es gibt das Missverständnis, dass Dinge ausser Kontrolle geraten, sobald Algorithmen involviert sind. Aber schlussendlich sind es Menschen, die die kommerziellen Entscheidungen treffen. Meine Sorge ist, dass diese Tatsache aus dem Blick gerät und Algorithmen als grundsätzlich abzulehnend eingestuft werden. Ich möchte der Meinung vorbeugen, Algorithmen seien etwas Böses, dem nicht vertraut werden kann. Der Diskurs sollte nuancierter sein und ich hoffe, dass Algoraves und live coding Initiativen sind, die einen nuancierteren Blick liefern.