Eventueller Mehrwert von Looping im Live-Coding Kontext (TidalCycles)

von thgrund, 29.09.20.

  1. thgrund

    thgrund Registrierter Benutzer

    Im Board seit:
    29.09.20
    Zuletzt hier:
    30.10.20
    Beiträge:
    2
    Kekse:
    0
    Erstellt: 29.09.20   #1
    Hallo liebe Musiker,

    ich schreibe derzeit meine Master-Thesis zum Thema Live-Looping und Sample-Manipulationen im Live-Coding Kontext. Und ich sammle gerade Punkte zum Thema "allgemeine Limitierung von Loopern" und den Mehrwert der sich evtl. durch den Live-Coding Kontext ergeben. Ich habe dazu ein paar Punkte gefunden die Interessant sein könnten und bitte um Feedback:
    1. Es werden Kanon-Strukturen möglich, da ich auf den Loop zugreifen kann, während er aufgenommen wird.
    2. Ich kann Loops manipulieren (Resynthesieren), neu anordnen und neu loopen.
    3. Ein Loop bestimmt nicht die Länge der anderen Loops, kann aber konfiguriert werden.
    4. Es ist theoretisch möglich eine ganze Band oder gezielt einzelne Musiker zu loopen.
    5. Durch das Live-Coding können Samples und Live-Loops vermischt werden (keine Limitierungen durch Presets oder Effekte).
    Für den ersten Punkt (Kanon-Struktur) habe ich einen kleinen Loop (Bruder Jakob) mit einem Stage Piano aufgenommen, den ich zeitversetzt im Stereo-Panning „On-the-fly“ wiederholt habe. Im zweiten Durchgang wird der Loop in verschiedenen Geschwindigkeiten parallel gespielt. Hierfür habe ich kein Video vorbereitet, aber eine Audiodatei (zu finden unter https://info-grund.com/owncloud/index.php/s/nyn4hb9e2L1FjJF)

    Für die Punkte 2 und 3 habe ich allerdings ein kleines Video, welches das demonstrieren soll:


    Mich würde sehr interessieren, ob ihr/sie in den vorgestellten Punkten einen Mehrwert seht oder ob es hierfür bereits existierende Lösungen gibt.

    P.S.: Um einen kleinen Einblick zu geben, wie eine reine Live-Coding Performance aussehen kann, könnt ihr bei Bedarf gerne hier vorbei schauen:
     
    gefällt mir nicht mehr 1 Person(en) gefällt das
  2. Jenzz

    Jenzz Registrierter Benutzer

    Im Board seit:
    08.08.07
    Zuletzt hier:
    30.10.20
    Beiträge:
    721
    Ort:
    Ahnsen
    Kekse:
    3.257
    Erstellt: 30.09.20   #2
    Moin .-)

    Ich glaube, dass Du mit diesem Thema bei www.Sequencer.de besser aufgehoben bist, denn es ist ja ein ziemlich 'technik-lastig' und recht speziell.. Muskier-Board ist mehr 'Rock'n Roll' .. ;-) ... Dort gibt es auf jeden Fall sicher mehr Leute, die mit dem Begriff 'Live-coding' überhaupt was anfangen können als hier.

    Jenzz
     
  3. FerdinandK

    FerdinandK Registrierter Benutzer

    Im Board seit:
    02.11.18
    Beiträge:
    547
    Kekse:
    4.314
    Erstellt: 30.09.20   #3
    Das was du machst ist wunderbar, aber aus meiner Sicht liegt der Vorteil des Programmierens im Programmieren selbst nicht in den Möglichkeiten.

    Alle 5 Punkte die du aufzählst sind mit diversen Geräten (oder Kombinationen davon) ebenfalls möglich, das sind ja letztendlich auch nur Computer, die programmiert wurden und mit einem mechanischen UI ausgestattet sind.
    Würdest du ein graphisches UI über deine Software stülpen müssen würde es mit den Funktionen auch dürftiger werden, weil dadurch die Möglichkeiten schwinden aber die Breite der Nutzer zunimmt.

    Die Konkurrent ist ziemlich gut unterwegs, ich vermute die Vorteile des Programmierens liegen dort wo oder was sich nicht einfach in einem UI abbilden lässt.

    Ich bin selber Programmierer aber live würde ich immer Knöpfe, Tasten, Dreher, Drücker und Schalter bevorzugen, weil die einfacher zu trainieren sind. Beim Loopen bring ich selber schon einiges zusammen, aber live ist nochmal eine ganz andere Geschichte, live (also im vollen Haus) vernünftig ein paar Zeilen zu schreiben zu coden (ohne Syntax Error) ist schwer für mich vorstellbar, vor alles weil das Hirn 100% braucht um zu eruieren warum grad was nicht funktioniert obwohl es funktionieren sollte (Fehler suchen), live fehlen da wichtige 30-70% .

    Wenn man will ist eine Partitur nichts anderes als ein Programm-code, Bands die proben (oder ich selbst am Looper und Mikro) ist nichts anderes als programmieren. Will man hier die Vorteile des codens herausarbeiten wird es schon ein paar conditional jumps (if) oder ein paar komplexere Strukturen (Prozeduren, Objekte) brauchen. Fast alles andere ist bereits mit einer Partitur und geeigneten Instrumenten ( Geräten) möglich.

    Ein Vorteil des Codens ist noch, dass man eben ein Skriptum hat, d.h. es muss nicht immer alles neu wiederholt werden, sonder man kann gezielt einen Teil bearbeiten, bei der "Aufführung" kommt genau jene Version die kommen soll. Abläufe sind per Definition automatisiert, diese müssen nicht erst "geübt" werden.
     
    gefällt mir nicht mehr 1 Person(en) gefällt das
  4. Calmar

    Calmar Registrierter Benutzer

    Im Board seit:
    16.09.10
    Beiträge:
    344
    Ort:
    Schwarzwald
    Kekse:
    2.304
    Erstellt: 30.09.20   #4
    Hey Thomas,

    mit Interesse habe ich deinen Beitrag und deine Video-Performances aufgenommen und habe es genossen. Ich betreibe selbst Live-Looping und arbeite dabei mit zwei Systemen: (1) PC-basiert mit Ableton Live in Kombination mit Hardware-Controller (Push 2) und (2) Boomerang-III-Pedal mit Effekt-Board. Die Devise dabei: So komplex wie nötig und so reduziert wie möglich.

    Live-Looping bedeutet - streng definiert - zunächst "nur" Echtzeit-Looping. Üblicherweise wird aber der Performance-Aspekt mitgedacht. In dieser Hinsicht bin ich hinsichtlich des Verhältnisses zwischen "Live-Looping" und "Mehrwert durch Live-Coding" ambivalent.
    Nicht selten langweilt mich eine Performance, die zwar technisch vom Feinsten ist, aber wo dem Performer durch Versinken in Technik und Programmierung den Kontakt zum Publikum verliert. Das ist auch das, was ich stets versuche, zu vermeiden.

    An dieser Stelle stelle ich mir aber gerade vor: Wäre ich jetzt in einer Location, wo du die Performance aus dem letzten Video aufführen würdest, fände ich es im Vergleich "spannender" - vorausgesetzt, es hängt dort eine große Syntax-Leinwand. Das wäre dann die kryptische Loop-Geschichte, die ich live "mitlesen" kann. Das hat was. Auch, wer die Programmiersprache "nicht versteht", findet in der Syntax nachvollziehbare Schlüsselbegriffe. Es ist nochmals eine andere Teilhabe, wenn ich statt "Geschraube an der Oberfläche" das "Geschriebene an der Basis" sehen kann...
    Daneben gilt für mich auch genau das, was FerdinandK im Vor-Post aufführt.

    Das ist der Punkt für mich. Die Zuschreibung von Wertigkeiten im Verhältnis von "Limitierung" und "Möglichkeiten" ist abhängig von der Perspektive. Im Live-Kontext brauche ich die Reduktion von Komplexität, um Ressourcen frei zu machen. Limitierung erwünscht.
     
    gefällt mir nicht mehr 1 Person(en) gefällt das
  5. thgrund

    thgrund Threadersteller Registrierter Benutzer

    Im Board seit:
    29.09.20
    Zuletzt hier:
    30.10.20
    Beiträge:
    2
    Kekse:
    0
    Erstellt: 30.09.20   #5
    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!
     
    gefällt mir nicht mehr 2 Person(en) gefällt das
mapping