Peux-tu te présenter ? Quel est ton parcours, as-tu une formation scientifique, notamment dans le domaine des langages informatiques ? Qu’est-ce qui t’a conduit vers la pratique du live coding ?
Je suis autodidacte. J’ai appris un peu de C, un peu de Java, un peu Python et plus récemment Ruby. Intéressé par l’informatique et la musique depuis longtemps, je suis tombé sur le live coding autour de 2004 ou 2005, mais à l’époque la discipline me paraissait hostile et mes connaissances en programmation trop limitées pour tenter l’expérience.
Vers 2007, j’ai commencé à faire mes premiers pas dans les langages en temps réel, du type Pure Data ou vvvv. J’ai pu faire mes premières installations interactives et, peu de temps après, mes premiers sets en vjing avec une interface primitive mais à peu près fonctionnelle. En 2010, je suis passé au Make Art Festival de Poitiers où j’ai pu découvrir le livre FLOSS + ART, avec des passages sur le live coding ainsi que des performances live. C’est également à cette occasion que j’ai pu découvrir la distribution GNU-Linux Pure-dyne qui intégrait une flopée d’outils très intéressants dont Fluxus, un environnement de live coding appliqué au visuel, sur lequel j’ai passé un peu de temps. Je me suis alors sensibilisé plus fortement au logiciel libre.
En 2011, dans le cadre de l’organisation Rencontres Mondiales du Logiciel Libre, nous avons invité trois live codeurs à venir jouer devant un parterre de libristes : il s’agissait de MCLD (Dan Stowell, live coding + beatboxing, SuperCollider ), Marije Baalman (live coding, SuperCollider ) et Michel Pasin (impromptu). C’est à cette époque que j’ai fait mes premiers pas sérieux dans le vjing et ce ne sera que quelques années plus tard que je reviendrai au live coding, mais ça restera tout le temps dans un coin de ma tête.
Vers 2015, je me suis replongé dans le live coding, via SuperCollider et surtout lors du Node 15 à Frankfurt, où j’ai pu écouter la présentation de Sam Aaron sur Sonic Pi. A la fois simple et puissant, l’outil est conçu pour être utilisé par un enfant de 10 ans. C’était une révélation. Accessible et versatile, open-source et gratuit. Pourtant le logiciel reste puissant et si certains compromis ont été faits en matière de flexibilité, le fait que le moteur de son soit en SuperCollider et que le code soit proche du Ruby permet d’aller très loin dans l’utilisation.
Le live coding c’est un peu ce que j’ai cherché depuis longtemps : faire de la musique numérique au moins partiellement improvisée sans s’encombrer d’interfaces lourdes et contraignantes, sans passer par des logiciels propriétaires fermés et coûteux. C’est également la possibilité d’expérimenter à peu près n’importe quoi sans que le logiciel nous en empêche.
Comment se crée un “set”, une performance ? Reprends-tu une ou plusieurs séquences de codes d’une performance à l’autre, pour les faire évoluer comme un perpétuel work in progress, ou bien conserves-tu parfois une version “finie” du code d’une performance ?
C’est un processus qui a bien évolué depuis mes débuts. Lors de mes débuts et des premiers enregistrements, j’écrivais essentiellement en direct ; j’utilisais des forme de codes variées et c’était un assemblage hétéroclite de manières de coder. Pour le premier concert sous SuperCollider, j’avais essentiellement des pages et des pages de code pré-écrit avec des variables aux valeurs elles aussi pré-écrites que je pouvais exécuter à la volée. C’était chaotique et imprévisible, mais sans doute intéressant par moments.
Actuellement, c’est un mélange des deux. En ce qui concerne SuperCollider, je passe du temps à rechercher des sonorités en écrivant ou en modifiant des synthétiseurs, c’est une démarche plus “propre” parce que j’ai une idée de ce que je veux faire et de l’évolution globale du son sur un concert. Cette partie du travail est faite essentiellement à l’avance et elle est reprise d’une performance à l’autre, en évoluant constamment au fil de mes découvertes et nouvelles idées. Une trame se construit, j’améliore souvent le son de parties précédentes, j’en optimise les performances, je supprime, j’ajoute, il y a toujours des parties qui restent, jusqu’à ce que vraiment j’aie envie de passer à autre chose. Du coup, page blanche et on repart à 0. Je suis maintenant plus organisé sur ma manière d’archiver mes différentes versions mais au début je ne gardais rien et une grande partie de ce que j’ai pu faire il y a quelque temps est perdu, ce qui dans l’absolu n’est pas grave.
Avec Sonic Pi l’ambition est plutôt différente : commencer avec une page blanche. Mais ça nécessite beaucoup d’entraînement, idéalement en évitant le plus possible des boucles toute faites. Sonic Pi est de ce côté très puissant. En 4 lignes, je peux écrire une rythmique fonctionnelle, en moins d’une minute on peut y adjoindre un basse et une mélodie. C’est une des forces de ce logiciel que j’espère bientôt maîtriser suffisamment pour faire un long set sans aucune préparation, si ce n’est quelques samples supplémentaires à ceux fournis dans le logiciel.
Ton activité de formateur autour de Sonic Pi a-t-elle un impact dans ton travail de musicien ?
C’est difficile à dire. Ce qui est certain, c’est que ça me permet de rester en permanence impliqué dans le domaine. Les formations avec les enfants me donnent un regard neuf sur la discipline. Voir des enfants de 7 ou 8 ans prendre en main et s’approprier l’outil est assez incroyable, d’autant plus qu’ils ne sont pas limités ou contraints par des styles de musique ou des connaissances préalables. Ils font indifféremment de la noise, de la techno, sans le savoir, des mélodies plus ou moins jolies, et cliquent 50 fois sur play en même temps, très satisfaits du résultat.
Les formations adultes ont peut-être plus d’impact sur ma manière de coder. On a pu avoir quelques adultes ayant un très bon niveau en matière de programmation et leurs logiques me font parfois regarder mon code différemment. Il m’arrive de le changer en fonction de ces découvertes. Certains musiciens m’apprennent également beaucoup en logique musicale. Globalement, les ateliers et donc les interactions humaines autour du live coding sont riches en apprentissages.
Comment l’improvisation s’articule aux systèmes génératifs dans ta pratique ? Le génératif est-il une stratégie pour improviser sans avoir à créer note à note, en laissant le programme générer en soi ses propres variations ? Fais-tu une différence entre ta musique composée en situation de live et en situation de « studio » ?
Le génératif permet à la fois d’être « flemmard » en effet, en laissant le code générer des motifs sans écrire de longues listes de notes. Mais il rajoute également un paramètre de chaos dans le live. Parfois le génératif fait des choses auxquelles je ne m’attends pas forcément, exactement ce qui me permet de sortir de ma zone de confort et de m’adapter à ce qui se passe. Toutefois, comme dit précédemment, les bornes sont définies à l’avance et s’il y a une partie aléatoire, elle reste confinée dans un territoire sonore donné.
En studio, je teste les limites des paramètres, ce qui me donne, selon les sons / code, une idée vague ou précise des bornes supérieures et inférieures des paramètres. En live, je sais donc à peu près quelles sont mes options sans crasher le logiciel, bien que parfois je me risque à de nouveaux essais en live. Pour Sonic Pi, il n’y a finalement que peu de différence, j’essaie des choses en « studio », je retiens des techniques ou des sons et ça me sert de base pour un live.
Pour SuperCollider en revanche, le travail « studio » est primordial, il me permet de créer ma marge de manœuvre d’improvisation pour le live.
As-tu déjà pratiqué l’improvisation à plusieurs en live coding ? Si oui, qu’as-tu retiré de cette expérience ?
Oui, sous différentes formes. Le premier essai, nous étions deux sous SuperCollider, deux débutants pas encore à l’aise avec le code. Nous avons essayé de nous synchroniser via le réseau mais aucune solution ne nous semblait pertinente ou techniquement accessible.
C’est finalement plus tard que j’ai trouvé des solutions de synchronisation sur des githubs ou forums. Nous avons donc commencé par jouer à deux sans synchronisation avec une division du son basée sur l’utilisation de plages de fréquences. Mon collègue était plutôt sur des arpèges de pianos aiguës, moi sur des basses et autres éléments rythmiques.
Nous avons ensuite essayé pendant une petite période le live coding à 4, tous les 4 sous Sonic Pi, c’était le “String Quartet”. Nous montrions également chacun notre code sur des TV cathodiques. L’expérience était en soi intéressante, mais le problème de la synchronisation demeurait toujours. Nous avons fait ça au moment où la version 3.0 de Sonic Pi n’était pas encore sortie avec ses nouvelles options de synchronisation via OSC ou en MIDI. Le principe, c’était essentiellement que chacun jouait sa partie à tour de rôle, les autres faisant peu de choses à ce moment si ce n’est un léger accompagnement ou des interventions ponctuelles. Au final, cette forme était intéressante en tant que conclusion de sessions d’ateliers que nous avions organisés dans un bar, des apéros-codes, mais finalement peu féconde à long terme. Même sans synchronisation, on peut arriver à des choses intéressantes si on arrive correctement à s’écouter.
Je continue actuellement le live coding à deux avec mon ami et collègue Callede Denis pour la partie Sonic Pi. On se passe essentiellement la main, chacun étant tour à tour leader puis accompagnant. Cela fonctionne plutôt bien mais je pense que la forme va évoluer fortement après les nouvelles options offertes par la version 3.0.
Désormais je joue surtout en duo avec mon acolyte Coloscope qui joue sur un synthé fait maison (sur raspberry Pi + Pi Sound développé sous Pure Data). L’improvisation est bien plus aisée étant donné qu’il me laisse essentiellement faire les choix rythmiques et de structure. Lui me suit, souvent avec brio, car il m’arrive de faire des changements rapides sans prévenir !
Quelles techniques génératives utilises-tu le plus volontiers dans Sonic Pi ou d’une manière générale en situation de live-coding (logiques conditionnelles, stochastique… ?).
Le génératif m’a toujours intéressé que ce soit pour le live coding ou pour des visuels. J’utilise souvent des logiques conditionnelles et de l’aléatoire pondéré mais également des L-Systems, des automates cellulaires. Il m’est arrivé d’utiliser d’autres éléments amusants comme une base de données pour générer une mélodie, par exemple les donnée en open-data des horaires d’entrées et sorties de vélo de location, pour les convertir en signaux midis. C’est une des grandes forces des musiques codées, d’écrire des motifs complexes, générés, aléatoires avec des règles précises, alors autant s’en servir.
En ce qui concerne les automates cellulaires, j’en ai utilisé quelquefois sous des formes simples dans l’environnement SuperCollider. L’intérêt est d’avoir un outil qui se comporte de manière prévisible tout en ajoutant une quantité d’entropie contrôlable. Pour l’instant, j’utilise un système assez simpliste : en fonction de la position d’une case activée, elle renvoie une valeur de note midi et/ou peut déclencher une action dans certaines conditions (proximité du bord de la grille par exemple). Il y a une librairie très poussée développée par Andrés Pérez que j’aimerais explorer prochainement afin d’approfondir le sujet.
(Illustration sonore de l’utilisation des automates cellulaires, avec l’autorisation de SVDK)
J’ai utilisé régulièrement les L-Systems dans mon travail visuel et à quelques rares occasions dans de la génération de patterns sonores. Dans un premier temps, on énonce les règles (variables, axiomes et règles) puis on associe à chaque variable une valeur pour un son particulier. On réitère pour différents sons. Par exemple, on peut associer une note midi différente à chaque variable ou encore le fait de déclencher ou non une percussion en fonction de la variable (amplitude de 0 ou 1 par exemple associé à une variable). En rajoutant un peu d’aléatoire dans le système, on parvient à une structure générative qui peut déclencher ou interrompre un instrument, changer d’octave progressivement tout en évitant d’avoir des structures trop prévisibles.
(Illustration sonore de l’utilisation des L-Systems, avec l’autorisation de SVDK)
Est-ce important pour toi que le public comprenne à l’écoute les processus génératifs sous-jacents ?
Je pense que je suis plus proche du point de vue de Alex McLean que j’avais pu découvrir dans FLOSS+ART : ce qui est important, c’est de montrer qu’il y a un lien entre le code et la musique, que notre processus peut être transparent, mais pas forcément de manière explicite et claire.
Pour l’aspect “pédagogique”, j’ai un peu essayé quelques reprises, ou encore écrire des commentaires pendant que je code, soit pour parler au public soit pour lui expliquer ce que je suis en train de faire. C’est quelque chose que je ferais plus volontiers dans Sonic Pi qui s’y prête bien, surtout si le concert a lieu après un atelier par exemple.
C’est une des problématiques que je me pose également sur mon travail visuel. J’ai essayé à différentes reprises d’impliquer le public via capteurs ou camera, les réactions sont souvent intéressantes et ce jeu en temps réel pendant un concert peut être grisant, mais pas adapté à tous les contextes.
Pour SuperCollider, ça m’intéresse moins, on peut le montrer mais ce qui m’importe surtout c’est de faire de la musique, que l’outil disparaisse derrière et là aussi, souvent les personnes présentes sont bien informées qu’il s’agit de live coding.
En outre, comme je m’occupe également des faire des visuels, je n’ai pas encore réfléchi à une façon simple, propre et peu coûteuse en performance pour éventuellement faire une superposition du code et les visuels. J’avoue que, plus j’y réfléchis, moins l’aspect code projeté m’intéresse, bien que ce soit effectivement une tradition du live coding.
Il m’est arrivé de superposer deux vidéoprojecteurs avec le code informatique, afin que le code soit certes montré, mais sans obliger les spectateurs à s’y plonger avec attention.
Les langages et logiciels induisent souvent des formes, des esthétiques qui leur sont propres. Comment ton expérience des différents langages (SuperCollider, Sonic Pi, TidalCycles…) dans un contexte de live coding ont-ils influencé ta musique ? Notes-tu une différence entre la musique que tu imagines avec des langages comme Sonic Pi et celle que tu réalisais avant de découvrir ces outils, par exemple dans un séquenceur ?
Oui, j’ai pu essayer un certain nombre de langages. Avant de me mettre sérieusement à SuperCollider et Sonic Pi, j’en ai essayé toute une flopée. Je ne connais pas bien chacun des autres langages, mais certains ont des logiques très intéressantes.
Mon expérience de SuperCollider m’a beaucoup aidé sur Sonic Pi, par exemple dans le domaine de la synthèse additive ou soustractive. Les deux logiciels partagent des logiques communes.
Les langages de live coding sont puissants dans la gestion de l’aléatoire et des règles conditionnelles avancées, choses que l’on trouvera plus difficilement dans un séquenceur classique. Par ailleurs, je n’ai jamais passé beaucoup de temps sur des séquenceurs avant de live coder, j’avais plus tendance à aller vers de la noise, via par exemple du no-input, ou du génératif via des feedbacks vidéo/sons.
Tes performances en live-coding ont-elles aussi une dimension visuelle ? Comment celle-ci s’articule-t-elle à ton travail sonore ?
Les deux sont intimement liés. Mon expérience scénique fut plutôt dédiée au visuel dans un premier temps. J’ai travaillé en tant que vj pendant plusieurs années. Avec certains projets, nous avons fait des interactions fortes entre visuels et sons, parfois même sous forme d’une influence inverse, à savoir que le signal vidéo créait le signal audio (projet 8KHZ).
Pendant que je fais du live coding, je n’ai pas la possibilité d’accorder autant de temps à mes visuels que pendant mon travail de vjing. Du coup, c’est essentiellement du contenu génératif ou de l’audioréactif.
Je commence à développer une solution pour envoyer des instructions en OSC afin de piloter les visuels. Cela m’évite d’utiliser à la fois un ordinateur pour live coder et une interface midi pour les visuels.
J’utilise un grand nombre de techniques différentes, parfois en live, comme du contenu généré par des réseaux de neurones, des Kinects, des signaux analogiques, des images d’archives, du génératif à base de géométrie… Pour moi, c’est un jeu d’essayer constamment de nouvelles choses, de voir comment elles peuvent s’intégrer dans un live. Mon interface pour les visuels est conçue de façon à pouvoir improviser en permanence de manière très flexible, avec des bonnes et des mauvaises surprises. J’ai toujours considéré mon travail visuel (du moins en live) comme étant très proche de l’improvisation musicale sur un instrument. Il y a des phrases, des motifs, des rythmes, c’est improvisé parfois rapidement au rythme de chaque beat, parfois lentement comme un pad en arrière-plan.
Actuellement, les visuels sur le live coding s’articulent surtout en terme de « scènes » audioréactives, c’est-à-dire le passage d’un environnement visuel à un autre pendant le set avec des variations dans chaque scène, soit automatiques soit manuelles quand j’ai un peu plus de temps à y consacrer.
Entre le son et l’image je n’ai pas vraiment une seconde de pause pendant le set. Il n’y a pas longtemps, je me suis rendu compte pendant un set que je n’avais pas une seule fois eu le temps de regarder le public. Je pense que les choses seront plus simples avec l’habitude et avec quelques améliorations de mon pilotage des visuels.
Peux-tu parler de tes projets impliquant le live coding ou d’autres pratiques liées à l’art génératif ? As-tu des défis dans ce domaine ?
Dans l’immédiat nous préparons, avec le duo SVDK & COLOSCOPE, un cinquième album qui devrait être assez différent des autres. Nous préparons également un nouveau « set », où j’accorde une attention particulière au développement des visuels. J’aimerais prochainement connecter le tout à des contrôleurs DMX. Nous avons également prévu des collaborations avec d’autres artistes.
En ce qui concerne le génératif, il y a une série de vidéos de prévue. J’aimerais bien préparer un github (ou équivalent) avec tout mon code nettoyé, mais ça va prendre un peu de temps.
Nous continuons à développer nos activités de formation en live coding et d’organiser des événements autour de cette discipline. Je prépare également une installation interactive autour de l’open-data et de la musique générative, combinant toutes mes nouvelles connaissances telles que le parsage de données, data mining, visuels et sons générés en temps réel…
(Propos recueillis en janvier 2018)