SIMONE : un instrument distribué pour l’improvisation musicaleSIMONE: a distributed instrument for musical improvisation

Aliénor Golvet, Benjamin Matuszewski et Frédéric Bevilacqua

Résumé | Index | Plan | Texte | Notes | Citation | Auteur | Version PDF | a | A

Résumés   

Index   

Index de mots-clés : improvisation musicale, instrument distribué, mosaicing audio, web audio, nano-ordinateurs.
Index by keyword : musical improvisation, distributed instrument, audio mosaicking, web audio, nano computers.

Plan   

Introduction

1L’essor de la Web Audio API1 depuis 2011 a accéléré l'utilisation de systèmes musicaux basés sur des navigateurs Web et l’émergence de nouvelles expériences musicales collectives. Ces travaux explorent notamment les diverses possibilités offertes par les réseaux : performances musicales à distance, participation du public, intégration de capteurs, systèmes de réalité virtuelle (Turchet et al. 2018).

2Cependant, les questions de la conception instrumentale de système musicaux en réseau et de l’apprentissage et de l’appropriation collective des tels systèmes par les musiciens restent largement inexplorées. En effet, si la communauté NIME (New Interfaces for Musical Expression) s’est depuis plusieurs années intéressée aux questions de conception et d’appropriation d’instruments (Magnusson 2009 ; Zappi et McPherson 2014), la majorité des travaux dans ce domaine concerne des pratiques où les musiciens utilisent leurs propres interfaces sans forcément être connectés par un réseau.

3Dans ce papier, nous présentons Simone, un système Web pour l'improvisation collective en réseau basé sur des entrées audio (microphone). Simone est conçu comme instrument distribué proposant une interaction collective qui se décline en plusieurs variations dont chacune correspond à une topologie d'interaction particulière. Dans chaque variation, les musiciens occupent des rôles variés et échangent différents types d'information.

4La conception de Simone a été influencée par des exemples antérieurs de systèmes de performance musicale en réseau et par une esthétique musicale proche du collage sonore, de l’improvisation bruitiste et de la musique concrète. Une des originalités de Simone est d’être conçu pour être utilisé via un ensemble hétérogène d'appareils (ordinateurs, tablette, téléphones portables, nano-ordinateur type Raspberry Pi) permettant ainsi de le déployer facilement dans différents types d'espace grâce à des moyens techniques légers et portables.

5Nous commençons par présenter divers travaux précédents de performances et d’installations musicales en réseau, en particulier des systèmes qui, comme le nôtre, utilisent des microphones. Dans une deuxième partie, consacrée à Simone, nous introduisons les différents objectifs ayant guidé ce travail avant de présenter les éléments de design et d’implémentation, ainsi que les différentes variations du système. Nous présentons ensuite deux exemples d’utilisation de Simone. Dans un premier temps nous présentons des éléments issus d’un atelier réalisé à l’Ircam durant lequel nous avons demandé à quatre participants d’improviser collectivement avec les différents systèmes. Enfin, nous présentons un travail au plus long cours avec un musicien improvisateur qui a pu prendre en main Simone pendant plusieurs mois.

6Les 4 premières parties de cet article ont été présentées au cours des Journées d’Informatique Musicale 2023. Cet article constitue une version révisée et étendue de cette soumission, avec notamment l’ajout de la dernière partie.

7Une version simplifiée de Simone a également fait l’objet d’une présentation publique lors des portes ouvertes de l’Ircam en janvier 2023.

1. Exemples historiques et influences

1.1. Instruments musicaux en réseau

8Probablement parce qu’une analogie immédiate peut être opérée entre un réseau informatique et un ensemble de musiciens – dont les nœuds seraient les musiciens et les communications se feraient par les médiums acoustique et/ou visuel – les possibilités du réseau ont rapidement été explorées par les artistes dans diverses modalités (Collins 2010).

9Les performances de musique en réseau ont ainsi été décrites comme explorant de nouveaux moyens de distribuer les ressources cognitives et l’information au sein d’un groupe, la modification des interactions et du jeu individuel en fonction de l’agentivité des autres musiciens et du réseau lui-même, la disparition de la séparation entre musiciens et public, ou encore la mise en œuvre de processus de création collective plutôt que la production d’une œuvre fixe (Kim-Boyle 2009).

10L’exemple précurseur et paradigmatique de cet usage du réseau est le groupe The Hub, fondé en 1986 des suites de la League of Automatic Music Composers (Gresham-Lancaster 2017 ; Stone 2021). Bien que chaque musicien du groupe contrôlait un système de sa propre confection, leurs performances étaient fondées sur l’échange d’informations via un réseau local selon un protocole défini pour chaque pièce. Ainsi par exemple dans la pièce Waxlips (1991), chaque musicien reçoit des notes individuelles de la part des autres membres du groupe via le réseau. Ce musicien doit d’abord jouer la note reçue puis lui appliquer une transformation arbitraire avant de l’envoyer à un autre membre du groupe2.

11Les expérimentations de The Hub serviront de modèle à de nombreux ensembles de musique tels que les laptop orchestra dans lesquels l’infrastructure en réseau prend une importance esthétique plus ou moins importante (Collins 2010 ; Trueman et al. 2006 ; Wang, Essl, et Penttinen 2008).

12En suivant la distinction faite par Rohrhuber (Rohrhuber 2007) nous pouvons distinguer deux types de structures de partage d’information au sein d’un système de musique en réseau : soit l’accès simultané à un état commun et partagé, soit le partage et la circulation d’objets et d'informations au sein du réseau. 

13Dans la première catégorie nous pouvons par exemple évoquer l’Emupo (Canonne, Monteiro, et Rühl 2011), une interface pour l’improvisation musicale collective développée en Max/MSP. Destinée à être jouée de manière autonome ou pour compléter le jeu d’instrumentistes, l’Emupo peut être contrôlé par plusieurs utilisateurs à la fois, chacun prenant la main sur différents paramètres de production d’un même son donnant alors lieu à une interaction “intra-instrumentale”. 

14Dans la seconde catégorie, l’ensemble powerbooks unplugged (Rohrhuber et al. 2007) propose des performances de groupe basées sur l’accès à un espace de partage d’informations où circulent extraits de code, commentaires des musiciens et messages provoquant la production d'événements sonores sur les hauts parleurs de n’importe quel ordinateur du réseau. L’exemple de powerbooks unplugged met aussi en évidence un autre des avantages offerts par l’aspect décentralisé de la production sonore : la possibilité de choisir librement la manière dont le son est spatialisé ainsi que le nombre de musiciens participants.

1.2. Utilisation du microphone

15Divers travaux d’installations artistiques et d’instruments en réseau utilisant le microphone ont servi d’inspiration pour ce travail. Bien que l’usage de microphones et de la voix ait été exploré de nombreuses manières dans la communauté NIME (on en trouvera une recension et une taxonomie dans (Kleinberger et al. 2022)) nous nous concentrons dans cette section uniquement sur les systèmes en réseau.

16Voice Networks (2003) (Weinberg 2005) de Gil Weinberg est une installation musicale collaborative proposant à des utilisateurs non-experts de participer à une expérience de création musicale collective et de mettre en évidence l’aspect social du jeu en groupe. 

17L’installation est composée de quatre postes disposés en carré, face à face, autour d’un écran. Chaque poste est composé d’un microphone, d’une surface tactile et de haut-parleurs. Les participants peuvent enregistrer des boucles sonores avec leur micro et leur appliquer des transformations sonores à l’aide de la surface tactile qui contrôle à un patch Max/MSP. Le réseau est utilisé pour échanger les boucles sonores ainsi créées entre les participants.

18Talking Drum (1995) (Brown 1999) de Chris Brown est une installation interactive composée d’un ensemble de “stations” (composées d’un microphone, de haut-parleurs et d’un ordinateur) disposées librement dans un même espace. Chaque ordinateur génère un rythme à partir d’un algorithme qui analyse ce qui est capté par le microphone. Bien que les différentes stations n’échangent pas d’informations, elles sont toutes synchronisées sur une même horloge. 

19L’installation Talking Drum crée ainsi une expérience d’improvisation entre des duos humain/machine au sein d’un espace acoustique partagé entre les musiciens et le public. 

20Auracle (2004) (Freeman et al. 2005) conçu par Max Neuhaus est un synthétiseur collaboratif accessible sur internet3 Le système analyse la voix captée par le microphone de chaque utilisateurs et en extrait plusieurs types de données de différents niveaux (descripteurs audios : RMS, f₀, classifications de “gestes” vocaux par analyse en composantes principales) pour contrôler un synthétiseur. Auracle est conçu comme un système qui répond à l’activité des utilisateurs et cherche à encourager une communication et un dialogue non verbal à travers une expérience musicale accessible via une interface destinée à un public non expert.

2. Simone

21Inspirés par les travaux mentionnés ci-dessus, nous avons donc développé un instrument distribué pour l’improvisation collective, proposant un ensemble de variations autour d’un scénario d’interaction.

22Notre objectif principal est de concevoir un système de création musicale collective qui favorise l’improvisation, l’utilisation de la voix dans le processus de synthèse sonore, et s’appuie sur l’échange d’information par le réseau. Le système est conçu comme un terrain d’expérimentation de divers paradigmes d'interaction collective et de leur appropriation par des musiciens. Il doit donc être accessible rapidement tout en possédant la profondeur et la flexibilité nécessaire pour qu’ils ne se sentent pas limités dans un contexte d’improvisation et de création. 

23Un objectif secondaire est de concevoir un dispositif qui nécessite un équipement matériel minimal et suffisamment flexible pour s’adapter à différentes situations et disponible sur plusieurs types d’appareils différents : ordinateurs, téléphones portables, tablettes, nano-ordinateurs. Simone peut ainsi être utilisé à la fois comme installation sonore collaborative, comme instrument de musique collectif ou encore comme instrument de musique distribué contrôlable par une seule personne avec la possibilité de disposer les sources sonores dans l’espace comme on l’entend.

2.1. Éléments de design

24Ce système d’improvisation collective est co-localisé et permet l’écoute mutuelle et les modalités d’interactions habituelles en improvisation (p. ex. gestes, regards).

25Outre l’utilisation d’interfaces classiques d’interaction humain-machine (souris, clavier, écran), qui offrent des contrôles sur la synthèse sonore, nous cherchons également à explorer l'utilisation de la voix dans la construction collective d’un espace sonore. 

26L’utilisation conjointe du réseau et du microphone permet d’imaginer de nouvelles relations entre la voix et le son produit par l’instrument distribué et diverses manières de reconfigurer ou de déstabiliser des dynamiques d’improvisation collectives.

27Du fait que la voix enregistrée est complètement altérée par une technique de mosaicing (décrite ci-dessous), Simone permet une expérience accessible aux utilisateurs qui pourraient être inhibés par le fait d’utiliser leur voix dans un contexte d’improvisation collective.

28En effet, l’expérience de Voice Networks nous montre que “bien que la voix soit probablement le moyen de communication le plus intuitif et répandu dans la vie de tous les jours, certains participants étaient inhibés par le fait de l’utiliser dans le cadre d’une installation publique par pudeur ou tout simplement à cause du trac”4 (Weinberg 2005).

29Contrairement à d’autres gestes instrumentaux, l’usage de la voix engage un certain nombre de caractéristiques personnelles (âge, maîtrise du chant, santé physique, sexe, accent, etc.) qu’il peut être gênant de dévoiler.

2.2. Implémentation

Principes généraux

30Simone est décliné en plusieurs variations qui diffèrent quant à leurs interfaces et quant aux topologies d’interactions mises en œuvre, mais qui partagent néanmoins un ensemble de caractéristiques communes : 

• Le microphone est utilisé comme moyen d’enregistrement afin de commander la synthèse sonore.

• La synthèse sonore est basée sur le principe du mosaicing audio (Janer et de Boer 2008 ; Zils et Pachet 2001). Il s’agit d’une technique de synthèse dans laquelle un son appelé son modèle est découpé en segments et analysé. Chaque segment est ensuite associé à un segment qui lui est le plus proche dans un son dit générateur (en fonction d’une distance calculée sur la base de descripteurs audio pré-définis), le résultat final étant la concaténation des segments issus du son générateur. Ainsi, le son synthétisé partage à la fois la structure et l’évolution temporelle du son modèle et le timbre du son générateur.

• Le système utilise un réseau local pour partager des informations entre les agents (c'est-à-dire utilisateurs et terminaux). Les informations transmises (horloge synchronisée, fichiers audio, données d’analyse) dépendant de la variation considérée (cf. Figure 1).

Figure 1. Diagrammes des échanges d’informations dans les trois variations présentées. Chaque cercle représente un client connecté au serveur.

Principes généraux

31L’application est entièrement développée avec le framework soundworks (Matuszewski 2020) basé sur les technologies Web, et est donc entièrement accessible depuis un navigateur Web. 

32La synthèse sonore est réalisée grâce à un système d’analyse/synthèse par mosaicing développé avec l’API WebAudio. Le fichier son modèle enregistré est analysé grain par grain en temps réel. Pour chaque grain, on calcule un vecteur de MFCC (Mel Frequency Cepstral Coefficients), et on cherche ensuite dans le son générateur le grain qui a les MFCC les plus semblables via une recherche dans un arbre à n dimensions.

33Nous avons choisi d’utiliser des MFCC à douze bandes de fréquences comme descripteurs audio car ceux-ci sont particulièrement adaptés à l’analyse et la représentation de la voix. Il s’agit en outre d’un descripteur de dimension suffisamment haute pour encoder plusieurs dimensions perceptives des sons, tout en étant suffisamment basse pour pouvoir trouver rapidement le grain le plus semblable à un autre.

34Par ailleurs l’énergie RMS (Root Mean Square) de chaque grain est calculée et est utilisée pour contrôler un gain lors de la resynthèse du son. Ainsi, un grain modèle de faible énergie donnera un son synthétisé de faible volume. Cet élément a été ajouté suite aux retours d’utilisateurs qui semblaient confus par le fréquent manque de lien entre la dynamique de volume du son modèle vu sur la forme d’onde affichée et le résultat sonore.

35Outre les clients accessibles depuis le navigateur Web d’un ordinateur ou d’un téléphone portable, nous avons également développé des clients exécutés dans des nano-ordinateurs de type Raspberry Pi 4 (combinant les avantages d’être portables et modulaires, et possédant une bonne puissance de calcul). Ce portage simple de l’application en dehors du navigateur a notamment été rendu possible grâce à l’implémentation en Rust de la Web Audio API dont les bindings vers Node.js (Rottier et Matuszewski 2022) ont permis de réutiliser de larges parties du code JavaScript original.

2.3. Variations

36Les principes généraux évoqués ci-dessus se déclinent selon différentes variations qui mettent en jeu différents moyens d’interactions et rôles exercés par les participants. Ces différents systèmes sont les suivants : 

Drum Machine

37Dans ce système, les utilisateurs enregistrent un son modèle avec le microphone et sélectionnent un son générateur parmi une banque de sons. Ils/elles peuvent ensuite sélectionner une section du son modèle à faire boucler. La durée de cette section est basée sur une grille rythmique commune à tous les participants qui partagent la même horloge. Le résultat peut être envisagé comme une sorte de boîte à rythmes distribuée.

Clone

38Dans ce système, il est demandé aux utilisateurs de commencer à enregistrer un son d’une durée approximative de 30 secondes. Ce son est ensuite envoyé à un autre participant pour lui servir de son générateur dans l’interface de jeu. Ainsi, chaque participant doit apprendre à jouer avec la voix ou le son d’une autre personne.

Solar System

39Contrairement aux précédents systèmes, les participants sont dans une configuration asymétrique. L’un d’entre eux occupe un rôle central et est appelé le Soleil. Le Soleil peut enregistrer un son modèle. Les données d’analyse de ce son sont ensuite envoyées simultanément aux autres participants appelés Satellites pour contrôler la synthèse sonore par mosaicing sur leur client. En outre, les Satellites peuvent choisir leur propre son générateur parmi une banque de son et faire varier divers paramètres de synthèse. Ainsi, le même son modèle enregistré par le Soleil est simultanément réinterprété par différents sons générateurs sur chaque Satellite. 

Solar System embarqué

40En plus des versions collectives que nous venons de présenter, nous avons mis au point une version solo embarquée du système Solar System. Celui-ci peut en effet se concevoir avec un unique agent humain prenant le rôle central de Soleil et des clients non-humains contrôlables à distance prenant le rôle de Satellites. 

41Le dispositif prend alors la forme suivante : un nombre variable de Raspberry Pi sur lesquelles est installée l’application sont connectés à un même réseau local (cf. Figure 2). L’interface de contrôle est accessible dans un navigateur web. Celle-ci, similaire à celle utilisée par l’utilisateur prenant le rôle de Soleil dans le système Solar System collectif, permet d’enregistrer un son modèle ainsi que pour chaque Satellite connecté de sélectionner le son générateur et de modifier les paramètres de synthèse.

42Chaque Raspberry Pi, connectée à une paire de hauts parleurs, reçoit les données d’analyse de la part du serveur et synthétise le son en temps réel. Le système devient alors un véritable instrument où l’on contrôle simultanément plusieurs sources sonores de timbres différents mais contrôlées par le même son modèle. En faisant varier les volumes et les paramètres individuels, en choisissant des boucles plus ou moins longues, il est possible de créer une grande variété d’espace sonores différents.

43La grande portabilité du matériel permet de disposer les sources sonores ainsi que d’en choisir le nombre de manière libre et adaptée à l’espace d’écoute. Il est à noter que le client est aussi accessible dans le navigateur internet ce qui permet à un membre du public de se connecter à l’application sur son téléphone et devenir ainsi lui-même une source sonore.

Figure 2. Le dispositif Solar System embarqué avec, à l’avant, quatre Raspberry Pi avec leurs enceintes et, à l’arrière, l’ordinateur avec l’interface de contrôle et un routeur wifi.

2.4. Interfaces

44L’interface a fait l’objet de plusieurs itérations au cours des tests et réflexions. Une attention particulière a été portée sur la complexité et le nombre d’éléments de l’interface avec lesquels il est possible d'interagir, afin de faciliter l’appropriation du système dans un temps restreint et de promouvoir l’agentivité des participants dans un contexte d’improvisation collective.

45Bien qu’elle diffère légèrement selon les différentes variations du système, l’interface comprend de manière générale les éléments suivants (cf. Figure 3) :

Figure 3. L’interface web du système Drum Machine. Les interfaces des autres systèmes sont sensiblement différentes et adaptées à chaque système.

46Une zone d’enregistrement qui permet de déclencher l’enregistrement avec le micro et de visualiser la forme d’onde du son enregistré, un bouton permet à l’utilisateur d’utiliser cet enregistrement comme son modèle (zone en haut à gauche dans la Figure 3.). En haut à droite dans la Figure 3., une zone avec un menu permet de choisir le son générateur ainsi que d’en visualiser la forme d’onde et de l’écouter. 

47La zone centrale montre la forme d’onde du son modèle actuellement utilisé. L'utilisateur peut sélectionner une section à boucler en utilisant la souris. La boucle sélectionnée peut être de longueur libre ou contrainte par une grille temporelle dans le cas du système Drum Machine. L’affichage de la forme d’onde du son modèle nous semble offrir un bon équilibre entre intuition du résultat sonore et invitation à l’exploration et au jeu. En effet, si la forme d’onde permet d’observer immédiatement le niveau sonore de chaque section du son modèle et donc du résultat synthétisé, les MFCC représentent également d’autres dimensions du son, ce qui ne permet pas d’anticiper précisément le résultat généré, poussant ainsi l’utilisateur à l’exploration.

48Enfin, dans la zone du bas de l’interface, différents sliders permettent de modifier différents paramètres de synthèse : volume, hauteur du son, période et durée des grains sonores. L’accès à ces quelques paramètres, très simples à percevoir et à contrôler, permet une plus grande variété de jeu instrumental et ouvre ainsi d’importantes possibilités de complémentarité et de dialogue entre les musiciens utilisateurs.

3. Utilisation en situation d’improvisation collective

49Une fois ces systèmes conçus et développés, nous avons mis en place un atelier d’improvisation avec quatre utilisateurs experts afin d’observer quels types d’interactions et de résultat sonore pouvaient émerger (cf. Figure 4). Les quatre participants de l’étude pilote étaient chercheurs en interaction humain-machine avec une expérience amateur ou professionnelle de la musique ou réalisateur en informatique musicale à l’Ircam, tous familiers de plusieurs logiciels et interfaces de création musicale numérique.

50Cet atelier a également été l’occasion de recueillir des avis sur l’ergonomie et la simplicité d’utilisation des interfaces développées, nourrissant ainsi leur évolution vers la version présentée plus haut. Des enregistrements audio des improvisations réalisées lors de cette session sont disponibles à cette adresse : https://archive.org/details/session3_2023025. 

Figure 4. Photographie de l’atelier réalisé avec quatre participants.

3.1 Déroulé de l’atelier

51L’atelier a commencé par une présentation générale et une rapide explication du principe du mosaicing audio. Ensuite, pour chacun des trois systèmes, il a été demandé aux participants d’improviser collectivement pendant huit à dix minutes. À la fin de chaque improvisation, une discussion a eu lieu afin de recueillir leurs impressions, de partager leurs expériences et de répondre à quelques questions préparées à l’avance sur la prise en main du système et des interfaces ainsi que sur les interactions qui ont eu lieu pendant l’improvisation. L’atelier s’est terminé par une discussion générale. Nous avons choisi de présenter les systèmes dans un ordre prédéterminé (Drum Machine, Clone, Solar System), plutôt qu’aléatoire, pour des raisons de continuité dans l’apprentissage des interfaces. 

52La banque de sons générateur disponible propose un mélange de sons instrumentaux, de sons électroniques et de sons concrets6. En outre, un certain nombre d’objets et de petits instruments étaient proposés aux participants qui ne souhaitaient pas forcément utiliser leur voix : un synthétiseur pour enfant, un kalimba, un accordéon pour enfant, une grenouille en bois et un petit sanglier en céramique renfermant une bille. 

3.2 Remarques générales

53Les participants ont tous globalement apprécié le dispositif et les moments d’improvisation. 

54Si la première partie de la première session peut donner l’impression d’un manque d’écoute mutuelle qui nous semble certainement dû à la période de découverte du système, les participants ont très vite proposé des stratégies pour construire l’espace sonore, en se partageant les différents registres de hauteurs, de volumes, de timbre et de rythme. Les dernières minutes de la session Clone nous semblent à ce titre particulièrement exemplaire : alors qu’un participant maintient un rythme plus ou moins constant avec un enregistrement de kalimba, un autre fournit une nappe sonore et les deux participants restants interviennent de façon plus minimale avec des bruits de petites percussions répétitifs.

55Les participants ont, dans l’ensemble, essayé de jouer avec les limites du système. Ils ont favorisé les boucles très courtes et ont joué avec les extrémités des sliders à leur disposition (durée des grains minimale pour donner un effet). Confrontés à la difficulté de négocier le silence et d’écouter les autres puisque le système de synthèse produit du son en continu, les participants ont rapidement appris à jouer avec le contrôle de volume.

56L’utilisation du microphone à disposition a été variée et son intérêt dans la construction sonore globale a été noté : « tu peux vraiment ajuster tout ce que tu fais rythmiquement avec les boucles et savoir que tu vas enregistrer du silence ». Cependant, les participants ont globalement moins utilisé le microphone qu’envisagé et ont préféré explorer les autres possibilités offertes par l’interface. Cela peut s’interpréter de trois façons différentes. 

57Premièrement, les possibilités sonores du système sont larges et l’utilisation de la voix n’est strictement nécessaire qu’au début de l’improvisation : « c’est tellement riche avec très peu d’input, ça n’encourage pas de refaire des trucs avec la voix ».

58Deuxièmement, les participants nous ont rapporté que l’utilisation du micro était rendue difficile par l’installation technique : le type de micro utilisé – un Shure SM58 sans pied – les obligeait à utiliser une de leurs mains pour enregistrer. L’utilisation d’un micro-cravate ou d’un micro sur pied pourrait régler simplement ce problème. 

59Enfin, l’acte d’enregistrer un nouveau son avec sa voix peut être ressenti comme pouvant perturber l’espace sonore en construction : « dans le flot musical, [...] c’est une sacrée interruption. En gros, tu coupes tout ce qui se passe pour enregistrer ton truc sans que ça s'entende trop, c’est une autre sonorité… ». Ces deux derniers points mettent en évidence la manière dont des aspects tant techniques (point 2) que sociaux (point 3) sont en interrelation.

60Par ailleurs, les participants ont apprécié la posture exploratoire offerte par le système : « Ouais c’est un peu au pif. Enfin, tu fais des trucs et “oh ouais trop bien” et tout et tu gardes et si c’est pas bien ehh. Enfin du coup ça fait partie du jeu j’imagine », tout en remarquant qu’il était parfois frustrant de ne pas pouvoir bien anticiper le type de son produit : « Je pense qu’il y a des sons que j’aurais peut-être voulu faire mais je pense que j’en ai pas été capable et je sais pas si j’en aurais été capable ». Suite à ces remarques, nous avons implémenté un gain sur la synthèse contrôlé par la RMS du son modèle afin de donner une appréhension plus immédiate du volume sonore produit.

3.3. Différences selon les systèmes

61Les participants ont ressenti des impressions et des contraintes très différentes selon les systèmes.

62Dans la session Clone, les participants ont trouvé le résultat sonore « plus aéré et plus subtil » et « plus facile à contrôler » qu’avec le système Drum Machine où « avec le choix des corpus on avait quand même des [...] présences sonores assez fortes ». L’un des participants fait ainsi remarquer que Clone favorise une écoute collective : « le fait que ça soit un nouveau matériau sonore et pas des matériaux qui sont dans une banque [...] incite plus à l’écoute ».

63Avec le système Solar System, où les rôles sont asymétriques, les participants ont remarqué qu’ils avaient moins de contrôle à leur disposition sans que cela soit ressenti comme un problème : « c’était frustrant au début [mais] à la fin on sent qu’on a beaucoup plus de contraintes donc on devient un peu plus créatif ». 

64Les participants ont aussi bien perçu l’asymétrie entre les deux rôles au sein de ce système. L’un des participants ayant le rôle de Satellite s’est ainsi adressé au participant jouant le rôle de Soleil en lui disant « tu es compositeur et nous on interprète ». Cependant certains participants n’ont pas eu vraiment l’impression de jouer avec le Soleil et ont ressenti une certaine « déconnexion » en étant plus concentré sur le résultat sonore que sur ce qu’il faisait.

4. Travail avec un artiste improvisateur

65L’utilisation de la version Solar System embarquée fait l’objet d’une étude au long cours avec l’artiste et improvisateur Jean-Brice Godet7. Celui-ci s’est vu confier l’application Simone et un équipement composé de quatre puis huit Raspberry Pi et paires d’enceinte, ainsi que le matériel nécessaire pour créer un réseau local. En terme méthodologique, la seule consigne était d’utiliser l’instrument régulièrement et de documenter les différentes étapes de son apprentissage et de son utilisation.

4.1. Une deuxième phase de design centrée utilisateur

66Dans une première phase d’apprentissage, Jean-Brice a pu utiliser le dispositif chez lui en solo, ou avec nous en studio. Cette phase a aussi été l’occasion de prendre en compte ses remarques et de procéder à quelques modifications et ajouts dans l’interface de contrôle de l’instrument nous permettant ainsi de rentrer dans une deuxième étape de design prenant en compte les besoins réels d’un utilisateur. 

67Nous avons tout d’abord ajouté une interface d’enregistrement directement accessible dans le navigateur. Celle-ci permet d’enregistrer un son avec le micro de l’appareil utilisé et d’uploader directement ce son dans la banque de son du serveur pour être utilisé en tant que son générateur par la suite. 

68La quantité de manipulation nécessaire pour contrôler quelques Raspberry Pi a très vite démontré l’importance d’un moyen de contrôler les sources sonores par groupes. Au lieu d’une interface permettant de créer différents groupes, ce qui aurait été trop lourd à manipuler et délicat à implémenter, nous avons préféré implémenter des sliders et boutons permettant de contrôler toutes les Raspberry Pi en même temps tout en laissant la possibilité d’en laisser certaines inchangées. Pour la même raison, nous avons aussi implémenté un système de presets permettant de sauvegarder des combinaisons de paramètres. Ces presets sont sauvegardés dans l’ordinateur de l’utilisateur grâce à la fonction localStorage de JavaScript, permettant ainsi de les conserver entre chaque session.

69Pour faciliter la manipulation simultanée de plusieurs paramètres et pour mieux personnaliser son expérience de jeu, Jean-Brice nous a demandé d’implémenter des contrôles MIDI ce que nous avons fait à l’aide d’un composant web que nous avons développé.

70Enfin, afin de provoquer un peu de variations dans certaines situations de jeu, nous avons décidé d’implémenter un nouveau paramètre de synthèse. Celui-ci, appelé randomizer modifie le processus de choix du grain dans la synthèse par mosaicing. Ainsi, au lieu de choisir le grain du son générateur le plus proche du grain modèle considéré, une valeur de randomizer de n permet d’aller chercher un grain au hasard parmi les n grains les plus proches.

71En revanche, un certain nombre de modifications proposées par Jean-Brice n’ont pas été implémentées car elles n’étaient selon nous pas cohérentes avec le design et l’intention originale de l’instrument. Par exemple, Jean-Brice proposait de pouvoir dissocier les sections de boucle sur le son modèle de chaque Raspberry Pi. Ceci allait à l’encontre de la volonté d’avoir un dispositif dont les sources sonores sont contrôlées par la même entrée audio ce qui garantit une certaine cohérence acoustique.

72Cette négociation entre utilisateur/musicien et concepteur du dispositif montre toute la complexité dans la conception d’un instrument musical numérique. Lors d’une session de jeu avec un autre musicien, ce dernier a ainsi observé cette différence avec les instruments de musique plus traditionnel : 

C’est aussi les limites de ce genre de trucs ouvert parce que si tu prends un instrument… tout instrument traditionnel genre violoncelle, piano ça a ses limites et c’est ce qui fait que quand t’en joues, tu connais les limites et quand t’écris pour, tu connais les limites même si tu penses que tu vas les pousser. Le danger du truc qui est modifiable à l'envi c’est que finalement… pourquoi est-ce que tu devrais… ? 

73Un sentiment d’arbitraire peut donc naître chez l’utilisateur dans certains choix de design qui lui sont présentés car tout peut être modifié en quelques lignes de codes. Le fait de laisser trop de paramètres ou d’éléments modifiables à l’utilisateur peut se montrer être un frein au développement d’une pratique instrumentale avec le système. Il s’est alors montré important pour nous de poser des limites et de déclarer quels éléments du système étaient figés et n’avaient pas vocation à être rediscutés. Ainsi, nous nous sommes généralement bornés à accepter des modifications pratiques de type quality-of-life qui ne modifiaient pas l’esthétique de l’instrument.

4.2 L’apprentissage de l’instrument et de techniques de jeu

74Il est intéressant de constater qu’une des premières étapes du processus d’appropriation de l’instrument s'est opérée par la constitution d’une banque de son personnelle de sons générateur. Pour Jean-Brice, celle-ci s’est construite de plusieurs manières selon différentes intentions. 

75Une première partie de cette banque de son est constituée de sons que l’on pourrait qualifier de “sons tests” : sinus, clics, bruit rose, accord de piano, etc. Ces sons ont été envisagés dans un premier temps comme des briques de base pour comprendre comment l'instrument réagit et fonctionne. Cependant, ces sons se sont peu à peu révélés intéressants esthétiquement et ont donc intégré à part entière le matériel musical de Jean-Brice avec Simone, par exemple avec un recours fréquent à des masses de sinus légèrement décalés en fréquence. 

76Une seconde partie de cette banque de sons s’est constituée à partir d’enregistrements personnels de parties instrumentales (soit en solo soit en groupe). La familiarité avec le contenu timbral de ces enregistrements a certainement permis de faciliter le processus d’appropriation. L’utilisation de ce genre de sons permet aussi d’envisager l’utilisation de Simone par Jean-Brice dans la continuité de son travail d'instrumentiste, comme une sorte de remix et de déconstruction de sa propre pratique.

77Enfin dans une dernière partie, la banque de son s’est enrichie de sons glanés dans le quotidien grâce à la page web dédiée à l’enregistrement de sons que nous avons développés, dans une démarche s’approchant d’une esthétique du détournement proche de la musique concrète. Jean-Brice a ainsi pu enregistrer des sons issus d’un direct télévisé du tournoi Roland-Garros pour s’en servir quasi immédiatement dans Simone (cf. Figure 5)

Figure 5. L'interface d'enregistrement de Simone ouverte en même temps qu'un direct télévisé de Roland-Garros sur l'ordinateur de Jean-Brice.

78Au cours de l’utilisation de Simone, Jean-Brice a peu à peu développé des techniques et des habitudes de “jouage” (selon ses propres termes) faisant écho à sa propre pratique musicale avec des dictaphones et des lecteurs de cassettes. Jean-Brice fait ainsi ce rapprochement entre les deux pratiques en évoquant le grand nombre de “manipulations” nécessaires mais aussi en décrivant sa vision du jeu avec Simone comme “un enchaînement de matières sonores” avec superpositions et passages entre des matières “verticales” (cassures ou rythmes) et de matières “horizontales” (nappes sonores non rythmées).

79D’autres habitudes de jouage développées consistent en l’utilisation du même son générateur sur chaque Raspberry Pi mais avec des jeux de paramètres différents pour créer des variations spatiales ou le fait de pousser le logiciel dans ses retranchements avec des jeux de paramètres qui causent ralentissements ou blocage du processus de calcul de la synthèse sonore.

80Pour Jean-Brice, l’intérêt spécifique de Simone réside dans deux aspects. D’une part, bien que le dispositif soit composé de plusieurs sources sonores pouvant être très différentes les unes les autres suivant les combinaisons de paramètres et de sons générateur choisies, la nature du processus de synthèse et le fait que toutes ces sources soient contrôlées par le même son modèle crée un sentiment de cohérence global qui permet d’identifier toutes ces sources comme un seul instrument. 

81D’autre part, la multiplication des sources sonores et leur placement libre dans l’espace constitue un point fort et offre de nombreuses possibilités acoustiques. Ceci est particulièrement audible quand toutes les sources sont réglées sur les mêmes sons générateur avec des paramètres légèrement différents. Jean-Brice décrit alors un sentiment de mouvement entre les sources sonores.

4.3. Différents contextes d’utilisation

82Une fois cette première phase d’apprentissage achevée, nous avons pu, avec Jean-Brice, faire varier les contextes et les échelles d’utilisations. Outre des sessions en solo, Jean-Brice a aussi joué avec Simone avec d’autres musiciens, que ce soit en studio à l’Ircam avec un violoncelliste ou lors d’une résidence artistique en Suisse avec deux autres improvisateurs.

83Lors d’une première session où nous n’avions pas expliqué le principe de Simone, le violoncelliste a révélé être confus, pensant qu’il s’agissait soit d’un simple système de diffusion avec des sons préparés, ou d’un système autonome d’improvisation humain-machine. 

84Déjà habitué à jouer avec Jean-Brice, le violoncelliste a noté une familiarité de langage et reconnu une esthétique générale avec laquelle il était familier dans le jeu de Jean-Brice avec Simone. Notant que le rendu sonore Simone rejoignait celui d’esthétiques musicales électroacoustiques proches du travail sur bande ou du collage sonore, il a remarqué que cela l’avait orienté vers deux stratégies principales d’interaction, soit en rejoignant le côté textural de la musique, soit en s’y opposant en jouant de manière plus mélodique, regrettant ainsi que Simone n’offre pas de possibilités plus mélodiques.

85La résidence artistique en Suisse a pu mettre en évidence les différences d’utilisation de Simone suivant les effectifs instrumentaux. Les autres musiciens ont en effet utilisé des instruments acoustiques (violon et trombone) et électroacoustiques (platines, field recordings). Jean-Brice a pu noter que l’expérience de jeu était plus aisée avec des instruments de nature électroacoustique, à l'esthétique plus proche de Simone, avec qui l’objectif est souvent la co-construction d’une matière sonore collective. Avec des instruments acoustiques, où le jeu improvisé nécessite bien souvent d’être plus réactif et de provoquer des ruptures, le jeu avec Simone était parfois rendu plus difficile à cause de la difficulté de totalement anticiper le résultat du processus de synthèse par mosaicing ainsi que par la faible réactivité d'un instrument manipulé à la souris. 

86Dans tous les cas, si la crainte pouvait naître que la multiplicité des sources sonores risquerait de noyer l’espace auditif et de rendre les autres instruments inaudibles, Jean-Brice a pu noter que ce n’était pas le cas grâce au sentiment de cohérence entre les sources mentionné plus haut et à la couleur spécifique de la synthèse par mosaicing.

En fait on a des matières sonores très différentes [..] et je trouve cette synthèse elle est particulière. Même si le timbre est très différent en fonction des Raspberry elles sont quand même toutes connectées les unes aux autres. T’as une sorte de contrôleur flou mais t’as un contrôle sur tout en même temps [...] Y’a quand même une unité. 

87Enfin, Jean-Brice a aussi pu tester ponctuellement Simone sur un dispositif à quarante Raspberry Pi que nous avions installé à l’Ircam (cf. Figure 6). En terme sonore, cet essai s’est montré très probant, l’échelle et la taille du dispositif accentuant le phénomène de circulation du son mentionné plus haut. Il est cependant très vite apparu que l’interface de contrôle n’était pas adaptée à manipuler autant de sources sonores et demande donc un certain nombre d’adaptations et de modifications actuellement en cours de réflexion.

Figure 6. Jean-Brice utilisant Simone avec un réseau de quarante Raspberry Pi.

Conclusion

88Nous avons présenté Simone, un instrument pour l’improvisation collective et distribuée conçu pour être utilisé par des utilisateurs experts dans un cadre d’improvisation.

89À cette intention, nous avons fait tester Simone à un groupe de 4 utilisateurs experts lors d’un atelier consistant en plusieurs sessions d’improvisation collective et de discussions. Les retours collectés lors de cet atelier ont mis en évidence les points positifs et négatifs du système, et ont mené à un certain nombre de modifications dans sa conception.

90Par ailleurs, la version embarquée du système fait actuellement l’objet d’une étude sur le long court, dont nous avons présenté ici les premiers résultats, dans laquelle nous l’avons confiée à un artiste actif dans le milieu de l’improvisation libre. Cette étude nous permet en particulier d'observer certains aspects de l’appropriation de l'instrument par cet artiste ainsi que les différentes techniques de jeu qu’il a adoptées ou développées au cours de sa prise en main dans différents contextes de jeu. Ces différentes observations nous ont permis d'éclairer une seconde phase de design de l'instrument.

91Les images de l'article sont mises à disposition selon les termes de la licence Creative Commons CC-BY-NC: https://creativecommons.org/licenses/by-nc/4.0/

Notes   

Citation   

Auteur   

Quelques mots à propos de :  Aliénor Golvet

Quelques mots à propos de :  Benjamin Matuszewski

Quelques mots à propos de :  Frédéric Bevilacqua