Par Grégoire Filliatreau & Valentin Moncler | M2 CMAS

Note d’intention

La proposition ici présentée s'inscrit dans le cadre de notre travail de création de Master 2. Il s'agit ici d'une performance live improvisé et interconnecté de musique électronique.

Avec le souhait de trouver une manière de créer au présent et d'explorer les situations émergentes qui peuvent résulter d'interaction et de situations où l'instinct, la réussite et l'erreur peuvent se côtoyer, nous explorons et programmons des systèmes de jeu s'apparentant à des instruments numériques. La première étape de cette recherche s’inscrit dans un questionnement sur les éléments préexistant au temps du concert et ceux qui vont se concevoir en temps réel.

Notre premier choix est de ne pas utiliser de matières sonores ou midi écrites avant la performance : elles doivent-être créer en live. Mais s'ajoute à cette première couche l'écriture logiciel : le développement des outils d'improvisation est aussi une forme de prédétermination. Par exemple le mapping correspond à une sélection des paramètres qui seront disponibles à l'instrumentiste pour faire ses choix sur le vif. Échapper à cette strate est déjà un exercice plus complexe. La première stratégie que nous explorons est celle d'un mapping relatif ou orientable, autrement dit avoir la possibilité d'utiliser un contrôleur pour différents paramètre au choix. Par exemple : dans le cas de l'utilisation d'un outil avec plusieurs instances comme un looper ou un sampler, avoir la possibilité, avec un seul contrôleur, de paramétrer individuellement chaque instance lorsqu'elle est sélectionnée, ou encore pouvoir adapter le mapping à l’outil utilisé. C'est là une première étape d'ouverture du mapping pour gagner en fluidité et laisser plus de marge de manœuvre aux musiciens.

La recherche d'un instrument jouable, d'une certaine corporalité et d'un fonctionnement autant adaptable qu'instinctif est une piste que nous avons choisis d'explorer. C'est en vue de répondre à ces besoins que nous avons intégré des capteurs à nos dispositifs respectifs afin de retrouver un certain rapport au corps - auquel on ne fait que peu souvent la part belle dans le cadre des performances live de musique électroniques - influent sur l'interprétation et la proposition dans les temps de jeu.

Nous nous sommes placé l'un face à l'autre dans l'optique de pouvoir accéder au regard de l'autre et de favoriser un dialogue dans le jeux musicale.

Liste du matériel utilisé

La jouabilité du système global repose sur une interconnexion des deux machines. Grégoire génère du son qui passe par les système de Valentin avant de lui être retourné. En somme, le trajet du signal se décompose comme suit :

Fonctionnement

Fonctionnement système Valentin

Fonctionnement général

Le système de Valentin consiste en une matrice permettant de router le signal vers différentes pistes d'effet. À l'heure actuelle, il reçoit une piste stéréo provenant de l'ordinateur de Grégoire. Cette piste peut alors être dirigée vers différents bus d'effets qui peuvent eux-même être routés vers d'autres bus d'effets. Il est donc possible d'appliquer des traitements sur des traitements ou de créer des boucles de feedback en envoyant une piste vers elle-même.

Par ailleurs, un clavier MIDI (Akai LPK25) permet de générer des sons depuis ce système. Celui-ci contrôle un synthétiseur générant une simple sinusoïde et peut être routé de la même manière que le son produit par Grégoire.

Gestion de traitements et effets

Les effets peuvent être appliqués au son émis ou le son émis aux effets.

On a par exemple des plugins de saturation qui peuvent colorer le son que l'on fait passer au travers, de même que les delays, tremolo, ou autre reverb.

D'autre part, il est possible d'appliquer l'enveloppe du son (en pratique surtout celui émis par Grégoire) à des boucles de feedback. Les boucles plus ou moins continues sont alors affectées par le son de Grégoire en en épousant la forme mais en gardant y mélangeant leurs propriétés spectrales. Pour le dire plus, on peut appliquer l'enveloppe du son de Grégoire au contenu fréquentiel du feedback.

Enfin, des plugins émulant des machines analogiques sont utilisés pour le bruit qu'ils dégagent et qu'il est possible de manipuler ainsi que pour la manière dont ils réagissent aux signaux très fort entraînant une saturation. Ce bruit est alors manipulable en le couplant à un input agissant comme un compresseur sur le bruit, ou traitable avec des effets appliqués à sa suite.

Chaîne d’effets 1

La première chaîne d’effets repose sur deux chaînes d’effets différentes organisées dans un rack d’effet. WAR, est la plus riche des deux. Elle comprend de nombreuses émulations de matériel analogique. Ces dernières réagissant au niveau d’input (plus le son entrant sera fort, plus la saturation s’en trouve affectée), le jeu sur le feedback et son volume est important ici pour créer des textures particulières. On a donc dans l’ordre un préampli (Radiator de Soundtoys), une émulation de machine à bande (Kramer Tape Stereo de Waves), une saturation analogique (Decapitator de Soundtoys), une distorsion (DevilLoc de Soundtoys), puis des effets de traitements plus spatiaux ou harmoniques avec un delay stéréo réglé en ping-pong (l’EchoFlex de Plug&Mix), un série de quatre resonators natifs d’Ableton qui permettent de générer des accords à partir d’un larsen ou de les appliquer au son de Grégoire, puis trois tremolo pour créer des rythmes plus ou moins complexes mais non manipulables sur le vif.

REVERB est une piste de reverb qui reçoit en input le son de la chaîne WAR. manipulable grâce au capteur de mouvement.

Chaîne d’effets 2

La seconde chaîne d'effets est encore en cours d'étude. Elle reposerait sur l'utilisation de phasers après un bit crusher. L'idée serait de pouvoir superposer ce son à un son moins traité afin de jouer sur l'effet de phase et créer des aspérités et des reliefs évolutifs, rapides ou brusques, dans le son mélangé.

Chaîne d’effets 3

Cette chaîne comprend un plugin de synthèse croisée. Ce dernier, en générant un larsen en amont (par exemple avec la première chaîne d’effet envoyée ensuite vers cette troisième chaîne) sur la même piste, me permet de sculpter le contenu spectral du signal de Grégoire en le mélangeant avec celui du larsen. Autrement dit, cela permet de sculpter la texture continue, lisse et plutôt longue du larsen avec l’enveloppe du son de Grégoire. En animant ce larsen, il est alors possible de jouer en même temps sur un même son, et ainsi, lorsque celui-ci est samplé, d’enregistrer un double geste instrumental.

Chaîne d’effets 4

La quatrième chaîne est souvent réglée pour générer un feedback. Son volume est géré par le volume général de la piste et peut-être traité par la suite avec un tremolo pour sculpter l’enveloppe du son et un autopan pour ajouter du mouvement dans la stéréo. Les paramètres de ces deux effets sont assignés à la première couche du MIDI Twister afin d’instrumentaliser leur utilisation et la rendre manipulable dynamiquement pendant la performance.

Contrôleurs utilisés & capteur

Les différents contrôleurs sont utilisés de manière complémentaire jusqu'à parfois ne former qu'un seul et même instrument.

 Le MIDI Twister est un contrôleur MIDI. Il est utilisé pour gérer le routing des pistes audio, MIDI et d'effets, l'activation des effets ou encore leur paramétrage. Les données qu'il émet sont envoyés aux paramètres choisis en utilisant les objets [live.path], [live.object] et [live.observer]. Ci-dessous un extrait du patch [vm_sends-ctl] qui permet de router les données en provenance du MIDI  Twister vers les paramètres désirés. Ce même principe est dupliqué autant que souhaité pour assigner les données des contrôleurs à des routings spécifiques.

L'objet [live.path] produit des identifiants uniques correspondants aux paramètres accessibles par l'API. On lui envoie des messages qui permettent de sélectionner les paramètres désirés.

Dans l'exemple ci-dessus, nous pouvons donc accéder, dans la session Ableton ouverte, au premier paramètre d'envoi (le 0 correspondant à la première instance des sends) de la piste spécifiée par un numéro entrant dans le message (on utilise en effet $1 pour pouvoir se donner la possibilité de reconfigurer le routing).

Les identifiants de ces paramètres sont ensuite envoyés dans les objets [live.observer] et [live.object] qui permettent respectivement de récupérer les valeurs de ces paramètres et d'agir dessus.

Le détecteur capacitif de courte portée est utilisé pour moduler les valeurs de différents paramètres d'effets (bruit de fond des plugins analogiques, distorsion, dry/wet, feedback ou temps du delay, reverb). Son utilisation dans Ableton Live est complétée par la combinaison de différents patchs et une autre interface.

D'une part, un patch Max4Live [Vm_SensorMatrix_viaLemur] permet de manipuler l'API d'Ableton Live et d'accéder aux paramètres du logiciel. Avec lui, il est possible de router dynamiquement les données envoyées par le capteur vers différents paramètres de différents effets situés sur différentes pistes. Son fonctionnement repose sur l'utilisation de [live.path], [live.object] et de [gate] pour définir le chemin qu'empruntent les donnés.

Pour choisir le routing, on utilise le logiciel Lemur sur un smartphone. Le téléphone envoie des données MIDI vers une piste MIDI "LEMUR" dans le set Ableton Live. Sur cette piste, le patch [Vm_LemurToSensor] interprète les données émises par le smartphone et les dirige vers la piste "CAPTEUR" via un système de [send] et de [receive] pour contrôler l'ouverture et la fermeture de six [gate] dans le patch [Vm_SensorMatrix_viaLemur].

L'interface Lemur se présente comme ci-dessus. Les boutons à gauche permettent d'enclencher les différents [gate] et de router le signal des capteurs à travers la session. Les données émises sont réceptionnées par la piste "LEMUR" et sont ensuite dispatchées grâce au patch [Vm_LemurToSensor] présenté ci-dessous.

Ce sont ces patches qui permettent d'orienter les données du capteur à travers tout le set en utilisant la combinaison de trois objets qui permettent de piloter l'API d'Ableton Live : [live.path], [live.observer] et [live.object].

Il y a donc plusieurs instances de ces trois objets qui permettent de parcourir la session pour diriger le flux de données vers des paramètres précis. Avec des [gate] il est alors possible de diriger les informations du capteur selon notre envie et d'enrichir l'utilisation du capteur.

Comme les capteurs envoient des données en permanence, l'utilisation de [gate] permet dans un premier temps de bloquer des états. Ensuite, la multiplicité de ces objets permet d'avoir différentes possibilités de routing qui sont utilisables individuellement ou cumulées. Cette possibilité de contrôle offerte par Max4Live a guidé le choix vers une restriction du nombre de capteur. En effet, il était plus intéressant dans une situation de prise de décisions rapides, de n'avoir qu'un seul générateur de données à gérer en ayant la possibilité de l'orienter dynamiquement.

Documents en téléchargement

• Patch M4L - vm_sends-ctl.amxd

• Patch M4L - Vm_LemurToSensor.amxd

• Patch M4L - Vm_SensorMatrix_viaLemur.amxd

• Session Ableton Live - test_traitements.als

Fonctionnement système Grégoire

Documents téléchargeables

• patch audio & instrument

  • grF-Sampler-groove_v1.amxd

  • grF-Track-multi-controle-test1.amxd

  • grF-audioSourceAutoDisarm.amxd

  • Audio Routing Example-grF1.amxd

• patch gestion

  • GrGgestionnaire2set6-RESEAU-2.amxd

  • grF-AudioMidiRec.amxd

  • abstractions

    • grF-r.maxpat

    • grF-forward.maxpat

    • grF-grooveduck2.maxpat

  • .js
    • scriptingName.js

• patch entrées midi

  • R8-map.amxd

  • grF-R16-bendin-send.amxd

  • lemur-tab-changer.amxd

  • TRAKTOR-input.amxd

  • Clavinova-midi.amxd

• Lemur

  • sample-selection-basique.jzml

• Ableton Live set

  • Groove-reseau-3.als

Fonctionnement général et simplifié

Le système de Grégoire est basé sur l'échantillonnage, et le réechantillonage via l'utilisation de sampler, des instruments - ici virtuels - permettant de manipuler des enregistrements sonores de différentes manières. Il fonctionne avec Ableton Live et Max4Live. Il est actuellement constitué d'une quinzaine de patch. Commençons par une description chronologique et simplifié de ce système.

La première piste est une piste audio stéréophonique recevant les Schoeps Mk4 depuis la MixPre-6 (servant ici de pré-amplificateur). Cette source sonore est dans un premier temps enregistré dans un looper qui est déclenché via un bouton au pied comme on peut le voir dans la vidéo de présentation à 2m05. Le premier enclenchement lance l'enregistrement de la boucle, et le deuxième (à 2min10) stop l'enregistrement et lance la boucle. Nous utilisons une fonction présente dans le looper de live qui permet de définir le tempo en fonction de la taille et du contenu de la boucle enregistrée.

Le contenu sonore de cette piste est ensuite enregistré manuellement (grâce aux fonction native du Push 2) dans un clip audio de la piste "Sampler-Rec". Une fois l'enregistrement de clip terminé, il est automatiquement envoyé dans le sampler présent dans la piste juxtaposé à la première piste. Le sampler est ensuite joué, et lorsque l'enregistrement d'une séquence midi est lancé sur cette piste (toujours avec une fonction native du Push 2), un clip audio de la piste "Sampler-Rec" est simultanément lancé (comme on peut le voir dans cette vidéo à 0min37). Lorsque l'enregistrement midi est terminé, le contenu du clip audio est automatiquement envoyé au sampler de la piste suivante. Cette opération se répète jusqu'au dernier sampler. Le processus fonctionne donc en une réutilisation constante de la matière accumulée. Cette structure est construite sur certains éléments clef.

Sampler Max4Live

La partie centrale du système est donc le sampler, développé sur Max4Live.

Le "grF-Sampler-groove" est stéréophonique et polyphonique. Comme son nom l'indique, il est basé sur l'objet [groove~]. C'est un instrument encore en construction comme en témoigne le mode édition présent plus bas. Il permet d'agir sur la vitesse de lecture, sur les point de départ et de fin de lecture, d'activer/désactiver le timestretch, ainsi que de choisir parmi les six modes de timestretch disponible pour l'objet [groove~]. Il est joué chromatiquement avec les pads du Push 2. Si le timestretch est actif, la hauteur des notes jouées n'influe pas sur la vitesse de lecture. À l'inverse, lorsqu'il est inactif, la vitesse de lecture est lié à la hauteur de la note midi reçu. Il y a pour le moment quatre instances de ce patch répartit dans quatre "tracks", nom donné aux pistes dans Ableton Live). Il à été construit en assemblant les patch d'exemple MaxMsp "sampling_with_adsr" et l'abstraction "grooveduck2".

Dans son état actuelle, ce sampler n'a rien de particulier. En réalité, sa principale spécificité réside dans son implémentation au sein de l'écosystème de patch constituant ce set : il est possible de remplir le buffer lié au [groove~] avec le contenu des clip audio qui sont enregistrés. Sa particularité réside dans la localisation de l'identité de ses composantes, notamment des receive et du buffer. Autrement dit ces deux éléments on une des nom construits en fonction de la piste audio dans laquelle le patch est situé : c'est donc une identité local relative à la piste.

Gestion de set : mapping & clip audio

Ce fonctionnement par piste est le point de pivot du fonctionnement de ce système. Ce choix s'est construit autour du fonctionnement du Push 2, qui fonctionne selon deux principaux modes : le mode Session qui permet de contrôler les clips et de sélectionner des piste que l'on peut jouer (si elle sont midi) à l'aide du mode Note. L'utilisation de ce dernier arme la piste sélectionnée. L'ensemble du set est géré grâce au patch "GrGestionnaire2set6". On peut le résumé en deux fonctions principale : la gestion des clip audio et le mapping relatif.

Un des problème de live réside justement dans ce dernier point. Deux  grandes stratégies s'offrent à l'utilisateur. La première : utiliser le midi learn qui permet d'assigner un paramètre d'abord en cliquant dessus puis en jouant en midi le contrôle que l'on veut associer. Cela implique plusieurs défauts :  ce mapping est fixé et ne peut pas être changer dynamiquement, il ne permet pas une grande flexibilité de manipulation des données et n'est pas réellement compatible avec l'utilisation de capteur envoyant des données constamment. La deuxième : avoir un patch midi au début de chaque piste midi qui récupère les données de tous les contrôleurs midi ou d'un seul au choix, sur un canal midi donné. Si on choisi de ne recevoir qu'un seul contrôleurs on peut vite se retrouver limité. Dans le cas ou on reçoit touts les contrôleurs, il est possible d'avoir des conflits entre les différents contrôleurs et si certains d'entre eux envoie leurs données sur différents cannaux midi, il est impossible de récuperer ces donées.

mapping relatif

Pour avoir un contrôle fin et flexible sur la gestion des entrée et sortie midi, le choix à été fait de segmenter ce processus. Chacune des entrées midi est reçu dans une piste séparée (cf. schémas précédent), avec un patch qui sert à envoyer chaque [ctlin], [notein], [bendin]... vers le patch de gestion "GrGestionnaire2set. Cet envoie est fait avec l'abstraction [grF-foward]. Elle prend en argument le nom qui sera donné au forward, nom qui sera modifié par 2nd input. Le nom créer sera le suivant : [nomDuForward]-[nombreInput2(0 par défaut)]. Cette abstraction est utilisé ici pour pouvoir choisir dans quel "config" les informations midi vont être envoyées: dans le patch "GrGestionnaire2set6", ces données sont reçu dans le patch [config1]. Ce patch est une manière de recevoir et d'organiser les données midi reçu. Ce système à été mis en place pour pouvoir alterner facilement entre différents type d'organisation (on peut voir ça comme des sorte de pages virtuelles pour l'ensemble des contrôleurs). Pour se faire, nous utilisons l'abstraction [grF-r], l'équivalent du [grF-foward] pour les receives. La cible de cette abstraction est défini par l'extraction du numéro de scripting name du patch [config1] grace au script "scriptingName.js" trouvé sur les forum de cycling. De cette manière, l'assignation d'une identité locale pour les [grF-r] se fait automatiquement lors de la copie d'une config.

Enfin, depuis le sous-patch [config1] sont organisés et envoyés les informations reçues des différents controleurs vers la piste actuellement sélectionnée.

gestion des clip audio

La réutilisation des clip audio dans Max4Live n'a pas été simple notamment du fait des espaces créés automatiquement par Ableton Live lors de l'enregistrement de fichiers audio dans le logiciel. La solution à été de référencer le dossier d'enregistrement "recorded" du set dans les file_preferencies de Max4Live. Par ailleurs, le patch "grF-AudioMidiRec" parcours tous les clip slot  de la piste Sampler-REC, et continue d'incrémenter jusqu'à ce qu'il trouve un clip slot vide. Ce même patch observe aussi le statut d'enregistrement de la session Ableton Live et enregistre des clip audio lorsque la piste selectionné enregistre elle-même des clip. Il envoie aussi le nom des clip audio dans le buffer de la piste situé juste après la piste selectionné. Dans le cas ou le paramètre "AUTO-SEND-TO-NEXT-BUFFER" est désactivé, ces données son envoyé dans un [coll] (dans le [GrGestionnaire2set6]).

Quelques précision sur les contrôleurs et capteurs utilisés

Lemur

L'utilisation de Lemur sur un smartphone à été d'une grande aide, surtout pour des éléments de gestion, le côté tactile sans retour haptique ne permettant pas forcément dans ce cas des résultats de jeux satisfaisants. La première difficulté ici à été de contrôler le changement d'une page à l'autre depuis Max4Live (et depuis un autre contrôleur, le Traktor F1). Pas manque de connaissances concernant le langage et le fonctionnement de Lemur, l'astuce à été de contrôler le changement de page à l'interieur de Lemur via des controleur en midi, et ensuite de contrôler ces dernier depuis Max4Live avec des [ctlout].

La seconde difficulté - qui n'a pas encore été résolue - est celle de l'échange bidirectionnel entre Lemur et Max4Live sans boucle de feedback. Enfin, Lemur est pour le moment utilisé uniquement en midi pour des question de simplicité, mais il faudra par la suite l'utiliser en OSC à l'aide d'un routeur wifi pour pouvoir lui envoyer des informations plus complexe comme des formes d'ondes.

Capteurs

capteur de souffle

Le capteur de souffle présente un particularité intéressante : son état sans utilisation sur situe à 64 (le milieu de l’échelle midi) normale. Lorsque l'on aspire on se retrouve entre 64 et 0, et lorsque que l'on "souffle", on se retrouve entre 64 et 127. Le choix à donc été fait de le mappé sur deux paramètres d'effet audio de live. Pour l'aspiration, il est placé sur un auto-filter réglé en mode low-pass : l'aspiration filtre le son, la valeur du capteur étant placé sur la fréquence de coupure du filtre. Pour le "souffle", un double mapping à été effectué : entre 64 et 127, l'amount (c'est-à-dire à quelle point le signale est affecté par l'effet) et la fréquence d'un Auto-pan, réglé en mode tremolo augmentent ensemble. Plus on souffle, plus le son va être modulé, et de plus en plus rapidement. Comme le reste des entrées midi, les données sont envoyé à la piste sélectionnée.

capteur type bouton

Le mappinp de ce capteur est un peu plus complexe dans son implémentatin dans Ableton Live. Il à été mappé sur un Looper d'Ableton Live. Malheureusement le bouton qui sert "Mutli-Purpose Transport Buttton" n'est pas accessible via l'API d'Ableton Live, probablement pour des raison de stabilité. Mais la volonté de garder un mapping flexible et relatif ne fait pas exeption ici, une autre stratégie au donc du être utilisé. Le "GrGestionnaire2set6" s'est vu attribué la sortie midi "Gestionnaire IAC (bus 1)", une sortie midi disponible nativement sous MacOS. Un [live.button] à ensuite été rélié à un [ctlout] "GrGestionnaire2set6" et à été mappé à une touche du clavier. Il à ensuite fallu faire midi learn classique en selectionnant le  "Mutli-Purpose Transport Buttton" et en appuyant sur la touche mappé au button créer plus tôt. Cette étape supplémentaire sert à ne pas déclanché ce bouton en midi créant par la même un conflit entre le midi IAC et le midi déclancheur du bouton. La dernière étape est de relier le [ctlout] qui a été mappé  au capteur type bouton pour contrôler ce paramètre.

Une erreur est apparu lors de l'utilisation du capteur bouton dans ce contexte. Le déclanchement ne se fait qu'apprêt le 2ème appuye. Des test comparatif on été effectué avec les midiin de la zoom R16 et d'autre controleurs, et le déclanchement se fait instantannément. La source de cette erreur n'a pas encore été trouvée.

Routing audio

 La dernière pièce de ce set concerne la question du routing audio. En effet pour enregistrer le contenue des piste dans des clip audio, la question d'un cheminement des sources audio s'est posé. Pour ce faire, le point de départ à été un des exemple des patch Audio Route (cycling 74) qui à été adapté pour l'usage souhaité. C'est par ailleurs aussi ce système qui permet en partie l'interconnexion sonores décrite plus bas. Nous avons précédemment fait une description simplifié, mais ce qui vient s'ajouter est l'intrication des son des set de Valentin et Grégoire. Cette interconnexion existe pour le moment selon deux modes (défini dans le patch "Audio Routing Exemple-grF-1" et contrôler via Lemur) : un mode ou seul le son de la piste sélectionnée est envoyé, et un autre ou le choix des pistes envoyé par à Valentin est choisi manuellement (toujours via Lemur). Ce système est la clef de voute de l'interaction qui se déroule au sein du groupe : les son qui proviennent du set de Grégoire sont constamment modifiés et traité par le set de Valentin (cf. description du fonctionnement collaboratif).

Synoptique complet

                                 Cet synoptique est accessible en meilleurs qualité ici

Fonctionnement collaboratif & idées d'améliorations

Le fonctionnement en live repose sur l'interconnexion de nos deux systèmes. Grégoire génère des sons. Ces derniers sont envoyés en audio dans la session de Valentin qui peut alors y appliquer différents traitements en routant le signal dans différentes pistes d'effets. Le son revient ensuite à Grégoire qui peut l'enregistrer pour créer un nouveau sample qu'il pourra ensuite jouer et manipuler (time stretch, hauteur, rythme, enveloppe, position de lecture, etc.).

Il s'agit donc d'enrichir mutuellement la matière au fur et à mesure de la performance. Les effets appliqués peuvent être statiques (simple traitement du son) puis être samplés, mais ils peuvent aussi être interprétés et créer du mouvement avant d'être fixés dans une boucle. Une amélioration que nous souhaiterions apporter consisterait simplement dans le fait pour Grégoire d'envoyer chacun de ses samplers à Valentin. Valentin pourrait alors choisir quelle boucle il choisit de traiter afin de faire évoluer cette matière répétitive par des traitements qui lui apportent de la variation.

Nous imaginons également incorporer des possibilités de traitement MIDI de la part de Valentin qui pourrait alors intervenir sur les séquences mises en boucles de Grégoire. Cela pourrait passer soit par des gestions de listes avec les objets [zl] par exemple ou par une interface graphique permettant de reconfigurer les séquences, en ajoutant ou en supprimant des éléments sur le vif, peut-être avec une autre interface Lemur qui récupérerait les donnés des séquences de Grégoire.

Aussi, au mapping relatif auquel nous avons fait référence dans la note d'intention pourrait s'ajouter un mapping dynamique. En effet, malgré son aspect relatif, le mapping tel que nous l'utilisons reste fixé à l'avance. Pourquoi pas envisager un outil permettant l'assignation de paramètre à des contrôleurs en temps réel, insérant ainsi une partie de la conception instrumentale dans le temps réel. Cet outil se verrait très bien augmenter d'un créateur de preset en temps réel. Il serait donc possible pour nous de choisir en live les paramètre que l'on souhaite utiliser, et ensuite de capturer des états de cet ensemble de paramètres pour pouvoir enfin jouer entre l'enchainement de ces états. Le dernier outils que nous venons de décrire est actuellement en développement dans max4live sous le nom de "droppeur".

Vidéo de la présentation

Démonstration improvisée filmée par Baptiste Laporte le jeudi 16 décembre 2021 dans les locaux d'Interface Z.

Ici, nous commençons par un enregistrement de bruit d'élastique. Une première phase d'exploration de l'objet au contact des micros et des effets laisse ensuite place à une première mise en boucle. Celle-ci devient alors le matériau avec lequel Grégoire et Valentin peuvent jouer durant la performance.

Autres improvisations

Quelques vidéos documentant l'évolution du projet dans une démarche de recherche et création au fil des improvisations et améliorations des systèmes.