Hey @all und schonmal vielen Dank für diese ausführlichen und netten Antworten! Ich versuche in diesem Beitrag auf alles so kurz wie es geht einzugehen.
@Jenzz
Danke für den Hinweis. Ich bin bisher sehr technisch unterwegs gewesen, weil ich mich aktiv in der Live-Coding Community rumtreibe. Aus diesem Grund hat mich die „Musiker nahe“ Sicht interessiert. Aber Ich werde sicherlich mal auf
www.sequenzer.de vorbei schauen.
@FerdinandK
Ich finde den Gedanken interessant, dass man mit einer Kombination mehrerer Geräte auch ans Ziel kommt. Sicherlich ist es hier eine Frage der Komplexität des eigenen Setups und was man erreichen möchte. Letztendlich betrachte ich eine von mehreren möglichen Interface-Arten in Kombination mit Live-Looping: nämlich Text. Es handelt sich also um eine klare Abgrenzung zu anderen Interface-Arten wie physischen-Geräten, grafisch-, sowie patcher- und knoten-basierten Ansätzen.
Zu der (funktionalen) Sprache TidalCycles gibt es ein eigenes Ökosystem und auch eine Community. Außerdem ist es eine Domänensprache um Muster zu schreiben und diese zu manipulieren. Diese Muster wiederum werden in Schleife wiedergegeben, bis man sie verändert. Hierdurch sind Polyrythmen, Polymetrik, Kanonstrukturen oder auch Fugen-artige Gebilde leicht live umsetzbar. Und man kann die Muster sehr schnell verändern, erweitern und neu anordnen (das ist auch der Sinn des Live-Codings). Es erfordert ein starkes Umdenken weil man Zeit und Notenanordnungen anders betrachtet, d.h. nicht mehr sequenziell wie es primär bei einer Partitur ist.
Generell ist im Design der Sprache eingebaut, dass ein laufender Prozess nicht durch Syntaxfehler abstürzen kann (da funktional) und man mit wenig tippen einen großen Effekt erzeugen kann. Auch wenn es für Live-Coding optimiert ist, kann man sich auch Code vorschreiben und fest definierte Effekte mit MIDI steuern (oder MIDI Geräte mit der Sprache steuern). Aber der Vorteil zur Individualisierung ist eben, dass man nicht durch UI-Design Entscheidungen limitiert ist. Der Nachteil ist eindeutig, dass man nicht die Breite der Nutzer erreicht. Dafür gibt es allerdings schon sehr gute Lösungen, wie du auch geschrieben hast. Was ich technisch umsetze, ist ein angepasster Looper, den man damit steuern kann. Er ist also speziell auf die Live-Coding Domäne zugeschnitten.
Was du in deinem letzten Absatz beschreibst ist der Unterschied zwischen Live-Coding und Live-Algorithmen. Beim Live-Coding greift man direkt und bewusst in einen laufenden Prozess ein. Es handelt sich also um ein Werkzeug und quasi um ein eigenes Instrument, welches man lernen kann. Bei Live-Algorithmen wird ein Algorithmus abgespielt und es werden maximal die Parameter verändert. Aber der eigentlich Algorithmus wird nicht mehr verändert (z.B. bei maschinellem Lernen oder Markov-Modellen, aber das führt hier zu weit). Hier hat man maximale Sicherheit und die Abläufe sind praktisch automatisiert.
Vielleicht muss ich auch einfach festhalten, dass es nicht mehr, weniger oder besser kann, sondern das es einfach was anderes ist?
@Calmar
Danke das du dein Setup geteilt hast! Die Anpassung des eigenen Setups, basierend auf das was man erreichen möchte ist auch ein sehr wichtiger Punkt. Ich plane daher auch Variationen des Loopers, die spezialisiert sind auf verschiedene Anwendungsszenarios. Gerade das Thema „Resourcen frei machen“ für eine Live-Performance sehe ich auch als sehr wichtig an (das hat auch
@FerdinandK schon so geschrieben).
Ich habe Live-Looping bisher übersetzt als „Live-Sampling mit Wiedergabe der Aufnahmen in Schleife“. Sonst würde das live anordnen von Samples oder Synthesizern mit TidalCycles schon selbst ein Live-Loop sein. Wenn es sowas wie eine strenge anerkannte Definition gäbe, wäre ich dafür sehr dankbar (idealerweise mit Quelle).
Beim Live-Coding wird der Code tatsächlich auf eine Leinwand projiziert und gegebenenfalls mit Visuals (teilweise auch als Live-Coding) unterstützt/interessanter präsentiert. Transparenz ist hier ein großes Stichwort und wurde seit den Anfangstagen des Live-Codings schon so gemacht. Es geht in gewisserweise auch darum, den kreativen Prozess von Improvisation und Musikerzeugung einem Publikum "sichtbar" zumachen. Und es wurde auch schon untersucht, dass Code auf Leinwand zum Erzeugen von Musik auch bei nicht Programmierern befremdlich und erklärend zugleich ist. So kann man den Aufnahmeprozess durch Code und Visuals transparenter machen (gerade bei einem größeren Setup, bspw. In einem Band Kontext). Also das geht exakt in die Richtung die du dir vorstellst. Ein Beispiel habe ich schon selbst einmal umgesetzt und kann so aussehen:
https://github.com/thgrund/tidal-looper/blob/master/feedback/hydra-example.gif
In den letzten Jahren gab es einige „Algoraves“, also Konzerte mit algorithmischen Tanzmusik. Live-Coder sind hierbei tendenziell häufiger vertreten. Diese neuartige Phänomen kann, für allgemein Interessierte, dieses YouTube-Video allerdings besser erklären als ich hier in diesem Post:
@All
Nochmal danke für eure Zeit und aufschlussreichen Kommentare!
