* Une instance de processus est similaire à l'instance d'une classe : le processus est la classe et l'appel à un processus correspond à l'instanciation d'une classe.

* L'intervalle de temps entre l'appel du processus et la fin du processus correspond à la durée de vie de l'objet.

* Un processus en cours d'exécution est dénoté par une valeur de type `exe`<fnref n="71" /> et l'exe de l'instance correspond à une référence à l'instance de l'acteur.

* L'état de l'objet correspond aux valeurs des variables locales de l'instance de processus.

* Les interactions avec l'objet peuvent être réalisées en affectant ses variables locales.

* Les messages correspondent à des méthodes, i.e. des fonctions ou des sous-processus qui accèdent aux variables locales du processus père. Ces méthodes peuvent mettre à jour l'état du processus en cours d'exécution, prendre des décisions locales, créer d'autres processus, envoyer des messages ou déterminer comment répondre au prochain message reçu.

Même si les acteurs ne sont pas implémentés pas un nouveau type d'entité primitive (leur implémentation repose sur les processus), ils disposent de constructions syntaxiques dédiées dans le langage, afin de faciliter leur définition (construction `@obj_def`) et leur utilisation

### III.4. Parallélisme implicite et hypothèse synchrone

Le langage Antescofo offre des structures de contrôle dédiées que nous allons présenter brièvement.

Nous avons plusieurs fois mentionné que les calculs s'effectuent implicitement en parallèle. Le parallélisme en Antescofo est une notion qui diffère du parallélisme usuel dans un langage impératif. Les différences proviennent du cadre synchrone du langage.

Classiquement, le temps se définit à travers deux notions, les instants et les durées, qui s'organisent à travers trois relations : la simultanéité, la succession et la permanence (le fait de durer). Les langages de programmation séquentielle ne traitent généralement que des instants et de leur succession : la durée réelle d'un calcul n'a pas d'importance, et on ne gère que la succession. Ce modèle du temps est semblable au modèle MIDI où la durée d'une note est implicitement représentée par l'intervalle de temps entre l'activation de cette note (*on*) et sa désactivation (*off*). On ne peut pas dire par exemple qu'un accord commence à un moment donné, car le démarrage de l'émission des notes des accords sont des événements séquentiels distincts, la simultanéité est dans ce cas émulé. Cependant, au niveau conceptuel, cela signifie que la simultanéité ne peut pas

<footnote n="71">⁷¹ Cet *exe* peut être utilisé pour tuer l'instance du processus, accéder à ses données locales, tester si le processus est toujours en cours d'exécution, etc. C'est une valeur comme une autre qu'on peut stocker dans un tableau ou bien passer en argument.</footnote>
être directement exprimée dans le langage, ce qui rendra plus difficile la spécification de certains comportements temporels.

Pour exprimer la simultanéité, on doit imaginer idéalement que les calculs élémentaires s'effectuent instantanément (avec une durée nulle). Ce modèle idéal est désigné sous le terme de « modèle synchrone » ou bien d'hypothèse synchrone<sup>72</sup> car il permet aux événements d'être considérés comme atomiques et de parler formellement de simultanéité. Les conséquences de l'hypothèse synchrone ont été étudiées dans le développement des langages synchrones pour les systèmes embarqués temps réel tels que Esterel [BG92], Lustre [HCRP91] ou Lucid Synchrone [Pou06].

Le langage d'Antescofo reprend le modèle synchrone qui permet de déclencher des événements simultanément. Mais comme pour tous les langages synchrones, les calculs simultanés sont exécutés séquentiellement dans un ordre déterministe qui dépend de l'apparition de l'événement dans la partition. Bien que la notion d'une simultanéité ordonnée séquentiellement peut sembler paradoxale, on peut définir des modèles du temps logiquement cohérent qui formalisent ces notions<sup>73</sup>. Imposer un ordre séquentiel d'exécution à des calculs (de durée nulle) simultanés est fondamental, par exemple pour l'initialisation correcte d'actions audio (par exemple, on ne va pas changer les paramètres d'un synthétiseur s'il n'est pas encore instancié dans la chaîne audio).

Le parallélisme en Antescofo correspond à la simultanéité des calculs. Quatre opérateurs, appelés *opérateurs de continuation*, permettent de contrôler la simultanéité ou la succession de deux calculs *a* et *b* :

* une opération implicite permet de lancer deux calculs simultanément. Cet opérateur se note par la simple juxtaposition des calculs : *a b*;

* le délai permet de retarder le lancement de la seconde action par rapport au lancement de la première d'un délai *d*. Il se note en intercalant le délai *d* entre les deux calculs : *a d b*;

* la continuation simple permet de lancer *b* après la terminaison du calcul *a* et se note : *a <=> b*;

* les calculs pouvant déclencher des sous-calculs de durée variable, récursivement, il existe un dernier opérateur de continuation composée permettant de lancer un calcul *b* après la terminaison de *a* et de tous les sous-calculs induits par *a*. Cette opération se note *a +=> b* et correspond à l'opérateur de succession dans les langages séquentiels classiques.

La figure suivante illustre ces opérateurs :

<footnote n="72"><sup>72</sup> N. Halbwachs, *Synchronous programming of reactive systems*, Springer Science & Business Media, 2013, vol. 215.</footnote>

<footnote n="73"><sup>73</sup> O. Maler, Z. Manna et A. Pnueli, "From timed to hybrid systems", in Workshop/School/Symposium of the REX Project (Research and Education in Concurrent Systems), Springer, Berlin, Heidelberg, 1991. p. 447-484.</footnote>
<figure><img src="image_31.png" /><figcaption>**Fig. 3.6** Illustration imagée des opérateurs de simultanéité, de continuation simple et de continuation.</figcaption></figure>

### III.5. Le *whenever*

La structure de contrôle *whenever* permet de déclencher des actions et des processus à chaque fois qu'une condition logique est vérifiée.

La vérification de la condition n'est pas statique mais dynamique et peut se produire à n'importe quel moment du déroulement de la pièce. Une fois lancé, le *whenever* reste actif jusqu'à ce qu'il soit stoppé explicitement (par une commande *abort*), sinon il reste actif jusqu'à la fin du programme. Quand il est actif, il déclenche un processus (le corps du *whenever*) chaque fois que sa condition est vérifiée.

Cette structure est fondamentale dans le contexte des musiques interactives puisque c'est elle qui va permettre d'interagir avec le monde extérieur qui met à jour un ensemble de variables. Cette mise à jour, qui se produit parallèlement à l'exécution du programme, est surveillée par un *whenever* pendant le temps de sa durée de vie. Comme d'autres structures dans Antescofo, elle est polyphonique, c'est-à-dire que le corps du *whenever* sera déclenché autant de fois que la condition logique est vérifiée et s'exécutera en parallèle avec les autres activités du programme.
<figure><img src="image_32.png" /><figcaption>**Fig. 3.7** Exemple d'utilisation d'un *whenever* pour déclencher une séquence rythmique à partir d'un kick (mouvement brusque) de la main droite captée par un accéléromètre.</figcaption></figure>

La figure ci-dessus illustre l'utilisation d'un *whenever* pour déclencher une séquence rythmique à partir d'un kick (mouvement brusque) de la main droite captée par un accéléromètre. Le kick est détecté par un traitement effectué en amont d'Antescofo, au niveau du capteur de mouvements. Chaque occurrence d'un kick de la main droite est notifié à Antescofo par un envoi de message Max qui met à jour la variable `$R_kick`. De manière interne au programme, la condition logique `$R_kick == $R_kick` est vérifiée dynamiquement, ce qui déclenche le processus `::wavetable_seq3` qui joue une séquence rythmique d'une synthèse par table d'onde avec des hauteurs faites à partir des tableaux des lignes 1 (rythmes) et 2 (fréquences) et d'autres paramètres aléatoires pour chaque instance. La durée de chaque processus est variable et arrêtée par le *abort* entre 2 et 5 temps (ligne 12) après son activation. Le graphique en bas représente la polyphonie intrinsèque en fonction de l'occurrences des kicks.

Tout se passe comme si un *whenever* réévaluait constamment sa condition logique afin de décider s'il faut déclencher l'évaluation de son corps. Cependant, l'implémentation des *whenever* est optimisée et l'évaluation de la condition est paresseuse : elle ne se fait que si sa valeur est susceptible de changer, i.e. quand l'une des variables qui apparaît dans la condition est mise à jour (que ce soit lors d'un calcul interne ou bien de manière externe par un message).

### III.6. Courbes différentielles

Nous ne présenterons pas la notion de courbes échantillonnées (*breakpoint functions*) car cette notion est classique dans les langages musicaux. Cette structure de contrôle permet d'échantillonner une fonction définie par morceaux. Cette fonction peut être définie conjointement à la structure de contrôle ou bien être une NIM, c'est-à-dire une valeur représentant une fonction définie par morceaux. La seule spécificité des *curves* Antescofo est de permettre de parcourir la fonction échantillonnée dans un temps
absolu (temps physique) ou relatif (i.e. synchronisé avec un autre processus ou avec le musicien).

La notion de *curve* a été étendue en Antescofo pour permettre de résoudre des équations différentielles dont la variable est le temps. La solution de l'équation différentielle est échantillonnée (comme pour une courbe définie par une NIM) et on peut aussi définir des points remarquables (appelés *zero crossing*). Ces points sont définis par le passage à zéro d'une quantité arbitraire qui dépend du temps, de la fonction solution et de sa dérivée. En un *zero crossing*, il est possible de changer la valeur de la fonction et/ou d'équation différentielle. Cette fonctionnalité permet dans les faits de définir des fonctions par morceaux, réalisant la notion de systèmes différentiels hybrides largement utilisée en automatique pour le contrôle de dispositifs physiques.

En Antescofo, les courbes différentielles permettent notamment le calcul optimisé de modèles physiques de contrôle. Attention, cette construction n'est pas adaptée à la définition d'oscillateurs pour la synthèse sonore : comme les autres processus Antescofo, les échelles de temps mises en jeu sont la millisecorde et au-delà.

<figure><img src="image_33.png" /><figcaption>**Fig. 3.8** Visualisation d'un système masse-ressort avec une grille de 400 masses. Le système programmé avec le solveur d'équations différentielles intégré dans le langage Antescofo utilise environ 4 % de CPU dans un processeur Intel Core i9 à 2,9 GHz. À titre indicatif, un système masse-ressort de 49 particules programmé directement dans le langage Antescofo utilise environ 30 % de CPU.</figcaption></figure>

### III.7. Mécanismes d'exécution dédiés

Le langage Antescofo propose plusieurs mécanismes d'exécution dédiés particulièrement pertinents dans un contexte d'applications musicales temps réel.

#### Propagation de constantes

Afin de minimiser les calculs à l'exécution, conséquent agressive de propagation des constantes. Toutes les expressions que l'on peut détecter de façon évidente au moment
du chargement du programme comme étant constantes, sont précalculées et propagées comme constantes dans les expressions englobantes.

## Évaluation au chargement

Lors du chargement, il est possible d'exécuter avec la construction `@eval When load` des calculs qui ne seront évalués qu'une seule fois au moment du changement du programme. Cette construction permet d'initialiser à l'avance des chaînes audio ou un set-up complexe.

## Évaluation à la volée

L'interprète Antescofo réagit aux messages de Max ou de PD, mais aussi à des messages OSC. Un canal OSC est spécifiquement réservé à l'évaluation à la volée d'expressions textuelles. Cela permet d'offrir sous des éditeurs de texte tels que Sublime ou Atom une fonction permettant d'évaluer depuis ces logiciels des parties du programme en cours d'écriture. Cette fonctionnalité est particulièrement cruciale pour évaluer des parties de l'électronique pendant le processus de composition, tester des parties du code, par exemple pour des processus génératifs ou interactifs, ou encore faire du *live coding*.

## Fonctions de transport

Spécifiques au langage Antescofo, les fonctions de transport<sup>74</sup> permettent d'activer ou désactiver la machine d'écoute, de jouer et de naviguer dans la partition électronique avec différentes modalités.

Pour citer les plus importantes, la commande « *start* » permet de lancer l'exécution d'un programme, « *stop* » pour l'arrêter, « *startfromlabel* » active la machine d'écoute à partir d'un endroit spécifique dans la partition, « *next_label* » force la détection de l'événement suivant et déclenche les actions qui sont entre l'événement courant et l'événement suivant, « *visit_label* » permet de se positionner à un endroit sans déclencher aucune action précédente, etc.

Ces fonctions sont fondamentales pour jouer et se déplacer dans la partition, par exemple pour commencer à des moments spécifiques de la partition, notamment pendant le processus de composition ou pendant les répétitions des pièces mixtes.

Les fonctionnalités visées sont généralement pensées comme des commandes « extérieures » à un langage de programmation et sont généralement réduites au lancement d'un programme et éventuellement à son arrêt. Pour Antescofo, ces commandes font partie du langage et peuvent se lancer par calcul dans le langage lui-même.

<footnote n="74">74 http://antescofo-doc.ircam.fr/Reference/tempo_transport/#transport</footnote>
## Compilation à la volée

Les programmes Antescofo sont des programmes interprétés. Cependant, il est possible de compiler au vol (un sous-ensemble) des expressions (notamment les expressions arithmétiques et mathématiques). Ce mécanisme permet de produire une version équivalente mais plus efficace afin d'optimiser les ressources CPU de l'ordinateur lors de l'évaluation de ces expressions. Pour ce faire, le code Antescofo est traduit dans un code C++ qui est généré, compilé et lié dynamiquement au programme Antescofo. Lors de l'évaluation de l'expression, c'est le code compilé qui est exécuté au lieu de faire appel à l'interprète.

Ce mécanisme est utilisé pour les *curves* différentes et dans ce cas, la compilation au vol se fait au chargement du programme, ce qui évite de perturber l'exécution de la pièce pendant son exécution. Il est possible de demander explicitement la compilation d'une fonction, et cette compilation se fait alors au moment de cette demande (compilation « just in time »).

Cette fonctionnalité est très prometteuse puisqu'elle pourrait dans le futur s'étendre à plus d'expression, ce qui optimiserait les ressources pour faire plus de calculs et libérerait des ressources pour d'autres traitements (audio, vidéo...) dans un même ordinateur.

```c
1 @fun_def @scale($x, $in_low, $in_high, $out_low, $out_high, $power)
2 {
3     if (($x-$in_low)/($in_high-$in_low) == 0)
4     {
5         $out_low
6     }
7     else
8     {
9         if (($x-$in_low)/($in_high-$in_low)) > 0)
10        {
11            ($out_low + ($out_high-$out_low) * @pow (($x-$in_low)/($in_high-$in_low)), $power))
12        }
13     else
14     {
15         ($out_low + ($out_high-$out_low) * -(@pow (($x+$in_low)/($in_high-$in_low)), $power)))
16     }
17 }
18 }
19
20 $ret := @compilation(MAP{
21     @scale -> [('double', "double", "double", "double", "double", "double"], "double"],
22 })
```

<caption>**Fig. 3.9** Exemple de compilation de la fonction utilisateur *scale* (l'équivalent de l'objet *scale* dans Max). La fonction *@compilation* va faire la compilation et générer une nouvelle fonction *@scale_compiled*. L'argument donné à *@compilation* est un dictionnaire qui décrit la signature des fonctions à compiler. La signature d'une fonction est la spécification du type de ses arguments et du type de la valeur retournée.</caption>

## III.8. Bibliothèque ad hoc

Le langage Antescofo propose une bibliothèque de plus de 300 fonctions permettant de manipuler les types de données de base (symboles, booléens, entiers, flottants, chaînes de caractère, vecteur, dictionnaire, NIM, fonctions, processus, acteurs, *exe*). Parmi ces fonctions, ont peux noter un ensemble de fonctions spécialisées particulièrement utiles dans les applications musicales.
## KNN

K-nearest neighbors (KNN) est une famille d'algorithmes permettant de déterminer rapidement le voisinage d'un point dans un nuage de points. La bibliothèque Antescofo est basée sur *nanoflann*<sup>75</sup>. Nous utiliserons ces fonctions entre autres pour le système de synthèse concatenative spatiale en 3D.

## Réification d'un score Antescofo

Il est possible d'accéder via un ensemble de fonctions à la description des événements musicaux à reconnaître dans une partition Antescofo. Il est par exemple possible de récupérer sous la forme d'une NIM, les changements de tempo dans la partition. Autre exemple, la fonction @bach_score permet de transcrire une partition Antescofo dans un format compatible avec l'objet bach roll<sup>76</sup> dans Max.

## Formats d'entrée/sortie

Plusieurs fonctions permettent de représenter des données dans des formats divers. Il est ainsi possible de définir une valeur Antescofo dans le format Json et inversement, de transformer une valeur Json en une valeur Antescofo. Les valeurs Antescofo sont implicitement traduites en valeur OSC lors de l'envoi d'un tel message, et inversement, les arguments d'un message OSC sont traduits automatiquement en valeur Antescofo. La fonction @nim2vezer permet d'exporter des NIMs (*breakpoints*) vers le séquenceur OSC Vezér<sup>77</sup> basé sur une * timeline* graphique.

## III.9. Représentations graphiques de la partition

Antescofo propose un langage textuel, contrairement à des langages dédiés à la musique comme Max ou OpenMusic. Ces derniers sont des langages à flots de données (*dataflow*), ce qui rend difficile l'explicitation de * timelines* parallèles clairement identifiées comme dans la notation musicale symbolique traditionnelle. Antescofo améliore cet état de fait en proposant une notion explicite de * timeline* à travers les notions de groupe et de processus. Cependant, ces * timelines* étant dynamiques et pouvant être le résultat d'un calcul (par exemple en lançant un processus), il reste difficile d'identifier le code produisant un effet spécifique dans des partitions électroniques comptant des milliers de lignes de code, surtout s'il y a beaucoup de polyphonie et des couches multitemporelles. Cette difficulté impacte grandement la compréhension, la lisibilité et la composition musicale.

Des solutions peuvent être apportées pour pallier ce problème, comme Ascograph, un logiciel permettant de visualiser (et d'éditer) les événements électroniques dans une partition Antescofo sous la forme d'une * timeline* très semblable à celle qui existe dans la plupart des séquenceurs DAW. Cet outil est resté à un stade de maquette et n'est

<footnote n="75"><sup>75</sup> https://github.com/jlblancoc/nanoflann</footnote>

<footnote n="76"><sup>76</sup> https://www.bachproject.net</footnote>

<footnote n="77"><sup>77</sup> https://imimot.com/vezer/</footnote>
actuellement plus développé pour des raisons techniques (les bibliothèques utilisées ne sont plus maintenues).

Des approches alternatives doivent être développées. Nous avons mentionné la fonction `@bach_score` qui permet de construire un piano roll et de l'animer pendant l'exécution du programme Antescofo. Cette approche reste cependant limitée et ne permet pas d'interagir avec la timeline.

## Une direction de recherche

Nous suggérons ici une piste possible, déjà présente d'une façon rudimentaire dans Ascograph et qui consiste en l'association de timelines graphiques à des parties du code.

<figure><img src="image_34.png" /><figcaption>**Fig. 3.10** Interface du logiciel Ascograph avec ses 3 représentations. En haut à gauche, une représentation de type piano roll de la partition instrumentale en notes MIDI, à gauche l'éditeur de texte de la partition instrumentale et de l'électronique et en bas, la représentation graphique des actions électroniques.</figcaption></figure>

Ascograph adopte cette approche mais uniquement pour la spécification des événements musicaux à suivre. Plus généralement, on peut séparer des parties de l'électronique qui fonctionnent en parallèle, par analogie avec les instruments dans une partition d'orchestre, et avoir accès à une représentation de chaque partie aussi bien dans sa représentation graphique qu'en code à un moment déterminé de la partition et pour toutes les parties de l'électronique.

L'interchangeabilité entre le code textuel et la visualisation graphique (l'un étant le miroir de l'autre) serait alors fondamental pour passer d'une représentation à l'autre et pouvoir bénéficier des avantages de chacune. D'une part, le graphique permet de se retrouver facilement dans le déroulement temporel de la musique (* timeline*), et permet de modifier graphiquement certains paramètres (comme les *breakpoints* des courbes, des valeurs de paramètres, etc.). D'autre part, le code textuel permet de spécifier de
manière concise des actions électroniques fines, génératives et expressives grâce au langage de programmation.

Ces deux représentations (* timeline * visuelle et code textuel) seraient utiles à la fois pour le travail de composition, de réalisation et de performance du compositeur et/ou du RIM. On peut aussi imaginer différents rendus graphiques, par exemple un rendu plus général et simplifié représentant le résultat acoustique plutôt que les procédures pour le produire, à destination des chefs d'orchestre, des musiciens, et des performeurs (acteurs, danseurs...). D'autres types de rendu graphique peuvent aussi être imaginés à d'autres fins, par exemple dans des logiciels d'analyse musicale tels que iAnalyse, développé par Pierre Couprie. Un premier test de faisabilité a permis de valider l'importation d'une partition Antescofo dans iAnalyse. Ce travail pourrait aider l'analyse et la documentation, par des musicologues, des pièces mixtes et interactives.

<figure><img src="image_35.png" /><figcaption>**Fig. 3.11** Exemple d'écriture de l'électronique, extrait du début de *Las Pintas*, dans la librairie de notation symbolique dans Max *bach*. Bien que cette écriture présente plusieurs avantages, grâce notamment aux métadonnées qui peuvent être associées à chaque note comme par les différents paramètres de l'électronique et leur évolution, et malgré sa construction dynamique, elle n'est pas adaptée à l'interaction avec le code textuel du langage Antescofo qui peut lancer des processus dynamiquement.</figcaption></figure>
# IV. SuperCollider

Ce chapitre donne un bref aperçu du système SuperCollider (SC) et de son architecture client/serveur. Nous supposerons que le lecteur connaît les principes de la programmation audio et que la notion de graphe audio lui est familière. Nous n'entrerons pas dans les détails de la programmation du serveur de SuperCollider. L'objectif de ce chapitre est de détailler les éléments qui nous ont fait choisir ce système pour un couplage à Antescofo.

## IV.1. SuperCollider dans mon travail

SuperCollider [MC02] a été conçu par James McCartney, au moment où la puissance de calcul des ordinateurs personnels (type Macintosh PowerPC) a permis de faire du traitement en virgule flottante en temps réel [Wil11]. La première version de SuperCollider date de 1996 et la version 3 qui est devenue par la suite open source date de 2001. Cette dernière a été portée sur différentes plateformes (MacOS, Windows et Linux).

Dans le domaine du traitement du signal et de la synthèse sonore, le logiciel est devenu mon outil privilégié, tout d'abord pour sa capacité à créer d'une façon concise et puissante une grande variété de types de sons de synthèse et de traitements et aussi pour sa qualité au niveau du rendu audio (qualité reconnue par beaucoup d'utilisateurs dans le monde). Une autre caractéristique fondamentale est que SuperCollider a été conçu à la base pour le traitement audio en temps réel, l'interaction, la polyphonie et le multicanal, ce qui lui confère une souplesse et un dynamisme qu'on trouve difficilement dans d'autres environnements de synthèse et de manipulation sonore.

Dans la communauté de l'informatique musicale, SC est un logiciel relativement moins répandu que des systèmes comme Max ou PD. Cela est peut-être dû à sa programmation textuelle moins intuitive que des systèmes graphiques de type dataflow.

La première fois que j'ai utilisé SC dans sa version 2, j'ai été impressionné par la qualité du rendu audio et par son langage de programmation avec une syntaxe concise : une seule ligne de code suffit souvent à définir un son très riche. J'ai continué à utiliser SC pendant des années sous l'angle d'un synthétiseur générant du matériau difficilement réalisable dans d'autres environnements. Par la suite, j'ai commencé à programmer un environnement modulaire de composition dans le langage SC slang mais qui adressait uniquement la partie traitement du signal et pas le contrôle temporel.

## IV.2. Un exemple introductif

À l'instar de nombreux autres systèmes de synthèse, SC est utilisé pour définir des graphes audio où les nœuds représentent des UGEN (sommets sans prédécesseurs) ou bien des transformations audio (entre les entrées et les sorties du nœud).
La ligne de code suivante est un exemple simple de synthèse avec deux oscillateurs.

{ [SinOsc.ar(440, 0, 0.2), SinOsc.ar(442, 0, 0.2)] } .play;

Ce fragment de code définit une fonction (entre `{}`) qui appelle la méthode `play`. Cette méthode indique qu'il faut envoyer le résultat de la fonction dans le serveur `scsynth` pour un rendu sonore. La fonction spécifie deux oscillateurs : ce sont des `UGENs` (*Unit generators*), des objets qui produisent un signal audio. Du fait qu'ils sont entre `[ ]` la sortie de la fonction est une sortie multicanale : chaque élément de la liste devient un canal audio. L'exemple va donc jouer un oscillateur à 440 Hz avec une amplitude de 0.2 dans le canal 1 (gauche) et en même temps un second oscillateur à 442 Hz avec une amplitude de 0.2 dans le canal 2 (droite).

La forme textuelle présente de nombreux avantages sur la forme visuelle qui s'est imposée dans de nombreux outils. À titre de comparaison, entre un langage textuel (SuperCollider) et un *data flow* (Max), voici un exemple de la synthèse appelée « bubbles » réalisée par James McCartney. Elle génère un son de synthèse qui module dans le temps et qui est assez riche. La figure suivante est la fonction qui permet de définir cette synthèse et de la jouer.

1 // analog bubbles

2 {

3 f = LFSaw.kr(0.4, 0, 24, LFSaw.kr([8,7.23], 0, 3, 80)).midicps; // glissando function

4 CombN.ar(SinOsc.ar(f, 0, 0.04), 0.2, 0.2, 4) // echoing sine wave

5 }.play

<caption>**Fig. 4.1** Code représentant l'exemple « bubbles », synthèse réalisée en SuperCollider par James McCartney, avec utilisation de l'expansion multicanale. L'expression `LFSaw.kr([8, 7.23])` avec un tableau de deux éléments permet d'une façon simple de créer différentes instances du générateur LFSaw en multicanal, dans ce cas en stéréo.</caption>

La figure suivante est la même synthèse, avec le même résultat sonore, défini dans Max de façon visuelle. On peut apercevoir que la représentation graphique, même si plus intuitive et facile à comprendre à première vue, reste beaucoup moins concise. Avec la pratique, il n'y a plus de différence et le langage textuel est finalement beaucoup plus lisible.
<figure><img src="image_36.png" /><figcaption>Fig. 4.2 La même synthèse « bubbles » réalisée dans l'environnement Max.</figcaption></figure>

IV.3. Une architecture client/serveur

SuperCollider est fondé sur le paradigme serveur/client où le client est un IDE
(environnement de développement) pour le langage de programmation slang, et le
serveur scsynth un moteur de rendu audio. Le logiciel est conçu et structuré pour le
temps réel et isole ces traitements dans le seul serveur.

L'exemple précédent est écrit en slang et est compilé en une suite d'instructions pour une machine abstraite audio temps réel qui est implémentée par le serveur scsynth. Mais le serveur est agnostique : slang est un client particulier, mais n'importe quel programme peut adresser directement le serveur. C'est ce qui sera fait pour AntesCollider qui permet d'utiliser Antescofo comme un client de scsynth.

Une autre propriété importante inhérente au paradigme client/serveur adopté par le système slang/scsynth est que le contrôle et les interfaces graphiques sont complètement séparés du moteur audio. Le serveur audio scsynth est dédié à l'analyse, à la synthèse et au traitement audio en temps réel (mais aussi différé, cf. plus bas). Le contrôle des processus de traitement du signal est assuré par le client (habituellement un programme dans le langage slang, mais comme nous venons de l'indiquer, n'importe quel programme qui interagit avec scsynth).

Cette séparation client/serveur permet aux interfaces graphiques de ne pas interférer
avec les parties de traitement du signal. De plus, par son caractère dynamique, seuls
les traitements graphiques et les traitements audio réellement nécessaires seront actifs.
Ceci permet une grande optimisation des ressources.
L'autre avantage de cette architecture est de compartimenter les traitements, propriétés importantes en cas de crash d'un élément du système. Cette architecture simplifie aussi la réalisation de dispositifs redondants permettant d'activer des instances de rechange (*spare*) du client ou du serveur, prenant automatiquement le relais pendant l'exécution de la pièce en cas de problème. Le système offre donc un grand gain en ressources et un système plus robuste.

<figure><img src="image_37.png" /><figcaption>**Fig. 4.3** Architecture serveur/client du logiciel SuperCollider. À gauche, la partie client avec un IDE, l'interprète et le langage pour contrôler les serveurs scsynth ainsi que pour générer des interfaces graphiques dynamiquement. À droite, une représentation des serveurs audio, on peut instancier plusieurs en parallèle.</figcaption></figure>

## IV.4. La structure dynamique d'un graphe audio dans SC

SuperCollider est un descendant direct des langages de synthèse audio Music-N avec le concept de *Unit Generators* (UGens) (générateurs de signaux élémentaires) dont les calculs sont implémentés dans le serveur de synthèse scsynth. Les UGens permettent un contrôle en temps réel de tous les paramètres de la synthèse. Leurs combinaisons et la transformation de leur sortie permettent de créer efficacement un système modulaire de chaînes audio dynamiques.

Les interconnexions des UGens sont organisées en arborescences (*Nodes*) dans des définitions de synthèse (*SynthDef*). Cette architecture permet une grande flexibilité, modularité et restructuration. En effet, on peut dynamiquement et en temps réel instancier, placer, déplacer et détruire les *Nodes* à n'importe quel endroit de l'arborescence : « *Les graphs audio (construction des chaînes de traitement audio) peuvent être regroupés en arbres arbitraires dont l'ordre d'exécution et d'évaluation peut être modifié dynamiquement.* » [MC02]
```pascal
SynthDef(\SimpleSine, {[freq = 440, out| Out.ar(out, SinOsc.arHz, 0, 0.2)) }).add;

x = Synth(\SimpleSine);
y = Synth(\SimpleSine, [freq, 660]);

x.free; y.free;
```

**Fig. 4.4** Code représentant un exemple de base d'une définition de synthèse SynthDef dans SuperCollider avec une UGen *SinOsc* pour générer une forme d'onde sinusoïdale avec une fréquence par défaut de 440 Hz. Les variables *x* et *y* vont instancer dynamiquement deux synthèses différentes, *x* avec la fréquence par défaut et *y* une fréquence de 660. *x.free*; *y.free*; permettent de libérer les deux synthèses et de les enlever de la chaîne de DSP.

La librairie JIT (*Just-in-Time*) intégrée dans SuperCollider permet de modifier dynamiquement non seulement les paramètres des définitions de synthèses SynthDef précompilés, mais aussi leur structure interne (*graph*). On peut ainsi, comme déjà évoqué, n'activer que les traitements nécessaires à un moment donné. Cependant, cette dynamicité permet d'aller plus loin et ouvre la voie à de nouveaux types d'interactions. Par exemple, la librairie JIT (*Just-in-Time*) permet de remplacer un générateur sinusoïdal *SinOSC*<fnref n="78" /> par un générateur de bruit *WhiteNoise*<fnref n="79" /> dans la chaîne de traitement. Cette capacité ouvre de nouvelles possibilités pour le *live-coding* et l'expérimentation dans le domaine de la synthèse sonore :

> « It is impossible to write a program while it runs. A program describes and determines a process, so changing the description implies a new outset, a new process. Yet it is possible to structure a program in such a way that parts of it can be interchanged dynamically, and its textual form can be arranged to allow rewriting those parts while the whole process continues. Thus, instead of first designing an application that has fixed interaction points (parameters), the program text itself becomes the main interface. » [Will11]

## IV.5. Le choix de scsynth comme moteur audio

Ce dynamisme est un avantage considérable par rapport aux systèmes graphiques de type *dataflow* comme Max/Pd et une des principales motivations pour la création de la librairie AntesCollider.

Parmi d'autres avantages, il y a la polyphonie qui fait partie intégrante de l'architecture : on peut lancer plusieurs instances d'un même processus de synthèse et les contrôler ou les arrêter de manière globale ou locale. Cette fonctionnalité est aussi très importante dans la librairie AntesCollider du fait que le langage Antescofo (comme

<footnote n="78">⁷⁸ https://doc.sccode.org/Classes/SinOsc.html</footnote>

<footnote n="79">⁷⁹ https://doc.sccode.org/Classes/WhiteNoise.html</footnote>
vu précédemment) permet aussi l'instanciation d'un même processus polyphoniquement et à la volée.

Enfin, la gestion du multicanal ou « *mutichannel expansion* »<fnref n="80" /> (chaque élément d'un tableau représente simplement la sortie du canal audio correspondant) est aussi une fonctionnalité fondamentale du système. Elle permet de travailler sur des chaînes audio de n'importe quel nombre de canaux d'une façon simple et globale (à titre de comparaison, le multicanal dans Max a été introduit seulement en 2018 dans sa version 8).

En résumé, le choix de SC pour prendre en charge les traitements audio a été motivé par les caractéristiques suivantes :

* moteur audio précis et efficace de haute qualité ;

* fréquence d'échantillonnage (192 k +) et taille de bloc entièrement réglables ;

* chaîne de signal audio en arithmétique flottante 32 bits ;

* l'échantillonnage de buffers (*sampling buffers*) utilise des flottants en 64 bits ;

* modulation du taux de contrôle rapide et fluide ;

* un riche ensemble de 250 générateurs (UGens) prédéfinis dans la distribution de base ;

* des centaines d'autres UGens développés par la communauté de développeurs ;

* la prise en charge de n'importe quel nombre de canaux d'entrée et de sortie, caractéristique critique pour la gestion des grandes configurations multicales et des systèmes de spatialisation comme le HOA ou la WFS ;

* le logiciel est libre et en open source.

Il faut aussi citer une fonctionnalité qui n'est pas encore intégrée dans la librairie AntesCollider mais qui est particulièrement intéressante : le rendu hors ligne (*Non-Real-Time*, NRT). Ce mode d'exécution du serveur permet de faire des traitements audio qui ne sont pas possibles en temps réel (pour des raisons de puissance de calcul) ou pour générer du matériau audio en masse (*batch processing*<fnref n="81" />).

## Un choix largement partagé

Par sa performance, son optimisation des ressources, son architecture de gestion des *Nodes* et sa notion de graphe audio dynamique et versatile, le serveur SuperCollider scsynth est utilisé par différents systèmes en tant que serveur et moteur de rendu audio,

<footnote n="80">⁸⁰ https://doc.sccode.org/Guides/Multichannel-Expansion.html</footnote>

<footnote n="81">⁸¹ Traitements par lots.</footnote>
notamment pour des systèmes de *live coding* tels que Tidal Cycles<sup>82</sup>, Sonic Pi<sup>83</sup> et a été
interfacé avec d'autres langages de programmation comme Scheme (rsc3<sup>84</sup>), Common
Lisp (cl-collider<sup>85</sup>), Haskell (hsc3<sup>86</sup>, Vivid<sup>87</sup>), Python (FoxDot<sup>88</sup>), Java (JCollider<sup>89</sup>),
Scala (ScalaCollider<sup>90</sup>), Lua ( Lua2SC<sup>91</sup>), JavaScript (supercollider.js<sup>92</sup>), entre autres<sup>93</sup>.
SuperCollider a aussi été intégré dans des systèmes embarqués, notamment dans
Raspberry Pi<sup>94</sup> et BeagleBone Black<sup>95</sup>, ou dans des DMI intégrés comme Organnelle<sup>96</sup>,
Bela<sup>97</sup> ou Norns<sup>98</sup>. Ces langages pilotent le serveur en temps réel.

IV.6. Extensibilité du serveur scsynth

Bien que SuperCollider comprenne une vaste librairie de UGens pour faire toutes sortes
de synthèses, traitements et analyses, il est possible d'étendre les possibilités existantes
en programmant de nouvelles UGens directement dans un langage C++ [Will11]. Une
vaste collection existe déjà, les sc3-plugins<sup>99</sup> et font partie intégrante du logiciel.

Une autre manière de spécifier des modules de traitement et de synthèse est de les
définir à partir du langage FAUST<sup>100</sup> développé au GRAME. Il est en effet possible de
traduire le code des traitements DSP spécifiés en FAUST vers différentes plateformes
incluant les SuperCollider UGens. Il est ainsi possible d'étendre la librairie de SC. Et
la librairie AntesCollider utilise ainsi plusieurs modules issus de FAUST, notamment
pour la spatialisation avec les librairies SC-HOA [GRLE17] basée sur la librairie
Ambitools [LEGA15] et Ambisonic Decoder Toolbox<sup>101</sup> pour faire des traitements dans
le domaine de l'ambisonie.

<footnote n="82"><sup>82</sup> https://tidalcycles.org/index.php/Welcome</footnote>

<footnote n="83">⁸³ https://sonic-pi.net</footnote>

<footnote n="84">⁸⁴ http://rohandrape.net/?t=rsc3</footnote>

<footnote n="85">⁸⁵ https://github.com/byulparan/cl-collider</footnote>

<footnote n="86">⁸⁶ http://rohandrape.net/?t=hsc3http://rohandrape.net/?t=hsc3</footnote>

<footnote n="87">⁸⁷ https://www.vivid-synth.com</footnote>

<footnote n="88">⁸⁸ https://foxdot.org</footnote>

<footnote n="89">⁸⁹ https://www.sciss.de/jcollider/</footnote>

<footnote n="90">⁹⁰ http://github.com/Sciss/ScalaCollider</footnote>

<footnote n="91">⁹¹ https://github.com/sonoro1234/Lua2SC</footnote>

<footnote n="92">⁹² https://github.com/crucialfelix/supercolliderjs/</footnote>

<footnote n="93">⁹³ https://supercollider.github.io/community/systems-interfacing-with-sc</footnote>

<footnote n="94">⁹⁴ https://www.raspberrypi.org</footnote>

<footnote n="95">⁹⁵ https://beagleboard.org/</footnote>

<footnote n="96">⁹⁶ https://www.critterandguitar.com/organelle#whats-new</footnote>

<footnote n="97">⁹⁷ https://blog.bela.io/2017/10/29/bela-and-supercollider-live-coding-sensors/</footnote>

<footnote n="98">⁹⁸ https://monome.org/docs/norns/</footnote>

<footnote n="99">⁹⁹ https://github.com/supercollider/sc3-plugins</footnote>

<footnote n="100">¹⁰⁰ https://faust.grame.fr/index.html</footnote>

<footnote n="101">¹⁰¹ https://bitbucket.org/ambidecodertoolbox/adt/src/master/</footnote>
La possibilité d’intégrer des plugins VST<sup>102</sup> dans scsynth (VSTPlugin UGen<sup>103</sup>) ouvre la porte à tout un univers de plugins issus de différents instituts de recherche (par exemple les célèbres IEM *Plug-in Suite*<sup>104</sup> ou SPARTA<sup>105</sup> pour étendre les possibilités dans le domaine ambisonique) ainsi qu’à des plugins du commerce comme des instruments virtuels ou des traitements, notamment pour le *mastering*.

Grace à cette possibilité, la librairie AntesCollider intègre aussi les plugins VST et FAUST qui deviennent des modules banalisés qui peuvent être intégrés, instanciés dynamiquement et contrôlés algorithmiquement dans le temps par le langage Antescofo.

Cette extensibilité, son architecture client/serveur et son statut de logiciel libre (*open source*) confère à SuperCollider scsynth la possibilité d’intégrer simplement de nouveaux systèmes de synthèse dans différents domaines, et aussi d’être intégré comme moteur de synthèse dans des systèmes indépendants. Ces propriétés assurent la pertinence et la pérennité du système à travers le temps.

<figure><img src="image_38.png" /><figcaption>**Fig. 4.5** Schéma représentant l’extensibilité des modules de traitement et synthèse de scsynth grâce à la possibilité de programmer des UGens SuperCollider dans le langage C++, FAUST ce qui permet la création des définitions de synthèses SynthDef ainsi que l’intégration des plugins VST dans la chaîne de traitements.</figcaption></figure>

<footnote n="102"><sup>102</sup> VST (Virtual Studio Technologie) est un format ouvert de plug-ins créé par la société allemande Steinberg en 1996.</footnote>

<footnote n="103"><sup>103</sup> https://git.iem.at/pd/vstplugin/-/releases</footnote>

<footnote n="104"><sup>104</sup> https://plugins.iem.at/</footnote>

<footnote n="105"><sup>105</sup> http://research.spa.aalto.fi/projects/sparta_vsts/</footnote>
# V. La librairie AntesCollider : un système dynamique de composition et d’écriture de l’électronique en temps réel

Dans ce chapitre, nous détaillons la conception et la réalisation de la librairie AntesCollider que j’ai développée au cours de cette thèse. Cette librairie est une première étape dans le développement d’un environnement adressant la notion de partition centralisée.

Nous récapitulons tout d’abord les éléments qui nous ont amenés à développer cette librairie et les objectifs attendus (section 1). Les principales caractéristiques de la librairie sont présentées (section 2) avant d’entrer dans les détails techniques.

La communication entre Antescofo et scsynth est détaillée (section 3) avant de présenter la structure des graphes audio qui seront créés et gérés par AntesCollider (section 4). Ces graphes sont construits puis contrôlés automatiquement à travers des objets Antescofo et nous détaillons les plus importants (section 5). La section suivante détaille un exemple d’utilisation de la librairie, de bout en bout (section 6). Les arguments permettant de paramétrer la création des objets AntesCollider sont listés à la section 7 (un listing plus exhaustif est donné en annexe de ce document, cf. section 8). Nous présentons ensuite la création automatique des interfaces utilisateurs permettant de commander dynamiquement les traitements audio (section 9).

Nous avons aussi implémenté un programme indépendant permettant de visualiser dynamiquement des données issues des modèles physiques que nous avons développés sous Antescofo. Ces modèles physiques servent à piloter les synthèses sous AnteCollider et il est important de pouvoir visualiser les calculs en temps réel (section 10).

Les œuvres développées avec AnteCollider, qui ont permis de valider ce travail, sont recensées à la section 11. Le chapitre se termine par quelques retours critiques et l’évocations des développements futurs qui pourraient y répondre (section 12).

## V.1 De la partition centralisée à AnteCollider

### Motivations

Aujourd'hui, il existe toute une panoplie d'instruments électroniques, d'objets de synthèses et de traitements accessibles depuis un DAW ou encore des environnements tels que Max/Pd/FAUST (entre autres). Ces systèmes peuvent s'étendre grâce à des plugins (VST ou autres formats) et adressent la performance en *live*. Ces systèmes sont adaptés à un grand nombre des genres musicaux mais pour l'exploration qui m'intéresse, il leur manque un chef d'orchestre qui va permettre de coordonner d'une façon souple le jeu et l'interaction entre eux ainsi qu'avec le monde extérieur (instrumentiste/performeur, interfaces de contrôle, capteurs, etc.).
On a vu aussi que les solutions de gestion et composition temporelles à différentes
échelles et pendant une performance en temps réel, restent encore trop limitées, surtout
si on les compare à la richesse et à la diversité des traitements du son et des
synthétiseurs qu'ils soient du commerce, libres ou issus de centres de recherche.

Ces considérations m'ont amené à développer la librairie AntesCollider [FEGIDO19]. Programmée dans le langage Antescofo, AntesCollider est le résultat d'études, de recherches et de pratiques sur les outils informatiques existants en relation avec la création contemporaine dans le but d'étendre les possibilités musicales et de composition de l'électronique. Elle s'inspire à la base aussi bien des logiciels commerciaux (tels que les DAW) que des logiciels et langages de programmation plus spécifiques du travail de composition tels que Max ou OpenMusic.

AnteCollider vise le développement d'un environnement de travail centralisé
d'écriture de l'électronique. Les utilisateurs ciblés sont les compositeurs, les designers
sonores et les RIM qui s'intéressent à la composition, à la création sonore, à
l'interactivité et au temps réel. La souplesse, l'expressivité et la variété des possibilités
offertes par cette librairie devraient aider à augmenter l'espace de pensée
compositionnelle et induire de nouvelles approches pour concevoir la musique
électronique et l'interactivité musicale.

Objectifs

AnteCollider est une librairie qui essaye d'aller vers une plus grande flexibilité en
intégrant un langage de programmation du temps, Antescofo, avec un moteur de
synthèse audio performant, souple et dynamique, le serveur SuperCollider scsynth :

* l'intégration à un langage de programmation dédié textuel permet de s'affranchir des systèmes fermés où tout est déjà préprogrammé, et où les structures du calcul sont fixes et statiques ;

* l'intégration à un serveur scsynth permet de spécifier finement les processus de synthèses et de transformations sonores au sein d'une même partition centralisée Antescofo.

Un langage textuel comme Antescofo, pleinement intégré à Max, permet de combler
le manque de coordination temporelle auquel nous nous sommes malheureusement
habitués avec les outils existants. Il apporte aussi des structures de données modernes
(fonction de premier ordre, acteur, dictionnaire) avec un ensemble très riche de
fonctions dédiées permettant de les manipuler. Les possibilités offertes par le langage
facilitent la manipulation et enrichissent l'espace de pensée du compositeur avec de
nouvelles interactions, et permettent l'écriture de structures temporelles et
compositionnelles en relation avec le jeu en direct du performeur.

V.2. Principales caractéristiques de la librairie AnteCollider

La librairie AnteCollider exploite l'architecture client/serveur du logiciel
SuperCollider en pilotant un ou plusieurs serveurs scsynth à partir du langage
Antescofo. Ceci va permettre d'intégrer les avantages d'un langage permettant un contrôle synchrone et expressif à un moteur de synthèse dynamique et performant, et offrir ainsi un environnement d'écriture de l'électronique centralisée et adapté à la composition des musiques interactives en temps réel.

Cette intégration présente plusieurs avantages, surtout au niveau de la souplesse et de l'optimisation des ressources de calcul par rapport à des systèmes plus standard comme les stations audionumériques ou les logiciels plus versatile de type dataflow tels que Max/Pd.

Elle permet de créer des processus polyphoniques de contrôle grâce aux processus et objets Antescofo et des processus audio par l'intermédiaire des SynthDefs SuperCollider. En effet, on va pouvoir associer des processus Antescofo à des processus audio dans scsynth et les activer autant que nécessaire de façon naturelle puisque cette caractéristique polyphonique est propre aux deux systèmes.

Ce dynamisme est le principal avantage de la librairie, il va permettre de créer et détruire dynamiquement n'importe quelle configuration musicale électronique quels que soient les processus impliqués, processus audio comme processus de contrôle. Le système permet ainsi de passer d'une configuration à une autre, arbitrairement différentes, avec une grande fluidité et de façon discontinue ou bien continue par interpolation des paramètres, par des fondus enchaînés ou encore par des processus algorithmiques quelconques.

La composition, l'ordonnancement et la synchronisation d'événements musicaux sont spécifiés, gérés et contrôlés grâce aux fonctionnalités de suivi de partition et au séquenceur sophistiqué intégré dans Antescofo. Ces fonctionnalités sont de bien plus haut niveau que celles offertes par le langage slang dans l'environnement SuperCollider. En particulier, grâce à son contrôle de plus haut niveau, la librairie AnteCollider permet de simplifier significativement la gestion des modules de traitements et les connexions entre modules à l'intérieur du serveur scsynth. Voici quelques avantages de la librairie AnteCollider sur l'utilisation du client slang :

* La création et la connexion de chaînes de traitements, le routage vers différentes destinations (par exemple vers des pistes auxiliaires) et la création de pistes pour la spatialisation (HOA, VBAP...) se font directement dans la librairie. L'utilisateur n'a pas à gérer les « bus » de connexion audio, la création des groupes et *Nodes* et leurs ordres, ce qui dans slang devient assez complexe si on n'a pas un système qui les organise et les gère.

* Bien que slang dispose d'un système de « *pattern* » rythmique assez complet, performant et sophistiqué, ainsi que des « *routines* » pour gérer des événements temporels, il présente plusieurs contraintes structurelles. Il n'existe pas de notion globale de contrôle et la gestion de différentes temporalités devient rapidement complexe. Dans le langage Antescofo, la gestion temporelle est transparente, complètement programmable et modifiable grâce aux structures de données et
de contrôle (par exemple, chaque processus peut disposer de son tempo local, indépendamment du tempo global du musicien suivi).

* Le modèle de programmation offert par Antescofo offre un séquenceur sophistiqué qui permet de spécifier une partition électronique, avec par exemple la multitemporalité et les différentes fonctions de transport.

* L'écriture du temps dans le langage Antescofo est exprimée aussi bien en temps relatif à un tempo dynamique (qui peut changer au cours du temps) qu'en temps absolu (en secondes ou millisecondes). Elle permet une modulation de temporalité souple et en relation avec l'environnement (par exemple l'instrumentiste dans le cas du suivi de partition). Dans slang, bien qu'il y ait des extensions et des librairies externes (comme Quarks<fnref n="106" />) pour définir et organiser des structures temporelles et de tempi, ils ne sont pas complètement intégrés à un système de partition électronique centralisée et à un suivi de partition comme dans Antescofo et la librairie AntesCollider.

## V.3. Communications entre le serveur scsynth et Antescofo

Le langage Antescofo intègre le protocole de communication Open Sound Control OSC [WRFR97] pour communiquer en entrée et sortie vers d'autres environnements de programmation et logiciels musicaux ainsi que pour interagir avec des applications vidéo, lumières, microcontrôleurs, etc. La gestion des messages OSC est réalisée dans Antescofo à travers trois primitives :

* `Oscsend`: définit un canal de sortie OSC utilisé pour envoyer des messages à un ensemble de récepteurs OSC spécifiés par une adresse IP, un numéro de port et, éventuellement, un en-tête prédéfini de message. Les messages sont ensuite envoyés sur ce canal avec la même syntaxe qu'un message Max.

* `Oscrecv`: définit un canal d'entrée OSC utilisé pour traiter les messages OSC entrant dans un ensemble de ports spécifiés. En option, un en-tête de message peut être spécifié pour limiter les messages traités à ceux avec cet en-tête. Antescofo réagit à la réception de ce message en déclenchant un processus ou bien en assignant les arguments du message à des variables (qui peuvent être surveillées par un *whenever* si besoin).

* `osc_client`: définit un canal de communication bidirectionnel (entrée et sortie). Cette primitive ne spécifie pas de préfixe de message : lorsqu'un message est envoyé, le premier argument du message est utilisé comme en-tête et le reste des paramètres sont les arguments du message OSC. C'est ce mode de communication qui est adapté à la communication avec scsynth.

<footnote n="106">¹⁰⁶ https://github.com/supercollider-quarks/quarks</footnote>
Les deux commandes *oscsend* et *oscrecv* établissent uniquement un canal unidirectionnel avec un processus externe, comme c'est le cas dans la plupart des implémentations OSC, par exemple les objets *udpsend* et *udpreceive* dans Max.

Pour communiquer avec scsynth, Antescofo utilise la commande *osc_client* : le serveur utilise les métadonnées UDP du message envoyé par Antescofo pour répondre<sup>107</sup> sans avoir besoin de lui spécifier à l'avance un port d'écoute qui serait utilisé par Antescofo. Une fois lancé, le nom du canal peut être utilisé pour envoyer des messages OSC à un récepteur, le serveur scsynth, tandis que le rappel est activé pour gérer les messages entrants du serveur. Le programme Antescofo agit comme un client dans une relation client/serveur bidirectionnelle.

<figure><img src="image_39.png" /><figcaption>Fig. 5.1 : Architecture client-serveur de la librairie AntesCollider.</figcaption></figure>

Cependant, le serveur répond aux requêtes du client mais ne s'engage pas dans une interaction non initiée par le client [FEGIDO19].

Ce pont de communication bidirectionnel OSC entre le client Antescofo et le serveur scsynth est la base du fonctionnement de la librairie AntesCollider et il va permettre tous les échanges d'ordres et des données entre les deux logiciels.

<footnote n="107"><sup>107</sup> W. R. Stevens, B. Fenner et A. M. Rudoff, *UNIX Network Programming: The Sockets Networking API*, Addison-Wesley Professional, 2004, vol. 1.</footnote>
```perl
1 // Lance une instance de SuperCollider scsynth
2 // et demande d'écouter les demandes du client dans le port 57110
3 _ := @system("scsynth -u 57110 &")
4
5 // ouvre un canal de communication OSC en mode client vers SuperCollider
6 // la variable $server reçoit la réponse du serveur scsynth
7 osc_client scServer localhost:57110 * $server
8
9 // vérifie la variable $server pour réagir à la communication du serveur
10 whenever ( $server )
11 {
12   print "ANSWER: " $server
13 }
14
15 // initier la connexion avec scsynth
16 // en envoyant la commande "/notify"
17 scServer "/notify" 1 // le serveur répondra "/done /notify"
```

<caption>**Fig. 5.2** Exemple de création d'une communication bidirectionnelle élémentaire entre le langage Antescofo et le serveur scsynth avec la commande `osc_client`. Quand Antescofo envoie via `osc_client` le message « `/notify 1` », le serveur répond « `/done /notify` ». Cette réponse sera notifiée au programme Antescofo en assignant à la variable `$server` un tableau contenant l'en-tête et les arguments de la réponse. Une construction `whenever` est utilisée pour réagir à cette assignation et imprimera la valeur de la variable.</caption>

## V.4. Structuration des traitements scsynth dans la librairie AnteCollider

Comme expliqué précédemment dans la partie consacrée au logiciel SuperCollider, l'architecture d'interconnexions entre les modules de traitements, synthèses et d'analyses audio du serveur scsynth est fondée sur la notion d'arborescence. Cette arborescence se structure en *Nodes* (nœuds). Pour scsynth, un *Node* peut être aussi bien une définition de synthèse *SynthDef* qu'un groupe *group* (un nœud de groupes sur le serveur, qui est une collection d'autres nœuds organisés sous forme de liste liée). Les nœuds sont dénotés par un identifiant unique. Les *Nodes* au sein d'un *group* peuvent être contrôlés ensemble et peuvent être à la fois des *SynthDef* (synthés, traitements et analyses) ou d'autres groupes imbriqués. Les *groups* sont donc utiles pour l'organisation et le contrôle d'un certain nombre de *Nodes* en parallèle et, lorsqu'ils sont utilisés comme cibles, ils permettent de contrôler l'ordre d'exécution (l'ordre dans la chaîne DSP).

AnteCollider utilise l'organisation et l'imbrication de *Nodes* en groupes et groupes de synthèse, ce qui permet un contrôle des paramètres des *Nodes* soit individuellement soit en groupe à différents niveaux. Par exemple, on va pouvoir modifier l'amplitude du niveau de sortie du serveur (volume master), d'un groupe de pistes (*tracks*) de synthèses, des *tracks* ou des modules de synthèses isolés.
<figure><img src="image_40.png" /><figcaption>**Fig. 5.3** Structure en arborescence et imbriquée en groupes dans une architecture multiserveur *scsynth*. Chaque serveur peut contenir plusieurs *Nodes* qui sont créés dynamiquement. Le *Node* racine avec un index 0 se crée au lancement du serveur et ne peut pas être détruit. Il contient le groupe « *Default* » qui à son tour contient l'ensemble des *Mix_group*. Ces groupes contiennent les *tracks* qui sont eux-mêmes des groupes qui contiennent les modules de synthèses et traitements.</figcaption></figure>

Cette arborescence et les connexions audio multicales entre les modules (avec des bus d'interconnexions audio) peut devenir complexe si on instancie plusieurs chaînes de traitements en parallèle, ce qui est souvent le cas dans les musiques interactives. La libraire AnteCollider prend en charge la construction et l'organisation des arborescences grâce aux structures de contrôle et données du langage Antescofo.

Le modèle de l'organisation des arborescences dans AnteCollider est basé sur le paradigme de pistes (*tracks*) des tables de mixage audio classique ou des stations audionumériques. Cette architecture permet d'organiser et structurer les *Nodes* des groupes et de traitement/synthèse d'une façon intuitive et facile à utiliser.

## V.5. Objets de la librairie AnteCollider

Pour instancier et contrôler les *Nodes* des serveurs scsynth, la librairie AnteCollider implémente trois types d'acteurs qui sont créés, contrôlés et détruits dynamiquement. Les quatre figures suivantes illustrent ces constructions.
### Sc_server

**sc_server** permet de créer un serveur scsynth et de contrôler tous ses paramètres. On peut créer autant de serveurs qu'on veut, même si cette fonctionnalité a été pensée pour utiliser au mieux le nombre de cœurs du processeur de l'ordinateur et profiter au maximum des capacités de calcul parallèle de la CPU.

Le serveur scsynth est séquentiel (monothread). L'expérience montre que si l'on dispose de *n* cœurs de calcul, il est utile de créer jusqu'à *2n* serveurs. La répartition des instances de serveurs dans les processeurs est assurée par le système d'exploitation. Une version multithread de SuperCollider appelée SuperNova [Ble10] existe et permettrait d'utiliser un seul serveur qui accéderait à toutes les ressources de calcul, mais elle n'a pas encore été intégrée à AntesCollider.

### Mix_group

**mix_group** implémente un container de groupes de tracks (les tracks sont définis ci-dessous). Ce groupe peut gérer n'importe quel nombre de canaux (par défaut 8) et peut aussi avoir un format de spatialisation spécifique de type VBAP [Pul97], DBAP [LBH09] ou HOA (High Oder Ambisonic) [Mal99]. Un *mix_group* en format HOA peut être créé avec un ordre de 1 à 5.

Les tracks instanciés dans un *mix_group* héritent de son format. Par exemple, dans *mix_group_HOA* d'ordre 5, tous les tracks qui seront créés en son sein auront le format HOA d'ordre 5 avec des bus audio de 36 canaux (codification en ordre 5).

Les différents *mix_group* peuvent utiliser différents formats : on peut donc mixer de la stéréophonie avec de l'ambisonie en HOA ou en VBAP en même temps dans un ou plusieurs serveurs scsynth.

### Crea_track

**crea_track** gère un groupe qui contient des modules de synthèse et de traitements. Il peut y avoir plusieurs tracks dans un *mix_group* qui héritent du format du *mix_group* dans lequel ils sont créés.

### Crea_aux

**crea_aux** (*tracks* auxiliaires) similaire aux *tracks* précédents mais avec la possibilité d'avoir en entrée d'autres *tracks*, analogue aux pistes auxiliaires des tables de mixage ou des logiciels de type DAW pour faciliter l'organisation et la distribution des *tracks*. Un cas d'utilisation typique est celui des faire aller plusieurs *tracks* vers un *track* auxiliaire avec un module de réverbération pour utiliser la même réverbération pour tous les *tracks* qui vont vers elle, ce qui permet un contrôle général avec une seule réverbération et optimise l'usage des ressources de l'ordinateur.
<figure><img src="image_41.png" /><figcaption>**Fig. 5.4** Schéma de représentation dans la librairie AnteCollider de l'architecture imbriquée des graphes audio *scsynth*. Le « Root Node » (groupe racine avec index 0) contient le « Default Group » (index 1) qui a son tour contient les « *mix_groups* » multicanaux et HOA de la librairie. Cette architecture permet toutes les connexions audio entre les groupes et modules dans un serveur. Les sorties générales de tous les groupes vont vers un *Node* (Server Out) qui fonctionne comme un « master » de volume ou pour rajouter des traitements multicanaux génériques pour faire du *mastering* (compresseurs, réverbérations, équalisations, etc.).</figcaption></figure>
<figure><img src="image_42.png" /><figcaption>**Fig. 5.5** Schéma de représentation d'un *mix_group* multicanal et HOA dans la librairie *AnteCollider*. La librairie prend en charge la création dynamique des *tracks* à l'intérieur des *mix_groups* ainsi que les bus de communication audio. Les *tracks* sont mixés dans un bus global qui peut être utilisé pour appliquer des traitements par *mix_group* à travers des traitements intégrés dans *SuperCollider scsynth* ou des *VST* plugins multicanaux. L'utilisation d'un *mix_group* permet un contrôle global et individuel des paramètres des *tracks* et l'organisation des traitements et des synthèses par groupes : on pourra par exemple contrôler le niveau général de chaque *mix_group*, le mettre en pause ou le tuer, ce qui arrêtera tous les *tracks* qu'il contient et supprimera les processus de la chaîne de traitement audio. La partie *decoder*, à la sortie du *track* (*HOA Master Decoder*) va permettre de faire des traitements spatiaux sur tout le *mix_group HOA* comme des translations, rotations, etc.</figcaption></figure>
<figure><img src="image_43.png" /><figcaption>**Fig. 5.6** Schéma de représentation d'un *track* multicanal et HOA dans la librairie AnteCollider. La librairie prend en charge la création dynamique des modules à l'intérieur des *tracks* ainsi que les bus de communication audio. Les modules sont instanciés à la volée et leur ordre dans la chaîne audio peut être changé dynamiquement. La librairie permet aussi d'appliquer des processus de contrôle sur chaque module ou groupe de modules en temps réel. Par exemple, on pourra appliquer des modulations de paramètres à toutes les instances d'un même module, ce qui sera le cas par exemple pour la sonification des modèles physiques. Les *tracks* HOA vont encoder des enchaînements de modules pour spatialiser leur sortie et les traiter dans le domaine ambisonique. Ils peuvent aussi traiter des signaux déjà encodés comme pour la synthèse granulaire et concatenative spatiale, entre autres.</figcaption></figure>
<figure><img src="image_44.png" /><figcaption>**Fig. 5.7** Schéma de représentation d'un *track* auxiliaire multicanal et HOA dans la librairie `AnteCollider`. Comme pour les *tracks* normaux, ils permettent d'instancier des modules de traitements à la volée et d'avoir aussi en entrée d'autres *tracks*. Les *tracks* auxiliaires HOA peuvent avoir en entrée soit un *track* HOA, soit un *track* multicanal. Dans ce dernier cas, il sera encodé en format HOA pour être traité par la suite dans la chaîne HOA avec un ordre défini dans le *mix_group_HOA*. Les *tracks* auxiliaires sont très utiles aussi pour transformer des *tracks* mono ou multicanaux en *tracks* HOA, notamment pour passer de l'un à l'autre, par exemple une chaîne de synthèse qui passe d'un système standard de diffusion à un système HOA par fondu-enchaîné.</figcaption></figure>
## V.6. Exemple d'utilisation

Nous présentons dans cette section un exemple d'utilisation de la librairie `AntesCollider`, de bout en bout.

Dans une partition électronique utilisant la librairie `AntesCollider`, il est tout d'abord nécessaire d'inclure les fichiers de définition de la librairie à travers la primitive `@insert : extra_functions4_compiled.asco.txt` qui correspond aux fonctions utilisateurs compilées et `AntesCollider_lib1.asco.txt` aux objets de la librairie `AntesCollider`.

1. `@insert "inserts/extra_functions4_compiled.asco.txt"`

2. `@insert "inserts/AntesCollider_lib1.asco.txt"`

La première action consiste à instancier le ou les serveurs `SuperCollider scsynth` avec l'objet `obj::sc_server`. Cette commande va lancer les serveurs `scsynth` en tâche de fond avec des arguments par défaut ou spécifiés par l'utilisateur. Par exemple, dans les lignes suivantes, on va instancier trois serveurs et définir pour chacun la carte son `Digiface Dante (23938075)` comme matériel audio d'entrée et sortie.

13. `obj::sc_server("server1", 57110, device = "Digiface Dante (23938075)")`

14. `obj::sc_server("server2", 57111, device = "Digiface Dante (23938075)")`

15. `obj::sc_server("server3", 57112, device = "Digiface Dante (23938075)")`

<figure><img src="image_45.png" /><figcaption>**Fig. 5.8** Représentation graphique des trois serveurs `scsynth` instanciés avec les identifiants « Server1 », « Server2 », « Server3 », avec les ports OSC respectifs 57110, 57111, 57112. Avec l'instanciation d'un serveur, sont automatiquement créés le *Node « Root »* Group avec index 0 (qui contiendra tous les autres *Nodes* créés) et le *Node « Default »* Group avec index 1 (où toutes les synthèses, les traitements et les analyses seront créés).</figcaption></figure>

Une fois les serveurs lancés, on peut commencer à instancier des groupes, des synthèses, des traitements ou des analyses.

Dans les lignes suivantes, on instancie trois groupes de mixage ambisonique dans les trois serveurs existants avec un objet `mix_group_HOA`. Le premier argument est le nom du groupe, puis le serveur dans lequel ce groupe va être créé, puis le décodeur ambisonique à utiliser (dans ce cas, le décodeur binaural IEM<fnref n="108" />) et puis l'ordre ambisonique à utiliser (ordre 5 dans cet exemple). Toutes les synthèses créées dans ces

<footnote n="108">¹⁰⁸ https://plugins.iem.at/docs/plugindescriptions/#binauraldecoder</footnote>
groupes héritent de l'ordre ambisonique, dans ce cas des bus audio de 36 canaux (ordre 5) sont créés.

22 obj::mix_group_HOA("group_hoa1", "server1", "iem_binaural", 5)
23 obj::mix_group_HOA("group_hoa2", "server2", "iem_binaural", 5)
24 obj::mix_group_HOA("group_hoa3", "server3", "iem_binaural", 5)

<figure><img src="image_46.png" /><figcaption>**Fig. 5.9** Représentation graphique du code de l'instanciation des `mix_group_HOA` « group_hoa1 », « group_hoa2 » et « group_hoa3 » avec des décodeurs binauraux IEM d'ordre 5 dans les serveurs `scsynth`.</figcaption></figure>

On peut à présent créer des synthèses, des traitements ou des analyses dans les groupes de mixage de chaque serveur. On peut créer plusieurs groupes de mixage par serveur et ils peuvent aussi avoir d'autres formats que le HOA, comme mono, stéréo, multicanal, VBAP...

Dans les lignes suivantes, on crée différentes synthèses dans chaque groupe de mixage :

29 // Tracks group_hoa1
30 obj::crea_track_HOA("track_hoa1", "group_hoa1", amp = 0, doppler = 0)
31 obj::crea_track_HOA("track_hoa2", "group_hoa1", amp = 0, doppler = 0)
32
33 // Tracks group_hoa2
34 ▼ obj::crea_track_HOA("sc_track3", "group_hoa2", fade_in = 1, amp = 0,
35 ▼  [["BassSynth1", "freq", 35.9, "fmrange", 1.5, "fmfreq", 7.85, "lpf", 214., "hpf", 51.2, "rq", 0.35, "amp", -10],
36      ["TRingMod1", "modfreq", 164.4, "ampmod", 0, "lpfilt", 3822.5, "hpfilt", 50, "amp", -2.6],
37      ["TAdCVerb", "revTime", 0.3]])
38
39 // Tracks group_hoa3
40 obj::crea_track_HOA("track_orbit1", "group_hoa3", [["Impulse_Pluck", "freq", 548, "freq_imp", 10., "del", 0.006, "amp", -3]])
41 obj::crea_track_HOA("track_orbit2", "group_hoa3", [["Impulse_Pluck", "freq", 600, "freq_imp", 20, "del", 0.0005, "amp", -3]])
42 obj::crea_track_HOA("track_orbit3", "group_hoa3", [["Impulse_Pluck", "freq", 300, "freq_imp", 20, "del", 0.0005, "amp", -3]])
43 obj::crea_track_HOA("track_orbit4", "group_hoa3", [["Impulse_Pluck", "freq", 400, "freq_imp", 30, "del", 0.0002, "amp", 0]])
44
45 // Insère des modules synthèses (SynthDef) dynamiquement pour le groupe "group_hoa1"
46 $tracks("track_hoa1").mod_add(["TestSynth3", "freq", 32, "amp", -3])
47 $tracks("track_hoa1").mod_add(["TDust", "freq", 10, "amp", -1])
48 $tracks("track_hoa2").mod_add(["TAddic_20_8_modMono", preset, "psycho2"], fade_in = 5)
49 // Rajoute des VST plugins
50 $tracks("track_hoa2").mod_add(["MultiEQ"])
51 // Insère des modules à des endroits spécifiques de la chaîne
52 $tracks("track_hoa2").mod_add(["TFlanger", "flangefreq", 1.822], "before", "MultiEQ")

L'objet `crea_track_HOA` instancie des pistes HOA. Par exemple, les lignes 30 et 31 instancient deux tracks vides dans le groupe de mixage « group_hoa1 » qui est dans le serveur `Server1`. De la ligne 34 à 37, on crée un track avec une chaîne de synthèse qui commence par `"BassSynth1"` qui va vers une modulation en anneau (`TRingMod1`) qui à son tour va vers une réverbération (`TAdCVerb`) et ses paramètres d'initialisation. Les lignes 40 à 43 définissent 4 tracks avec les synthèses `"Impulse_Pluck"` avec différents paramètres. Les lignes 46 à 48 rajoutent dynamiquement les synthèses
"TestSynth3" et "TDust" dans le track "track_hoa1", la synthèse "TAddic_20_8_modMono" et un plugin VST "MultiEQ" dans le track "track_hoa2". Ces modules peuvent être placés à n'importe quelle position de la chaîne du track, par exemple à la ligne 52, on va insérer le module "TFlanger" avant le plugin VST "MultiEQ". La figure suivante illustre le graphe audio obtenu.

<figure><img src="image_47.png" /><figcaption>**Fig. 5.10** Représentation graphique du code de l'instanciation des tracks HOA "track_hoa", "track_hoa2", "sc_track3" et "track_orbit1-4".</figcaption></figure>

Une fois les modules instanciés dans les différents groupes de mixage, il est possible
de les contrôler avec différentes méthodes de l'objet crea_track_HOA. Dans le listing
ci-dessous, la méthode .set permet de changer ponctuellement les paramètres des
modules. La méthode .bpf_param utilise une NIM (breakpoint functions) pour faire
varier continûment un paramètre. Des méthodes plus spécialisées utilisant des
variations périodiques de types de LFO (comme .rand_lfo ou .brown_lfo) existent
aussi. Il est aussi possible de moduler les paramètres avec d'autres algorithmes, par
exemple des modèles physiques, à partir du suivi d'un instrument, ou encore à partir
de données issues d'une captation gestuelle.

54 // set parameter (statiques)
55 $tracks("track_hoa1").set("TestSynth3", ["freq", 40])
56 $tracks("track_hoa1").set("TestSynth3", ["amp", -3])
57 $tracks("track_hoa1").set("TestSynth3", ["fc", 2000])
58
59 // set modulation (dynamiques)
60 $tracks("track_hoa1").bpf_param("TestSynth3", "fc", [2000, 5, "exp", 20, 3, 3000, 10, "exp_out", 100])
61 $tracks("track_hoa1").rand_lfo("TDust", "freq", 1, 50, 10, "linear", 60)
62 $tracks("track_hoa2").brown_lfo("TAddic_20_8_modMono", "ampmod", 0, 30, 2, 0, "linear", 120)
63 $tracks("track_hoa2").brown_lfo("TAddic_20_8_modMono", "transp", 1.305, 1.315, 0.1, 1.31, "linear", 60)
64 $tracks("sc_track3").rand_lfo("BassSynth1", "fmrange", 1, 10, 1.5, "linear", 120)
65 $tracks("sc_track3").rand_lfo("BassSynth1", "freq", 35.3, 37.2, 35.9, "linear", 120)

Au niveau de la spatialisation des *tracks*, il y a plusieurs méthodes correspondant à
différents types d'algorithmes de trajectoires spatiales (voir en annexe les méthodes
des objets). Dans les lignes de code suivantes on a quelques exemples :
67 // Trajectoire spatiales algorithmiques
68 $tracks("track_hoal").hoa_pol_rota(10, 0.6, 0, 0, 360, 0, 1)
69 $tracks("track_hoa2").traj_lib_lissajou3D(loop_num = 20)
70 $tracks("sc_track3").ambi_random_lfo_sphere2(0.5, -120, -20, 0, 360, 0, 0, "linear", 29)
71
72 $tracks("track_orbit1").orbit_traj(0, 0.06)
73 $tracks("track_orbit2").orbit_traj(0, 0.04)
74 $tracks("track_orbit3").orbit_traj(0, 0.033)
75 $tracks("track_orbit4").orbit_traj(0, 0.01)

La ligne 68 spécifie une rotation horizontale pour spatialiser le track "track_hoal".
La ligne 69 utilise la librairie Trajectory Score Library pour le track "track_hoa2" et
la ligne 70 génère une trajectoire aléatoire autour d'une sphère pour le track
"sc_track3". Les lignes 72 à 75 définissent quatre trajectoires orbitales avec
différentes vitesses pour spatialiser les tracks "track_orbitx".

Chaque track va pouvoir être visualisé à travers une interface (GUI). On va pouvoir
appeler les interfaces avec la méthode .gui. Dans le cas des plugins VST, la méthode
 gui va ouvrir l'interface native du VST. Pour les modules réalisés à partir de
définition des synthèses (SynthDef), les interfaces seront générées dynamiquement par
le biais du langage SuperCollider slang dans l'environnement QT<fnref n="109" />. Les lignes
suivantes permettent d'ouvrir l'interface du track "track_hoal" et du plugin VST
"MultiEQ" du "track_hoa2".

77 // GUI
78 $tracks("track_hoal").gui() // ouvre l'interface graphique du track dans SC slang
79 $tracks("track_hoa2").gui("MultiEQ") // ouvre l'éditeur du plugin VST

V.7. Arguments des objets de la librairie

Les arguments fournis à l'instanciation de chaque objet définissent sa structure et son
comportement. Un objet offre aussi des méthodes pour changer son comportement une
fois qu'il est instancié. Nous détaillons ci-dessous les arguments d'instanciation des
trois principaux types d'objets fournis par la librairie AntesCollider.

La création (et les méthodes) impliquent beaucoup d'arguments. Il faut noter que
l'instanciation d'un objet et l'appel à ses méthodes peut se faire avec des arguments
nommés : l'avantage est qu'alors on peut donner les arguments « dans le désordre ».
Par ailleurs, la possibilité de définir des valeurs par défaut permet de ne pas donner
explicitement tous les arguments (si les valeurs par défaut son pertinentes). Ces deux
possibilités simplifient grandement la création et la manipulation de ces objets.

Les méthodes des objets AntesCollider sont présentés in extenso dans l'annexe de cette
thèse. Nous ne mentionnons ici que les arguments à la création.

<footnote n="109">¹⁰⁹ https://wwwqt.io</footnote>
## sc_server

Les principaux arguments du serveur scsynth dans la librairie AntesCollider reprennent les arguments d'initialisation (paramètres de la ligne de commande) correspondante du serveur scsynth.

<table><thead><tr><td>Arguments</td><td>Defaut AntesCollider</td><td>Description</td></tr></thead><tbody><tr><td>$server_name</td><td></td><td>Nom du Server SC scsynth dans le dictionnaire (MAP) $Servers dans AntesCollider</td></tr><tr><td>$port</td><td></td><td>Un numéro du port OSC de communication entre Antescofo (le client) et le serveur scsynth. Numéro compris entre 0 et 65 535</td></tr><tr><td>$audio_bus</td><td>20 000</td><td>Nombre maximum de bus audio</td></tr><tr><td>$inputs</td><td>24</td><td>Nombre d'entrées physiques (dépend de l'interface audio utilisée)</td></tr><tr><td>$outputs</td><td>24</td><td>Nombre de sorties physiques (dépend de l'interface audio utilisée)</td></tr><tr><td>$sr</td><td>48 000</td><td>Le taux d'échantillonnage (sampling rate) préféré. Si elle n'est pas définie, l'application serveur tentera de définir le taux d'échantillonnage de l'interface audio</td></tr><tr><td>$device</td><td>"Built-in Microph"</td><td>Nom de l'interface audio à utiliser par le serveur SC scsynth. Si scsynth ne trouve pas l'interface définie, il utilisera celle par défaut du système d'exploitation</td></tr><tr><td>$block_size</td><td>64</td><td>Nombre d'échantillons à calculer dans une période de contrôle</td></tr><tr><td>$num_buffers</td><td>8 192</td><td>Nombre maximum de buffers (tampons d'échantillons) audio à utiliser</td></tr><tr><td>$max_num_synth_defs</td><td>4 096</td><td>Nombre maximum de synth_defs à charger lors du lancement du serveur scsynth.</td></tr><tr><td>$max_Nodes</td><td>16 384</td><td>Nombre maximum de Nodes (groupes et Synth) de l'arborescence</td></tr><tr><td>$memSize</td><td>20 97 152</td><td>Le nombre de kilo-octets de mémoire en temps réel alloués au serveur. Cette mémoire est utilisée pour allouer les synthèses et toute mémoire que les UGens eux-mêmes allouent</td></tr></tbody></table>
<table><thead><tr><td>Arguments</td><td>Defaut AntesCollider</td><td>Description</td></tr></thead><tbody><tr><td>$numWireBufs</td><td>256</td><td>Le nombre maximum de tampons (buffers) qui sont alloués pour interconnecter les UGens (à ne pas confondre avec les buffers audio ou tampons d'échantillons globaux). Cela fixe la limite de la complexité des SynthDefs qui peuvent être chargés au moment de l'exécution.</td></tr><tr><td>$max_logins</td><td>8</td><td>Un nombre entier indiquant le nombre maximum de clients qui peuvent recevoir simultanément des notifications du serveur.</td></tr></tbody></table>

## Arguments des mix_group

<table><thead><tr><td>Arguments</td><td>Default</td><td>Description</td></tr></thead><tbody><tr><td>$group_name</td><td></td><td>Nom du groupe multicanal dans le dictionnaire (MAP) $Groups dans AntesCollider</td></tr><tr><td>$server_name</td><td></td><td>Nom du server scsynth dans lequel le groupe va être instancié</td></tr><tr><td>$num bidirectional</td><td>8</td><td>Nombre des canaux audio du groupe</td></tr><tr><td>$out_offset</td><td>0</td><td>Décalage de tous les bus audio de sortie</td></tr><tr><td>$pan</td><td>false</td><td>Type de système de panoramique à utiliser (Panning, VBAP, DBAP)</td></tr><tr><td>$destination</td><td>&lt;undef&gt;</td><td>Permet d'envoyer les bus de sortie audio du groupe multicanal vers un groupe mix_group_HOA pour passer de l'un à l'autre (par exemple du stéréo vers HOA et/ou vice versa)</td></tr><tr><td>$pan_init</td><td>-1</td><td>Initialisation de la position spatiale « panning » du groupe</td></tr></tbody></table>

## Arguments des mix_group_HOA

<table><thead><tr><td>Arguments</td><td>Default</td><td>Description</td></tr></thead><tbody><tr><td>$group_name</td><td></td><td>Nom du groupe multicanal dans le dictionnaire (MAP) $Groups dans AntesCollider</td></tr><tr><td>$server_name</td><td></td><td>Nom du server scsynth dans lequel le groupe va être instancié</td></tr></tbody></table>
<table><thead><tr><td>Arguments</td><td>Default</td><td>Description</td></tr></thead><tbody><tr><td>$decoder</td><td></td><td>Nom du décoder à utiliser, par exemple « studio1 » qui correspond à la configuration du Studio 1 de l'Ircam</td></tr><tr><td>$order</td><td></td><td>Ordre Ambisonic à utiliser de 1 à 5 pour la librairie SC-HOA qui est utilisée dans AntesCollider</td></tr><tr><td>$lev_name</td><td>"hrir_christophe_lebedev50"</td><td>Nom du filtre HRIR pour un rendu ambisonique pour écouter sur casque</td></tr></tbody></table>

## Argument des crea_track

<table><thead><tr><td>Arguments</td><td>Default</td><td>Description</td></tr></thead><tbody><tr><td>$track_name</td><td></td><td>Nom du track dans le dictionnaire (MAP) $tracks dans AntesCollider</td></tr><tr><td>$mix_group</td><td></td><td>Nom du mix_group dans lequel le track sera créé</td></tr><tr><td>$synth_collection</td><td>[ ]</td><td>Tableau de synthèses et traitements dans l'ordre d'apparition, le premier sera la plus haut dans la chaîne audio</td></tr><tr><td>$fade_in</td><td>0.01</td><td>Durée en temps relatif de la rampe d'entrée fade in</td></tr><tr><td>$amp</td><td>0</td><td>Amplitude générale du track en dB</td></tr><tr><td>$numInputs</td><td>1</td><td>Nombre de canaux en entrée</td></tr></tbody></table>

## Argument des crea_track_HOA

<table><thead><tr><td>Arguments</td><td>Default</td><td>Description</td></tr></thead><tbody><tr><td>$track_name</td><td></td><td>Nom du track dans le dictionnaire (MAP) $tracks dans AntesCollider</td></tr><tr><td>$mix_group</td><td></td><td>Nom du mix_group dans lequel le track sera créé</td></tr><tr><td>$synth_collection</td><td></td><td>Tableau de synthèses et traitements dans l'ordre d'apparition, le premier sera la plus haut dans la chaîne audio</td></tr></tbody></table>
## V.9. La visualisation graphique et le contrôle interactif des chaînes de traitements audio

Les interfaces graphiques (GUI) sont aujourd'hui indispensables dans la plupart des logiciels musicaux, elles permettent à l'utilisateur de représenter et de contrôler facilement et ergonomiquement les éléments de l'électronique. Elles permettent aussi de naviguer simplement et efficacement dans les paramètres de l'électronique pour intégrer ensuite les résultats de ces expérimentations à l'écriture de l'électronique.

La librairie AntesCollider crée et gère ces interfaces graphiques mais délègue leur réalisation au langage SuperCollider sclang (qui sert ici de couche graphique). L'idée, en accord avec le caractère dynamique des traitements, est de créer les interfaces graphiques à la volée, quand elles sont nécessaires. La création dynamique de l'interface se fera surtout pendant le processus de composition et d'expérimentation dans le but d'explorer les paramètres des traitements et pour les enregistrer en tant que préréglages (presets) ou encore, comme dans les DAW, pour créer des mouvements continus à travers des fonctions (breakpoint fonctions ou NIMs dans le langage Antescofo). Cette approche dynamique permet d'optimiser les ressources du fait que les interfaces ne seront créées que si nécessaire et ne seront pas incluses implicitement dans le programme comme c'est souvent le cas dans des patchs de concert réalisés avec Max ou Pd.

Les interfaces graphiques créées et contrôlées depuis AntesCollider reposent sur le schéma MVC (Model-View-Controller) :

* Le modèle (Model) correspond aux constructions de la librairie et à leur miroir dans le serveur scsynth. C'est par exemple un nombre flottant utilisé pour représenter une fréquence.

* La vue (View) se réfère à l'objet graphique (GUI) qui représente le modèle pour l'utilisateur.

* Le Controller permet de lier une ou plusieurs vues à un modèle. Il permet d'informer le modèle d'un changement via l'interface graphique et inversement, de notifier les interfaces graphiques d'une mise à jour du modèle.

Le schéma MVC permet d'avoir plusieurs vues et contrôles attachés à un seul modèle, ce qui permet de partager les visualisations des mêmes objets depuis plusieurs instances et différentes vues des interfaces graphiques. Par exemple, si un utilisateur utilise un slider pour modifier un paramètre spécifique d'une synthèse, le modèle va être mis à jour et les contrôleurs du paramètre informeront toutes les instances graphiques de cette synthèse du changement, ce qui permettra de refléter les changements dans toutes les interfaces graphiques qui réfèrent à ce paramètre. Cette fonctionnalité est très importante puisqu'on peut avoir dans la librairie plusieurs façons de visualiser l'état des paramètres des traitements.

La figure ci-dessous est une copie d'écran d'une interface créée dynamiquement pour contrôler un module de synthèse additive.
Le code slang qui permet de créer cette interface est donné après la figure. Il illustre
la définition d'une interface graphique dans le langage slang pour contrôler
graphiquement la synthèse SynthDef "TAddic_20_8_mod" (un module de synthèse
additive avec 20 x 3 partiels avec modulation d'amplitude par partiel). L'objet
TAddic_20_8_mod hérite de la classe Tmodule2 pour la création automatique des
interfaces et leur intégration au système. La méthode metadata de cet objet (lignes 44
à 79) décrit tous les éléments graphiques comme les sliders, les multisliders, les
boutons..., ainsi que leur mapping (définie par l'objet ControlSpec) pour déterminer
les limites, les pas, la valeur initiale, le type de variations (CurveWarp, linéaire,
exponentiel...) et l'unité (dB, Hz...).

<figure><img src="image_48.png" /><figcaption>**Fig. 5.11** Interface créée automatiquement et dynamiquement à partir de la description d'interface de la méthode metadata. Toutes les interfaces héritent d'un même objet qui va permettre de les organiser spatialement et d'avoir les possibilités de créer des presets, de faire des interpolations de presets, de moduler les paramètres de façon aléatoire, de mettre le module en solo ou mute...</figcaption></figure>
```csharp
1 TAddic_20_8_mod: Tmodule2 {
2
3 classvar n = 20; //numero de componentes
4 //: TEffectModule
5 *def
6 {
7     ^SynthDef(\TAddic_20_8_mod, [out = -1, outbus = -2, transp = 1.0, amp = 0, d = 0, shift = 0, distor = 0, Ifnoise Cele = 0, lag = 1, ampmod = 0, gate = 1, free
8              = 1, matrix ramp = 0.01, width = 2, orientation = 0, lag spat = 0.2]
8
9     var freqs, amps, pos, sig, fqs, conca, len, lista, distarray, offset, envgate, envpause;
10
11     envgate = EnvGen.kr(Env.asr(matrix ramp, 1.0, matrix ramp, welch), free, doneAction:2);
12     envpause = EnvGen.kr(Env.asr(matrix ramp, 1.0, matrix ramp, welch), gate, doneAction:1);
13     //offset = Line.kr(0, -0.02, 60);
14     distarray = Array series(20, 1);
15     freqs = \freqs.kr(Arra fill(20, {[40 + 75. rand) * (0.50. midiratio),(40 + 75. rand)].choose.mericps}});
16     amps = \amps.kr(Arra fill(20, { 0.02 + 0.07. rand }));
17     pos = \pos.kr((Array series(20, 0)* (2/20)));
18     sig = Mix. fill(20*3, { |i|
19         var ampc;
20         ampc = AmpCompA.krfreqs. wrapAt(i));
21
22     PanAz.ar(8, SinOsc.ar(Lag.kr((freqs. wrapAt(i)*transp) + (Rand(-2.0, 2.0) * d + shift) * (distarray. wrapAt(i) ** distor), (0.5 + 2.0. rand)*lag), 0,
23              Lag.kr(amps. wrapAt(i), ((0.5 + 2.0. rand)*lag)) * SinOsc.ar(ampmod, 0, 0.5, 1) * max(0, LFDNoise3.kr(Ifnoise Cele, 1.0))), Lag.kr(pos. wrapAt(i), lag spat), 1,
24              width, orientation) * ampc;
25     );
26
27     fqs = (freqs*transp+shift) * (distarray ** distor);
28     conca = [fqs, amps].flop;
29     len = conca.size*2;
30     lista = conca. reshape(len);
31     SendReply.kr(Impulse.kr(30, 'mi-list'. Lag.kr(lista, lag));
32
33     sig = 0.25 * sig * envgate * envpause;
34     Out.ar(out, sig*amp.dbamp.lag(1));
35   }.
36 }
37
// TAddic_20_8_mod.def
38
39 *metadata
40 {
41     ^{metadata:
42         synthdefname: "TAddic_20_8_mod",
43         type: \gen,
44         main: \transp,
45         sliders:
46             \transp -> ControlSpec(0.001, 5, \lin, 0.001, 1, \transp),
47             \amp -> ControlSpec(0.ampdb, 2.ampdb, \db, 0, 0, \dB),
48             \d -> ControlSpec(0, 200, \lin, 0.1, 0, \desv),
49             \shift -> ControlSpec(-1200, 1200, \lin, 0, 0, \shift),
50             \distor -> ControlSpec(-2, 2, \lin, 0.001, 0, \distor),
51             \ifnoise Cele -> ControlSpec(0, 20, \lin, 0.001, 0, \famp),
52             \ampmod -> ControlSpec(0, 20, \lin, 0.001, 0.001, \ampmod),
53             \lag -> ControlSpec(0.001, 10, \lin, 0.001, 1, \lag),
54             \width -> ControlSpec(0, 8, \lin, 0.001, 2, \width),
55             \lag spat -> ControlSpec(0.001, 10, \lin, 0.001, 0.2, \lag spat)
56         },
57         multisliders:
58             \freqs -> [ControlSpec(20, 10000, \exp, 0.01, 20, \freqs), n],
59             \amps -> [ControlSpec(0, 2, \amp, 0.01, 0.02), n],
60             \pos -> [ControlSpec(0.0001, 2, \lin, 0, 0.3, \vol), n]
61         ],
62         buttons: [//<\que controla>, <parametro>, <action (funcion, listas, elementos,etc)>
63             \osc -> [osc, n],
64             \freqs -> [multisliders, \freqs,
65                 var freq_min = 40, freq_max = 75; //en midi quart de ton
66                 [(freq_min + freq_max. rand) * (0.50. midiratio),(freq_min + freq_max. rand)].choose.mericps], n],
67                 \amps -> [multisliders, \amps,{ rrand(0.0, 2.0) }], n],
68                 \pos -> [multisliders, \pos, { rrand(0.0, 2.0) }], n],
69                 \pos rt -> [multisliders, \pos, Array. series(n, 0)* (2/n)],
70                 \fq sr -> [multisliders, \freqs, Array. series(n, 1).Jinlin(1, n, 20, 10000)]
71             ]
72         ])
73     )
74 }
75
```

<caption>Fig. 5.12 Exemple de la description d'une interface graphique dans le langage SuperCollider (cf. texte).</caption>
## V.10. Le visualisateur antescollider_spatial_interface

En complément à la librairie AntesCollider, j’ai aussi développé au cours de ce travail de thèse une interface graphique pour visualiser les mouvements des sons dans l’espace générés algorithmiquement à partir du langage Antescofo ou pour visualiser les résultats des modèles physiques que j’utilise pour le contrôle de différentes synthèses sous AntesCollider.

Cette interface appelée antescollider_spatial_interface permet la visualisation des mouvements des sources ou des masses sonores comme la synthèse granulaire et concatenative spatiale. Le logiciel, programmé en C++ utilise la couche openFrameworks pour la création d’images et de vidéos en temps réel. Les données sont transmises par Antescofo à l’interface en utilisant le protocole OSC.

Ce visualisateur permet aussi quelques interactions utilisateurs permettant de contrôler dynamiquement depuis l’interface les processus de synthèses spatiales en envoyant des messages OSC ad hoc directement au langage Antescofo.

Ce visualisateur propose différents modes de visualisation des données reçues :

* **trajectories** : pour visualiser des trajectoires réalisées algorithmiquement dans AnteCollider ;

* **grains** : pour visualiser différentes couches de synthèses granulaires. Chaque couche peut avoir une couleur déterminée. Seulement la position et la durée du grain sont affichées. Dans le futur, on pourrait aussi imaginer une visualisation avec d'autres caractéristiques du son comme le centroid, la loudness, etc. ainsi que d'autres interactions pour l'expérimentation et le jeu en live ;

* **tmolecules** : pour visualiser des modèles physiques particulaires dans l'espace (jusqu'à plusieurs centaines de particules) ;

* **list3D** : pour visualiser une liste construite avec des position en x, y et z. La taille de la liste peut varier dynamiquement.

* **concat3D** : pour visualiser et contrôler des têtes de lectures spatiales dans un système de synthèse concatenative en 3D.
<figure><img src="image_49.png" /><figcaption>**Fig. 5.13** Capture d'écran du logiciel *antescollider_spatial_interface* pour la visualisation en 3D des mouvements spatiaux.</figcaption></figure>

## V.11. Œuvres réalisées avec AntesCollider

La librairie AntesCollider a été validée à travers plusieurs de mes créations réalisées pendant ce travail de thèse et par la réalisation de l'électronique de pièces écrites par un autre compositeur :

* *Dispersion de trajectoires*, pour saxophone baryton et électronique.

* *Estremo d'ombra*, pour flûte, saxophones, trombone, alto, contrebasse et électronique (composition de Lara Morciano).

* *Hypersphères*, Projet GeKiPe (HEM de Genève) pour un performeur, captation gestuelle et vidéo générée en temps réel.

* *Homotopy*, pour percussions, captation gestuelle et électronique.

* *Philiris*, pour piano, captation gestuelle et électronique (composition de Lara Morciano).

* *Taygeta*, pour percussions transducteurs et captation gestuelle (composition de Lara Morciano).

* *La curvatura del cristal encantado*, œuvre électroacoustique 16 pistes.

* *Lyphira*, pour piano, transducteurs et captation gestuelle (composition de Lara Morciano).

* *Curvatura II*, œuvre électroacoustique en HOA, entièrement écrite dans le langage Antescofo.

* *Las Pintas*, audiovisuel en temps réel et en HOA.

Certaines de ces pièces seront détaillées dans les chapitres suivants.
J'ai aussi présenté AntesCollider à ICMC 2019 dans l'article « AntesCollider: control and signal processing in the same score » [FEGIDO19] qui a obtenu le **ICMA Audience Award for Best Paper Presentation**.

## V.12. Futurs développements

### Développements à court terme

À court terme, le développement de la librairie AntesCollider vise à intégrer complètement tous les éléments du traitement du signal dans la partition électronique.

Concrètement, cela implique de permettre la spécification des définitions de synthèse SynthDef pour la création des synthétiseurs, traitements et analyses audio directement dans Antescofo. Pour l'instant, les définitions de synthèse se font dans le langage SuperCollider slang et non pas directement dans la partition électronique Antescofo. En effet, les définitions des synthèses peuvent être envoyées directement depuis le client vers les serveurs SuperCollider via OSC en format binaire.

Une autre fonctionnalité utile (qui s'appuierait sur la précédente) serait d'intégrer les possibilités de la librairie JIT pour créer et modifier des graphes audio dynamiquement en *live coding*. On pourrait ainsi explorer et prototyper facilement différents types de synthèses sans devoir les précompiler à l'avance.

Une autre intégration sera aussi d'exploiter les possibilités de rendu *off-line* (Non-Real-Time) de scsynth pour faire de la synthèse avec précision à l'échantillon (*sample-accurate*). Ce type de rendu est utilisé aussi quand le processeur de l'ordinateur n'arrive pas à calculer le son en temps réel, comme des rendus complexes de spatialisation d'ordre HOA élevé avec des réverbérations par convolutions multicaionales ou pour la création de synthèses audio algorithmiquement par échantillons (par exemple à partir de modèles physiques complexes, d'algorithmes stochastiques, de méthodes d'apprentissages ou de résolutions de contraintes, etc.). La flexibilité au niveau temporel du langage Antescofo devrait permettre de réaliser des séquences complexes avec une grande qualité sonore. Cette intégration pourrait aussi être utilisée pour faire de la CAO avec du traitement par lots (*batch processing*) pour la génération des matériaux électroacoustiques algorithmiquement ou à partir des descriptions de plus haut niveau comme des NIM, etc.

Au niveau de l'édition d'une partition Antescofo, l'intégration de fonctionnalités comme l'auto-complétion des fonctions, processus et objets qui listerait au vol les arguments de ces entités, serait très utile. Ces fonctionnalités permettraient de faciliter l'apprentissage du langage. Elles sont nécessaires pour faciliter l'utilisation des grandes librairies qui proposent de nombreuses entités.

### Développements à moyen terme

Le visualisateur antescollider_spatial_interface continuera à être développé en intégrant de nouvelles fonctionnalités. Ce visualisateur devrait évoluer pour devenir un
véritable serveur vidéo/visuel permettant la visualisation dynamique des données (comme c'est le cas actuellement) mais aussi la création des interfaces graphiques dynamiques (dont la réalisation graphique est prise en charge aujourd'hui par slang).

Concernant Antescofo et son langage, il y a plusieurs développements possibles qui seraient particulièrement utiles comme l'intégration d'analyses audio et gestuelles directement dans le langage aussi bien en temps réel que différé (off-line).

Il serait commode d'intégrer différents types d'analyse et de calcul de descripteurs. Ces descripteurs pourraient être directement associés à différents types de traitements grâce aux dictionnaires, sans devoir passer par des logiciels ou des librairies externes comme c'est le cas aujourd'hui. L'intégration de ces analyses permettrait par exemple de piloter des synthèses par descripteurs comme la synthèse concatenative ou de construire des recompositions morphologiques à partir d'analyses en temps réel ou différé avec des technique de machine learning par exemple.

Au niveau du suivi de partition, une fonctionnalité importante serait d'étendre la machine d'écoute afin de permettre la reconnaissance de sons autres que harmoniques (notes). La perspective de faire du suivi de modes de jeux particuliers (pour les instruments acoustiques) ou d'autres sons non harmoniques (par exemple des sons environnementaux) est particulièrement attractive pour les compositeurs mais pose toujours des problèmes complexes de recherche. Une approche polyphonique du suivi (avec un suivi en parallèle de plusieurs instruments), bien que très difficile à mettre en place, peut être une piste intéressante à développer aussi dans le futur. L'intégration du suivi de geste (ou autres types de données) dans Antescofo est aussi un champ à explorer, cette technique a déjà été expérimentée en interaction avec le Gesture Follower [BZS+10] de l'équipe ISMM<fnref n="110" /> de l'Ircam dans l'environnement Max en couplage avec Antescofo [Lem19], technique qui sera utilisée dans une pièce pour ensemble et électronique qui sera créée en 2022.

Au niveau graphique, après le travail sur Ascograph qui a été abandonné et l'intégration de l'éditeur Vezér pour l'édition des courbes, différentes pistes sont en cours d'exploration comme une visualisation ou rendu visuel de l'écriture de la partition électronique dans un navigateur ou dans des environnements comme *bach*. Un des avantages de Ascograph était qu'on pouvait modifier la partition électronique directement via l'interface graphique, notamment les courbes. Cette fonctionnalité devrait être étendue à tous les paramètres. La multidimensionnalité que peuvent exhiber des partitions électroniques complexes (par exemple *Curvatura II*), avec des superpositions temporelles et procédurales, présente un grand défi pour la visualisation et l'écriture de l'électronique.

<footnote n="110">¹¹⁰ https://www.ircam.fr/recherche/equipes-recherche/ismm/</footnote>
Un travail d'intégration des partitions Antescofo avec le logiciel iAnalyse<fnref n="111" /> développé par Pierre Couprie pour l'analyse des pièces interactives en temps réel dans un but musicologique et compositionnel est aussi une perspective très prometteuse.

Développements à plus long terme

Durant ce travail de thèse et en relation avec la création des outils présentés ici pour la
composition et l'interaction en temps réel, j'ai plusieurs fois réfléchi à un
environnement « idéal » (tout au moins pour moi) en tenant compte des possibilités de
l'informatique musicale d'aujourd'hui, de la modularité et du caractère dynamique
nécessaire au travail d'expérimentation et au travail d'écriture, dans le contexte de la
partition électronique centralisée.

La librairie AntesCollider qui permet de créer un pont entre Antescofo et SuperCollider est un premier pas vers un tel environnement. C'est aussi un point de départ pour prototyper et expérimenter de nouveaux outils dynamiques de création, porteurs de nouvelles idées techniques et musicales.

Une dimension importante de cet environnement idéal est l'extensibilité et
l'adaptabilité à différents projets de recherche en composition et interprétation de
l'électronique. La possibilité d'étendre l'environnement pour intégrer des techniques
émergentes comme celles issues de l'intelligence artificielle ou pour incorporer de
nouvelles techniques de composition, de synthèse, de traitement et de spatialisation
sonore, est une caractéristique qui permettrait de pérenniser les développements en
assurant la pertinence de l'approche au cours du temps. Comme Max, qui s'appuie sur
la programmation visuelle par patch, cet environnement idéal devrait pouvoir s'adapter
à différents utilisateurs, chercheurs, développeurs, compositeurs/musiciens et artistes,
et à différents niveaux d'expertise, des débutants jusqu'aux utilisateurs experts.

Une approche possible pour ce faire, est d'associer une représentation visuelle des
programmes à la représentation textuelle, avec la possibilité de basculer d'une
représentation à une autre. C'est l'approche adoptée pour les objets Max gen~ et
CodeBox<sup>112</sup>. Cette double représentation devrait permettre l'expression graphique des
chaînes de traitements et graphes audio, représentation plus naturelle et intuitive pour
les utilisateurs non experts, et simultanément la représentation textuelle qui permet de
spécifier des synthèses plus élaborées difficilement représentables manuellement dans
des systèmes de type *block-diagram* (par exemple des filtres récursifs).

On pourrait ainsi réaliser un système de partitions centralisées où même les éléments
de très bas niveau comme les *Unit Generators* (unités de génération, analyse et
traitement audio souvent écrites en C/C++) ou des librairies entières (par exemple une
librairie HOA pour la spatialisation) pourraient être inclus en tant qu'objets compilés.
Ceux-ci pourraient être représentés aussi bien en code et/ou patch que dans un langage
de bas niveau tel que C/C++. Tous ces éléments devraient aussi être disponibles en tant

<footnote n="111">¹¹¹ Pierre Couprie, http://logiciels.pierrecouprie.fr</footnote>

<footnote n="112">¹¹² https://cycling74.com/tutorials/gen~--for-beginners-part-5-the-codebox-operator</footnote>
que logiciel libre (open source) puisque les codes sources devraient aussi faire partie
de cette partition globale en tant que inserts exportables et compilés pour n'importe
quel système d'exploitation.

<figure><img src="image_50.png" /><figcaption>**Fig. 5.14** Diagramme d'un système modulaire intégré. Au centre, la partition électronique centralisée qui contrôle et communique avec l'ensemble des éléments.</figcaption></figure>
# VI. Paradigmes compositionnels

> « Il ne faut pas oublier que la division de l'octave en douze demi-tons est purement arbitraire. Il n'y a aucune raison de continuer à tolérer cette restriction. Tout comme le peintre peut créer des couleurs et varier leur intensité, le musicien peut également obtenir des vibrations sonores qui ne correspondent pas nécessairement aux tons et aux demi-tons traditionnels, mais qui varient, en fin de compte, d'un son à l'autre. Nous ne pourrons vraiment explorer l'art du son (c'est-à-dire la musique) que si nous avons des moyens d'expression entièrement nouveaux. Oublions immédiatement le piano et les restrictions mécaniques arbitraires qu'il nous impose et ne voyons pas cela comme une proposition iconoclaste. » [Var83]

Ce chapitre a un statut un peu particulier. Il ne vise pas à présenter un travail effectué pendant cette thèse ou bien à défendre et à argumenter une idée en lien avec mon travail. Son but est de présenter quelques éléments biographiques, évoquer certaines positions artistiques qui me sont propres, et mettre en avant certaines problématiques musicales qui me préoccupent plus particulièrement. L'objectif est de mettre en contexte les créations présentées dans les chapitres suivants.

## VI.I. Quelques éléments biographiques

Ma pensée musicale s'est forgée au fil des années par des études classiques qui ont commencé par le piano puis, à l'université du Chili, se sont complétées par des études générales (contrepoint, harmonie...) et par la composition.

C'est ensuite au LIMP (Laboratoire de recherche et production musicale), à Buenos Aires en Argentine, que j'ai commencé à approfondir la programmation informatique, notamment avec le langage LISP.

Après ces riches expériences, je suis venu en France étudier la composition instrumentale et mixte au CNSMD de Lyon, dans le département de composition anciennement appelé SONVS, où la programmation faisait partie intégrante du cursus, notamment dans le cadre des cours de Denis Lorrain et de Robert Pascal.

À la fin des études au CNSMD, j'ai participé au cursus de composition de l'Ircam. Il s'agit d'une année intense sur l'apprentissage de différents logiciels et techniques développés à l'Ircam, aboutissant à une pièce pour un instrument soliste et électronique en temps réel en fin du cursus.
## La fabrication du son

Pendant toutes ces années de formation, mon intérêt pour les nouvelles technologies, en particulier la programmation, s'est développé progressivement. Cet intérêt s'est accompagné d'une réflexion sur la création des formes et techniques compositionnelles permettant une plus grande souplesse entre la pensée musicale et sa concrétisation sonore. Le son, comme pour beaucoup de compositeurs de la seconde moitié du XXe siècle, est devenu primordial et sa création, à travers l'expérimentation technologique et son écriture fine, est aussi devenue un acte quotidien et naturel au même titre que l'écriture de notes sur une partition.

Le monde de la synthèse sonore par ordinateur s'est ouvert à moi assez tôt et j'ai tout de suite commencé à expérimenter le mélange des sons de synthèse et des sons instrumentaux pour faire émerger une musique unique et une sonorité globale. Dès mes premières compositions mixtes, mon travail s'est focalisé sur la recherche de mélanges composites avec la composition simultanée des deux parties – l'instrumental et l'électronique – même lorsque cela implique la confrontation d'éléments très hétérogènes. Dans ce cas, aucune des deux parties ne doit avoir de rôle prépondérant : chacune a ses propres moyens et va contribuer à l'expérience musicale. De même, la virtuosité de chaque partie va être comparable dans la limite des possibilités techniques et perceptives. Chacune jouera avec son potentiel. Par exemple, un instrument ne pourra pas jouer des *ribatutti* aussi vite qu'un ordinateur, et un ordinateur ne pourra pas jouer avec les subtilités et les richesses interprétatives d'un instrumentiste professionnel (du moins avec les technologies actuelles).

Avec l'intégration des nouvelles technologies, l'espace sonore dans tous ses paramètres s'ouvre à une granularité beaucoup plus fine des rythmes et des hauteur. De plus, l'électronique permet de composer l'espace avec une souplesse, une flexibilité et des possibilités inatteignables avec les instruments acoustiques. Les sons de synthèse permettent la création de sons inouïs, par exemple sans une temporalité définie, ils peuvent jouer sans s'arrêter, se métamorphoser, suivre des trajectoires spatiales, créer des masses sonores, être étirés ou raccourcis, etc.

L'électronique, et plus particulièrement l'informatique musicale, peut être considérée comme un instrument élargi et multitâche qui va permettre de créer et transformer des sons ainsi qu'interagir avec le monde externe – instruments, médias, environnement, etc. – à travers des capteurs – microphones, capteurs gestuels, capteurs physiques, physiologiques, etc. Par ses possibilités étendues, l'électronique des musiques mixtes vient renouveler l'écriture et apporter de nouvelles idées musicales en élargissant l'univers des timbres et des morphologies sonores. La composition avec ces nouveaux instruments doit tenir compte de toutes les interactions possibles et trouver les meilleures stratégies pour les formaliser et les implémenter, aussi bien dans le cadre de la musique écrite que dans celui des musiques improvisées ou d'autres formes comme les installations sonores.

Par ailleurs, le monde instrumental acoustique porte l'aspect interprétatif, vivant et interactif du moment présent, en apportant la richesse des sonorités et une projection
du son bien différente et bien plus subtile que celle offerte par des haut-parleurs. De même, les techniques instrumentales ont évolué et l'introduction de nouveaux modes de jeux a étendu les sonorités des instruments acoustiques.

Les deux mondes interagissent pour faire émerger une musique où la relation entre l'humain et la machine est forte et interdépendante.

## L'impact des courants musicaux

Différents courants musicaux se sont développés au cours du XXe siècle et on a assisté à une multitude d'expérimentations aussi bien au niveau formel (par exemple avec l'introduction du hasard, de formes ouvertes ou encore de la génération algorithmique) qu'au niveau sonore. Les compositeurs d'aujourd'hui sont confrontés à toutes ces nouvelles techniques tout en étant liés à la pensée musicale élaborée durant l'histoire de la musique occidentale. Dans mon cas, je me sers de toutes les idées qui pourront m'aider à créer ma musique, à lui donner sa liberté et son expressivité.

Dans cette histoire de la pensée musicale, la musique spectrale m'a particulièrement influencé en contribuant fortement à la libération des techniques et par son approche de différents processus combinatoires ou aléatoires. Comme indiqué par Grisey, la musique se nourrit de toute la palette des sons, depuis des superpositions temporelles extrêmement complexes jusqu'à des situations d'une simplicité absolue comme une sinusoïde ou un silence dans une transformation continue. Et c'est un des avantages de notre époque que de pouvoir faire face à cette richesse sonore avec une grande liberté pour créer sa musique : les règles et contraintes au niveau compositionnel sont données par le compositeur lui-même et chacun peut s'exprimer et expérimenter comme il le souhaite, avec les moyens qu'il a à disposition. De plus, nous avons des outils de plus en plus performants et versatile qui nous permettent de donner à la musique une grande variété et une grande latitude dans les approches, nous assurant des conditions d'une liberté encore jamais atteinte dans l'histoire de la musique.
<figure><img src="image_51.png" /></figure>

**Fig. 6.1** Schéma de représentation de différents éléments techniques dont dispose un compositeur aujourd'hui pour créer la musique et le son. Ce schéma de composition délimite trois catégories : la composition instrumentale incluant ses traditions, la composition électroacoustique et la composition des musiques interactives ou mixtes.

## VI.2. Une liberté issue de la diversité et de la plasticité musicale

« Je rêve les instruments obéissant à la pensée et qui, avec l'apport d'une floraison de timbres insoupçonnés, se prêtent aux combinaisons qu'il me plaira de leur imposer et se plient à l'exigence de mon rythme intérieur », The Liberation of Sound, Edgar Varèse [Var66].

### « Une inépuisable diversité » comme déterminant de ma poïétique

Comme je l'ai déjà évoqué, je pense que nous avons la chance incroyable à notre époque de pouvoir accéder à un nombre presque illimité de musiques. Il suffit de parcourir les catalogues des plateformes dédiées à l'écoute musicale ou de visiter différents sites de radios sur Internet pour être sidéré par la quantité et la diversité des styles proposés. Ils ne représentent pourtant qu'une faible partie de toutes les musiques existantes. Bien entendu, à l'échelle humaine, nous ne disposons pas du temps nécessaire pour écouter toutes ces musiques : par exemple, Spotify<fnref n="113" /> dispose d'un catalogue de plus de 60 millions de titres. Nous avons donc le choix d'aller explorer

<footnote n="113">¹¹³ https://www.spotify.com</footnote>
différentes musiques et styles musicaux selon nos envies ou nos recherches personnelles, sans jamais les épuiser. Et de fait, nous pouvons découvrir et écouter comment la musique s'exprime de différentes façons, pour différents types de personnes et à différentes occasions, que ce soit pour un événement religieux ou festif, pour un ascenseur, pour de jeunes occidentaux qui font la fête ou pour un rituel sacré d'une tribu en Amazonie, etc. La musique fait partie intégrante de l'être humain et « s'adapte » à son auditeur (et vice versa). Elle prend des formes variées et multiples en fonction du créateur ou de l'auditeur, elle deviendra pour chacun « sa musique ». On peut dire que « la perception de la musique est cognitive et culturelle » [Lev13].

Dans ma démarche compositionnelle, cette diversité de formes, de contenus et d'attendus constitue ma poïétique fondamentale. Ma liberté musicale est le produit de cette plasticité, et plus particulièrement de l'articulation de cette plasticité et du devenir du son et de « sa transformation continuelle d'énergie » [Gri08]. Elle me permet de tenter de dépasser les catégories culturelles et structurelles préétablies même si je suis bien conscient que nous sommes des êtres forgés par notre réalité culturelle, environnementale et notre espace de croyances.

Ma démarche compositionnelle ne s'appuie pas sur l'utilisation de musiques existantes, mais sur la possibilité d'accéder à cette diversité de sonorités instrumentales, mécaniques, électriques, numériques, algorithmiques, chaotiques ou statiques. Ma recherche musicale et créatrice s'en inspire et se l'approprie. Je peux alors laisser la musique s'exprimer et voyager librement dans mon imaginaire, mon écoute intérieure, sans « trop » de contraintes. Il devient théoriquement possible d'utiliser toute la palette des sons et combinaisons au niveau des timbres, des structures, des morphologies et des espaces qui existent et qui sont mis à ma disposition par les nouveaux outils technologiques.

## Un déploiement entre écoute et possibilités techniques

S'instaure ainsi un double jeu entre d'une part la perception et l'écoute, et d'autre part les possibilités techniques actuelles et tout l'héritage musical : un double jeu qui est au service de ma liberté musicale et qui est à la base de ma conception musicale. Cette liberté se déploie au niveau du timbre, mais aussi au niveau formel où elle permet de jouer avec la perception et l'agencement de l'énergie en fonction du parcours de la musique et du son<fnref n="114" />. La composition musicale, pour moi, doit exister sans contraintes théoriques formelles et sans se laisser subordonner par des structures et des formalisations au niveau de la macro-forme. Plus précisément, mon processus compositionnel ne peut pas s'ancrer dans une théorie formulée a priori. Il repose sur des idées élaborées et expérimentées dans un aller-retour avec le son, son écoute et

<footnote n="114">¹¹⁴ Par exemple, dans la pièce *Las Pintas*, l'idée est littéralement de voyager entre différents univers sonores, pouvoir se déplacer au niveau spatial et énergétique et de composer les articulations entre les univers avec différentes stratégies grâce à l'écriture de l'électronique.</footnote>
l'appréhension des relations spatiales, temporelles et dynamiques entre éléments sonores.

Mais cette attention première portée à la matière sonore ne m'empêche pas d'intégrer les possibilités formelles apportées par l'utilisation de différents types d'algorithmes ou de structures induites par des procédés génératifs déterministes ou stochastiques. En effet, aujourd'hui, toutes ces techniques font partie intégrante de la palette des couleurs sonores du compositeur. L'interaction entre ces techniques et leurs articulations font partie de mes préoccupations quand elles s'inscrivent dans une intentionnalité et une nécessité musicale induites par le son lui-même. Par exemple, pour créer des masses ou des textures sonores, j'utiliserai des processus de génération aléatoires puisque les faire à la main serait maladroit, prendrait trop de temps et le résultat risquerait de ne pas être aussi caractéristique que celui réalisé par un programme informatique génératif.

## L'espace de la représentation

La musique peut aussi se diffuser aujourd'hui de différentes manières. Elle s'est ouverte à un nouvel univers qui est celui de l'espace et du lieu physique de représentation. À cet égard, des pièces comme *Curvatura II* et *Las Pintas* sont des exemples de compositions électroacoustiques qui peuvent et doivent s'adapter au lieu de représentation. Il est possible de changer des paramètres de base comme le décodeur ambisonique, de nuancer les réverbérations pour prendre en compte l'acoustique de la salle et de moduler des éléments et des processus pendant la performance car ils sont générés en temps réel à partir d'une partition électronique centralisée (AntesCollider). Ainsi, la pièce pour ensemble spatialisé et électronique dont la création est prévue à l'automne 2022 pour la réouverture de l'espace de projection de l'Ircam avec son système de multidiffusion Ambisonic/WFS, pourra être rejouée dans d'autres lieux en s'adaptant à leur acoustique, au système de diffusion et à la configuration des haut-parleurs. La prise en compte de l'environnement et de l'espace physique de représentation avec ses qualités acoustiques spécifiques permet de jouer très finement sur le timbre et le son de l'œuvre (un bon exemple est offert par certaines pièces de A. Di Schipio [DiSh03]). Cette dimension spatiale peut aussi être utilisée et développée pour des installations sonores ou des pièces en interaction avec le public.

## VI.3. Composition des processus sonores et de leurs interactions

### L'interaction des processus sonores

La composition des pièces interactives mixtes ou uniquement électroacoustiques fondées sur des processus temps réel présente aujourd'hui plusieurs enjeux. Un des premiers concerne l'écriture et la construction des différentes interactions sonores. Par là je veux désigner principalement l'interaction des différentes couches ou sources sonores entre elles (plutôt qu'une interaction avec l'environnement). L'agencement des éléments en interaction est une tâche complexe et nécessite un environnement qui peut soutenir toutes ces interconnexions et interactions :
« L'émergence d'une approche articulée autour du concept d'interaction généralisée (interne à l'œuvre) nous permet aujourd'hui d'envisager à la fois l'existence de passages possibles entre des dimensions disjointes du temps et la nature des non-linéarités qui découlent de leur interaction. Le problème, pour un compositeur intéressé dans l'extension d'une syntaxe à toutes les dimensions temporelles, c'est de trouver les moyens d'articuler cette complexité. » [Vag95]

Dans ce type de musiques, différentes couches interagissent. Elles impliquent plusieurs échelles, plusieurs temporalités, et se superposent, chacune avec leurs propres modes opératoires. Le degré d'interaction entre tous ces éléments et toutes ces temporalités est très riche. L'exploration et la maîtrise de ces relations nécessitent des outils particulièrement expressifs pour mettre en œuvre et contrôler les interactions souhaitées ainsi que de nombreuses expérimentations et tests d'écoute.

Dans ce contexte, la notion de partition électronique centralisée et des librairies comme AntesCollider sont fondamentales puisqu'elles vont permettre justement d'organiser et faire interagir les différents éléments dans un même environnement, une partition électronique avec un langage expressif et flexible.

Voici un exemple permettant d'illustrer notre propos : un instrumentiste joue des rythmes en superposition et en interaction avec différents sons de synthèse granulaire qui fonctionnent, eux, à des vitesses beaucoup plus rapides. Ces synthèses granulaires peuvent en même temps se déplacer en masse dans l'espace avec une autre temporalité que celle qui génère les rythmes de la granulation. Ces différentes temporalités peuvent aussi être modulées (accelerando, rallentando, etc.) par d'autres processus internes ou générés par des éléments externes (analyses, capteurs). Leurs dynamiques s'organisent aussi par des points de rendez-vous ou d'opposition. On voit que différentes temporalités doivent coexister dans des relations complexes<fnref n="115" />.

## Processus sonores et processus informatiques

L'utilisation de différents types de processus de génération temporelle, leur dépendance à un tempo global ou à des tempi locaux et le contrôle de leurs comportements à travers leur instanciation, leur durée de vie, leur interaction et leurs modifications dynamiques pendant leur exécution nécessitent une structuration très forte.

Je rejoins ici l'approche développée par Horacio Vaggione qui propose de structurer ces processus à travers des réseaux d'objets et d'échelles temporelles. Je réalise la mise en œuvre de ces notions directement à travers la structuration en objet Antescofo et leurs méthodes qui permettent de gérer ces processus.

<footnote n="115">¹¹⁵ Ce type d'agencement peut être réalisé avec un langage tel que Antescofo, où différents tempi peuvent être modulés par d'autres tempi (par exemple le tempo d'un processus électronique peut se régler sur le tempo d'un musicien).</footnote>
Ce type de composition entre plusieurs processus temporels multi-échelles parallèles, et les multi-interactions imbriquées aussi à différentes échelles (avec un instrumentiste, avec des systèmes de captation gestuelle, avec des analyses des flux par descripteurs audio, avec des données provenant d'autres médias temporels, etc.) fait émerger une sonorité d'ordre supérieur. Mais elle nécessite une pratique et une maîtrise des systèmes d'écriture permettant d'agencer tous ces composants.

Donner une cohérence musicale à tous ces éléments en parallèle devient vite complexe et arriver à un résultat musical convaincant prend du temps, à moins de se contenter du résultat émergeant et de prendre l'acte de créer ces réseaux d'interactions comme l'acte de composition en soit. Ce n'est pas mon cas. Dans ma recherche musicale, le résultat sonore et musical doit prévaloir sur la théorie. Mais comme pour n'importe quel type de pratique, avec de l'entraînement et de l'expérimentation, on arrive d'une certaine manière à imaginer le rendu global résultant de ces interactions imbriquées et multiples. On réalise alors pleinement l'approche par objet et réseaux [Vag08] qui en même temps enrichit l'espace de pensée et apporte de nouvelles idées musicales conduisant à de nouvelles expérimentations.

## VI.4. Utilisation d'algorithmes, de modèles formels et de calculs dans la composition

Plusieurs compositeurs et chercheurs ont accordé à travers l'histoire une importance capitale à l'utilisation des mathématiques dans la musique. On dit couramment que la musique est en partie faite et réalisée avec des relations algébriques (échelles, rythmes, hauteurs). Aujourd'hui, nous avons la possibilité d'utiliser des machines avec des ressources de calcul importantes qui permettent désormais une exploration inédite grâce à des techniques de génération et de modélisation des structures musicales.

L'idéal de la composition musicale automatique (CMA) ou « *musique de Turing* » [Vag03] qui utilise des algorithmes pour créer des formes musicales entières ne fait pas partie de mes recherches. Je crois que dans ce dispositif, la composition perd son rapport au sonore et devient un exercice de programmation plus qu'un acte de création musicale et sonore. Dans cette vision, la création du programme devient l'objectif de la composition elle-même. À mon avis, rares sont les cas où les résultats sont intéressants au niveau formel sans une intervention manuelle du compositeur : celui-ci doit le plus souvent ajuster la partition produite pour la rendre « musicale » du fait qu'elle est caractérisée par la très faible interaction entre pensée compositionnelle et calcul (algorithmique) [Sol07]. Xenakis résume bien cette volonté de ne pas subordonner la musique aux mathématiques :

> « Les restrictions sont d'ordre général canalisatrices plutôt qu'impérieuses. Ce sont des tendances de l'être sonore que la théorie et le calcul définissent et non pas un esclavage. Les formules mathématiques sont ainsi apprivoisées et asservies. » [Xen81]

Penser qu'appuyer sur un bouton permettra de créer toute la musique automatiquement ne fait pas partie de mes aspirations. On peut tout de même formaliser des pensées musicales pour les modéliser par des algorithmes ou des processus. Par exemple,
partons de l'idée musicale suivante : créer une sonorité harmonique floue avec plus d'énergie dans les fréquences graves. Cette idée pourrait se réaliser en programmant un processus qui générerait des hauteurs à partir d'une distribution aléatoire de type exponentiel avec des rythmes irréguliers pour contrôler un synthétiseur. Puis on pourrait affiner ce processus en rajoutant des contraintes de hauteurs, par exemple pour utiliser seulement des subdivisions en huitième de ton avec des rythmes issus d'un tableau des durées pour chaque son, etc. L'avantage qu'il peut y avoir à réaliser ce type de processus dans un système temps réel capable de *live coding* comme AntesCollider est qu'on peut moduler ses paramètres en temps réel et ajuster à l'oreille (et à la main) les paramètres pour trouver le son adéquat en fonction du contexte musical.

> « D'une façon plus pragmatique, nous pouvons dire que les modèles sont des représentations conceptuelles, des intermédiaires qui font le lien entre le monde abstrait des idées (concepts) et le monde concret (des sons, des instruments, du cognitif), les fédérateurs entre l'imaginaire abstrait et le sensible, et aussi des manières de faire. » (Mikhail Malt [Pot09])

Une position intéressante est développée par Mikhail Malt avec son concept de *solfège des modèles*. Pour lui, la maîtrise d'un modèle génératif quelconque est un savoir-faire de compositeur qui s'apparente au solfège classique.

> « Il s'agit d'un solfège au sens d'aptitude à relier le comportement de deux espaces de caractéristiques différentes en tenant compte des particularités de chacun. [...] Dans notre cas précis, un “solfège de modèles” est la capacité d'interpréter, ou de relier le comportement d'un modèle formel (ou d'une représentation) à une situation musicale. [...] Il est aussi important de signaler que nous ne parlons pas non plus de ce qui est communément désigné sous l'anglicisme de “sonification” de données, soit la conversion de paramètres générés par un modèle formel quelconque dans des paramètres de l'espace musical tels que les hauteurs, des durées ou des rythmes. [...] Si nous pensons à l'utilisation de modèles de hasard par des compositeurs aussi différents que Xenakis, Cage, Birtwistle, Murail ou Ferneyhough, il est possible de se rendre compte comment un même modèle appliqué à des espaces, à des contextes et dans des esthétiques différentes produit des résultats aussi distincts, même si un invariant formel demeure. »

> La tâche du compositeur est de bien connaître ses modèles et d'évaluer la pertinence et le contexte musical de leur utilisation, le modèle se transforme ainsi en un interprète de la pensée du créateur. » Mikhail Malt [Pot09]

L'utilisation d'algorithmes est primordiale : ils m'aident à modéliser, à formaliser et à créer des passages avec certaines caractéristiques rythmiques, contrapuntiques, des sons synthétiques, des textures, des couches, des orchestrations, des mouvements dans l'espace, etc. Je les utilise comme des éléments de mon espace de pensée et de ma palette sonore compositionnelle en faisant des événements composables qui interagissent entre eux pour créer et faire émerger la morphologie du discours musical, au même titre que les hauteurs, des sons inharmoniques ou des silences.
Cette utilisation prend pleinement sa place dans le double jeu entre écoute et technique, dans cette boucle de rétroaction fondamentale qui relie l'expérimentation et le processus de composition. Cette expérimentation nécessaire accueille les imprévus ou les accidents qui, par exemple à cause d'une erreur dans les paramètres initiaux d'un processus ou un programme, induisent parfois des résultats inattendus mais qui permettent à l'imagination de rebondir et d'échapper à l'a priori. Quelquefois, « *la machine rend des réponses à une question que vous n'avez pas posée* » [BouGre88].

L'algorithme fonctionne donc à la fois comme un outil technique remplissant une fonction bien définie, comme un objet de mon espace de pensée musicale et comme une notion heuristique dans le *workflow* de la création.

Il est alors intéressant de noter que certaines notions, utilisées comme heuristique pour imaginer de nouveaux modèles de calcul ou bien pour concevoir de nouveaux algorithmes, se transportent de facto dans le domaine musical où elles gardent leur pouvoir heuristique. La notion d'agent, par exemple, en est une bonne illustration dans le développement de nouvelles approches génératives, par exemple avec la notion d'automate cellulaire. Le domaine de la vie artificielle, dont l'objectif est de créer des systèmes artificiels s'inspirant des systèmes vivants, est un autre pourvoyeur de métaphores et d'analogies heuristiques qui permettent d'imaginer d'autres formes. Dans ce contexte, l'artiste devient un « méta-créateur » [Whi04] : il développe le système qui crée l'œuvre ou une partie d'elle. L'émergence est l'une des caractéristiques de cette *A-life art* où l'artiste donne les règles à suivre qui peuvent être arbitrairement simples, mais dont l'application répétée peut engendrer une grande complexité lui rendant le résultat imprévisible [Whi04]. Dans le domaine des musiques interactives, c'est le comportement même de l'algorithme et des agents qui peut être modifié en temps réel à partir de différents *inputs*, comme des descripteurs du jeu instrumental issu de l'analyse audio ou de la captation gestuelle.

## VI.5. La composition : un artisanat et une palette en constante augmentation à maîtriser

Dans cet univers compositionnel avec une palette augmentée par les technologies informatiques comme la partition centralisée, on peut assez facilement rester bloqué ou se perdre. Plus la palette est grande, plus la confrontation avec la page blanche sera traumatique si l'on n'a pas a priori dans l'esprit des idées compositionnelles, sonores et musicales fortes.

C'est le parcours et le métier du compositeur qui lui permettent de connaître sa palette et d'imaginer des mondes sonores en fonction des possibilités offertes. C'est toujours cette expérience, tirée de l'expérimentation et de l'assimilation des rétroactions techniques et musicales, qui lui permet d'augmenter cette palette pour faire face à de nouveaux besoins musicaux. Ainsi, une dialectique se déploie entre l'outil et les besoins, l'un modelant l'autre.

On pourrait imaginer une autre approche, de nature évolutionniste, où la musique et l'outil seraient largement indépendants : le compositeur partirait de cette palette
augmentée et commencerait à expérimenter pour ne garder que les résultats jugés
satisfaisants vis-à-vis de son objectif musical et de son idée globale de la composition,
quitte à les organiser et les composer à posteriori.

Dans mon parcours de création de sons et de formes musicales, en accord avec cet esprit de liberté musicale que j’ai défini, la composition devient un artisanat et une construction « manuelle », un « tricotage » qui se fait petit à petit, en effaçant, en revenant en arrière, en anticipant un besoin futur, dans un aller-retour perpétuel entre l’outil et le résultat sonore, pour passer d’un état à un autre, se transformer et se renouveler en permanence, pour sculpter la musique et lui donner la fraîcheur et la spontanéité dont elle se nourrit.

## VI.6. Écriture du son et de la forme

« L'instant est à la fois matériau et forme : s'il est impossible de distinguer en son sein une idée concrète — thème, motif, cellule, série ou, plus généralement, un élément premier clairement délimité — d'un développement, c'est qu'il est saisissable globalement comme seul l'est le matériau ; d'un autre côté, il est fabriqué de toute pièce à la manière d'une forme. Or, cette fusion peut aussi être nommée son, le son étant à la fois forme et matière : de toute évidence, le son est marqué par sa matérialité ; mais, simultanément, si on l'isole pour lui-même, il n'est guère possible de le résumer à autre chose qu'à lui-même, ni d'en extraire un quelconque élément, sauf à le mutiler — il n'est pas une matière mise en forme. Enfin, son et instant parachèvent l'immanence qui évacue le temps : ils sont autosuffisants et ne nécessitent, pour se réaliser, aucune mémoire de ce qui précède ou aucune anticipation de ce qui suit ; ils constituent un monde clos, un univers replié sur lui-même et, par conséquent, ne renvoient à rien d'autre qu'à eux-mêmes. [...] La spatialisation de la musique va de pair ou entraîne la mutation majeure de ce siècle où la musique cesse d'être l'art des sons (sous-entendu : de la combinatoire des sons) pour devenir l'art de la synthèse du son : le repli dans l'instant qui découle de la spatialisation est synonyme de construction intérieure du son. » [Sol98]

L'un des aspects passionnants de l'ère actuelle est la possibilité de composer le son lui-même avec une palette riche de timbres et couleurs dans un contexte de liberté où le matériau n'est plus limité ni maîtrisé par le carcan d'un système formel (par exemple tonal). Comme déjà mentionné, nous avons aujourd'hui à disposition une pléthore de synthétiseurs, de techniques de synthèses numériques et ces outils semblent s'ouvrir encore à de nouvelles potentialités avec par exemple les apports de l'intelligence artificielle. Cette explosion des potentialités concerne aussi les instruments acoustiques avec le développement des modes de jeux pour les instruments de l'orchestre. Il en résulte pour la musique mixte une richesse non seulement du timbre sonore mais des interactions qui en découlent.

Ma recherche actuelle sur la composition se centre principalement sur la composition du son dans un contexte où les notions de matériau et forme s'effacent au profit de leur fusion. On passe ainsi de *composer avec le son à composer le son*. C'est le son lui-
même qui va se déployer dans le temps et l'espace et qui fera émerger la forme. Dans ce contexte, l'exploration des sons est fondamentale et disposer de systèmes qui permettent cette exploration est indispensable pour adresser non seulement le timbre mais aussi sa modification continue dans le temps (voir le chapitre VII sur la synthèse spatiale).

Ce besoin explique la focalisation de ma recherche, au niveau électroacoustique, sur la librairie AntesCollider qui permet d'un côté d'avoir un système de synthèse puissant et dynamique, et d'un autre un langage pour contrôler ces synthèses de différentes façons et les faire évoluer dans le temps et l'espace pour faire émerger un état sonore global.

Les objets (acteurs) du langage Antescofo et leurs expressivités vont permettre de créer facilement différents systèmes de synthèse pour l'exploration du son. Dans ce contexte, ces objets sont générateurs de micro- et macro-forme grâce à leurs capacités à être transformés dynamiquement dans différentes dimensions, ils deviennent multiformes, multi-échelles, multimodaux, etc. Ces objets peuvent aussi se comporter comme des agents qui vont créer leur propre vie ou interagir entre eux. Chaque objet avec ses propriétés musicales et polyphoniques donnera naissance au son et à la forme de la composition grâce à leur écriture dans la partition électronique centralisée.

La figure suivante présente un extrait de la partition électronique de la pièce audiovisuelle *Las Pintas*. Il s'agit de l'objet utilisé pour créer des morphologies granulaires HOA_grain_rot_random_rev2. Cet objet a 25 paramètres qui peuvent être modulés en temps réel pour réaliser différents mouvements de granulation dans l'espace en HOA. Ces objets génèrent en même temps le timbre, le rythme, la texture, la spatialisation, l'amplitude et la réverbération du son pour produire une morphologie spécifique. La superposition des objets de synthèse crée en même temps le son et la forme.
<figure><img src="image_52.png" /><figcaption>**Fig. 6.2** Extrait de la partition électronique de *Las Pintas*, pièce audiovisuelle. Cet extrait présente la superposition de 3 acteurs pour la création de morphologies sonores à partir de la synthèse granulaire spatiale en HOA. Chaque objet est instancié avec des paramètres différents pour générer différentes textures. Ces paramètres peuvent être modulés pour changer leur comportement (lignes 8566-8577) en temps réel pendant la performance par l'instrumentiste électronique. La superposition de plusieurs acteurs génère la sonorité globale recherchée pour ce passage de la composition.</figcaption></figure>

## VI.7. Au-delà de la notion de temps réel/différé

> « La prise de position pour le temps différé ou pour le temps réel, en d'autres termes la répartition des événements constitués de valeurs absolues ou relatives, doit désormais cesser d'être un choix technologique pour devenir un choix compositionnel. De ce point de vue, la synthèse, définie comme un calcul de paramètres totalement préétablis, est une technique relevant complètement du temps différé puisqu'il n'y a aucune détection ni analyse d'un signal en temps réel. » Philippe Manoury, *Les partitions virtuelles* [Man97]

Aujourd'hui, avec l'accès à des ordinateurs de plus en plus puissants au niveau du calcul, la distinction historique entre temps réel et temps différé devient de plus en plus floue. Ce brouillage est à l'œuvre dans plusieurs directions.

La puissance de calcul permet à présent d'intégrer certaines opérations de CAO lors de la performance, et des fonctionnalités qui étaient conçues pour le temps différé, comme celles offertes par OpenMusic, peuvent être utilisées en temps réel avec *bach* dans Max
par exemple. Il existe toujours aujourd'hui des processus qui n'arrivent pas à être calculés en temps réel, comme la spatialisation de masses sonores dans un système Ambisonic d'ordre élevé (au-delà de l'ordre 5). Mais avec des processeurs (CPU) de plus en plus rapides et la multiplication des cœurs (multiprocesseur), ces limitations se rétrécissent, ce qui permet d'intégrer de plus en plus de processus qui auparavant étaient seulement disponibles en temps différé.

Par ailleurs, des logiciels conçus pour le temps réel peuvent être utilisés en temps différé. Les fonctionnalités propres à « l'écriture sur papier », comme revenir en arrière, effacer, recomposer, enregistrer, éditer, etc., peuvent à présent se faire dans des langages informatiques temps réel comme Antescofo ou la librairie AntesCollider dans la partition électronique avec la fonction *live coding*. Le travail compositionnel avec ces logiciels permet alors une écoute « en direct » du résultat des processus quelle que soit leur nature (génératif, déterministe ou stochastique). L'acte de composer précède toujours le temps de la performance : il ne s'agit pas d'une improvisation mais de composer avec des outils qui réagissent en même temps qu'on les manipule, d'une façon analogue à l'utilisation du piano comme aide à l'écriture pour orchestre.

Enfin, l'exemple des musiques électroacoustiques en temps réel (un exemple sera présenté au chapitre VIII) est un exemple de composition écrite mais qui se recrée en temps réel (au lieu de diffuser un enregistrement). Ce schéma confère une flexibilité qui permet par exemple d'adapter la pièce très finement à un lieu d'écoute ou d'altérer des paramètres et des comportements avant ou pendant le jeu.

## Maquettes, écoute intérieure et concrète

La possibilité de faire de la CAO en temps réel, avec par exemple des maquettes à la manière d'OpenMusic intégrées à des langages temps réel de plus en plus sophistiqués et offrant des possibilités de traitement symbolique, permet de retrouver dans le temps différé ce qui en avait été exclu : l'écoute concrète.

Dans ma démarche, l'écoute concrète est fondamentale ; je peux imaginer des processus, des mouvements dans l'espace, des morphologies sonores qui se transforment et les programmer dans la partition électronique, mais ces idées doivent absolument être validées par l'écoute. On peut en effet avoir des idées de prime abord séduisantes sur la manière de créer des formes sonores, mais lorsqu'on réalise ces idées à l'aide d'un programme informatique, le résultat ne correspond pas toujours à ce que l'on avait imaginé. Souvent, il faut retravailler l'idée pour que sa réalisation corresponde à l'impulsion de base et surtout qu'elle devienne intéressante dans un contexte musical. La question de la perception et de l'appréhension sonore reste pour moi fondamentale et c'est pourquoi j'ai besoin de cette écoute. Je ne peux pas dérouler un concept, si élégant ou élaboré qu'il puisse être, sans un retour perceptif et sans éprouver l'impact cognitif déclenché par sa perception.
## VI.8. Un compositeur doit-il apprendre à programmer ?

C'est une question qu'on m'a posée à plusieurs reprises et cette thèse défend l'usage de la programmation comme partition électronique.

On peut légitimement se poser la question du rapport entre composition et programmation informatique. De nombreux compositeurs trouvent une réponse à leurs besoins dans l'offre existante de logiciels de montage, de composition et d'interaction, sans avoir besoin de recourir à la programmation.

Le cursus annuel de composition à l'Ircam offre un bon exemple des attitudes possibles face à l'informatique musicale. Les étudiants pratiquent cette discipline pendant toute une année, avec de nombreux travaux pratiques, pour aboutir en fin d'études à la composition d'une pièce mixte en utilisant des programmes temps réel dans Max. Après ces études, certains compositeurs continuent à pratiquer l'informatique et même à étendre leurs compétences pour réaliser des pièces avec une grande composante technologique. D'autres, en revanche, abandonnent complètement la composante technologique ou s'adresseront par la suite à un RIM pour réaliser la partie électronique de leurs compositions.

La maîtrise d'un langage de programmation est similaire à l'apprentissage d'une nouvelle langue ou d'un nouvel instrument qui nécessite un investissement se comptant en années. La programmation a une courbe d'apprentissage longue et, pour certains, c'est un monde aride trop éloigné des problématiques artistique et musicale. Il faut d'une certaine façon aimer se confronter à une machine et aux problématiques logiques de la programmation pour passer au-delà de cette aridité et y percevoir un langage permettant d'exprimer, de travailler et de concrétiser une idée musicale.

Le passage entre programmation et composition n'est pas toujours évident car toutes les deux ont besoin de travail et de temps. Il faut donc trouver un bon équilibre et organiser les ressources qu'on va consacrer à l'une ou l'autre. Dans ma pratique, j'ai opté pour essayer de séparer le développement informatique de la composition, c'est-à-dire que je donne la priorité à l'un ou l'autre en fonction du temps, des commandes... Bien entendu, les deux mondes sont complètement perméables, on ne peut pas les séparer ou les isoler : pour programmer, il faut avoir en tête ce qu'on veut faire au niveau musical, et pour composer avec des partitions électroniques, on est confronté à la programmation tout au long de la composition. Pendant le processus de composition, de nouvelles idées peuvent émerger et elles doivent être programmées. Cependant, une programmation de plus bas niveau, comme le développement d'une librairie, devrait se réaliser dans un autre temps que celui de la composition, pour ne pas interférer avec la fluidité du processus créatif.

Un des principaux avantages d'être un compositeur-programmeur (même à différents niveaux de maîtrise) est de pouvoir expérimenter directement des idées musicales liées à la technique et éprouver cette rétroaction entre création, pratique et expérimentation. Aujourd'hui, cette approche est complètement intégrée à ma pratique compositionnelle et la programmation participe à l'imaginaire du compositeur. Je ne peux plus concevoir
ces deux activités l'une sans l'autre. Cette expérience de la programmation m'a aussi donné une compréhension précieuse des possibilités offertes par les technologies numériques. Et elle m'a aussi amené à travailler en tant que RIM, ce qui m'a permis de me confronter aux esthétiques et pensées de divers compositeurs.

La programmation s'est donc révélée dans mon parcours être un outil de libération. Une libération bornée par les possibilités techniques et par notre imagination, mais qui permet de s'affranchir du cadre fermé de nombreux logiciels commerciaux. Une liberté nécessaire pour expérimenter de nouvelles idées musicales.

La réponse à la question posée au début de cette section est donc positive, à la condition de ne pas opposer la programmation à la composition, de l'intégrer réellement dans les cursus de composition (au même titre que l'orchestration ou l'analyse) et de montrer toute la fécondité de la rétroaction créativité-programmation-créativité.

Cet objectif est atteignable : les compositeurs intègrent déjà complètement l'outil informatique avec l'utilisation des DAW dans leur pratique quotidienne. Des initiatives comme dans Ableton Live permettent d'ouvrir ces environnements, de montrer les bénéfices de la programmation et de simplifier l'apprentissage en s'appuyant sur des environnements déjà maîtrisés.
# VII. L'espace

> « De simple mode de représentation, l'espace a fini
> par absorber la musique, à tel point qu'on peut se
> demander si, contrairement à toute définition
> courante, la musique ne serait pas, de nos jours, plutôt
> que l'art du temps, un nouvel art de l'espace. » [Sol98]

On considère en musique deux types d'espace : l'espace de représentation, un espace abstrait qui correspond aux lieux de l'écriture, de la conception musicale et de la synthèse du son dans lequel on construit et on pense les sons et la musique, et puis l'espace physique, l'environnement dans lequel la musique et les sons vont se propager.

On trouve plusieurs espaces de représentation dans la notation musicale, par exemple l'espace des hauteurs, des timbres ou des rythmes et leurs associations spatiales ou ce que Makis Solomos appelle la géométrisation de la musique :

> « Cette géométrisation renvoie à la rationalisation de la musique... Aussi, à travers les processus de géométrisation et de rationalisation, la notion d'espace de représentation s'est naturalisée en musique, permettant de la penser comme entièrement composable. C'est ainsi que, dans les années 1950-1960, est apparue, avec le sérialisme, la définition paramétrique de la musique, permettant de la décomposer en "paramètres". Aujourd'hui, on peut l'envisager comme un espace multidimensionnel, où le compositeur définit des objets symboliques justiciables d'opérations constituant une sorte de géométrie de cet espace composable. » [Sol13]

À ce propos, Ligeti écrivait :

> « Les relations syntaxiques des moments musicaux particuliers sont transposées [...] par notre imagination dans un espace virtuel, où les moments particuliers – éléments, figures, chaînons, parties, etc. – agissent comme des lieux ou des objets et où le devenir musical apparaît dans son écoulement total comme l'architecture dans l'espace. »

[Lig66]

Ligeti parle aussi de la notion de réversibilité comme une qualité de la pensée spatiale :

> « La permutabilité du temps est la source la plus féconde pour les associations spatiales. Alors qu'une succession irréversible, comme la progression cadentielle de l'harmonie tonale, expose le temps lui-même dans son écoulement inexorable, les figures interchangeables et renversables dans la succession temporelle présentent la qualité primordiale de l'espace : la réversibilité. Revenir à son point de départ n'est possible que dans l'espace, pas dans le temps. » [Lig14]

Les représentations spatiales sont aujourd'hui complètement intégrées à la conception et la composition de la musique. Elles sont aussi présentes dans l'utilisation compositionnelle de l'espace physique, avec ce que l'on peut désigner par « synthèse
spatiale». Imaginer l'espace sonore physique et ses transformations, déformations, transmutations rendues possibles grâce aux techniques de diffusion sonore spatialisée, fait de cet espace physique (et virtuel dans sa conception) un espace de représentation dans lequel on peut créer des formes sonores et musicales.

## VII.1. L'espace physique

Le son est un phénomène spatial en soi puisqu'il voyage et se propage dans l'air (un fluide) sous forme d'ondes longitudinales grâce à la déformation élastique de l'air. La notion de son spatial est donc une tautologie.

### Une préoccupation ancienne

L'espace physique en musique n'est pas une préoccupation ou invention récente : il est déjà présent dans plusieurs musiques traditionnelles où la disposition des musiciens dans l'espace est fondamentale. Ces dispositions ont souvent une fonctionnalité en relation directe avec des rituels ou avec l'environnement dans lesquels ils se pratiquent, par exemple en plein air ou dans des temples. Avant le XXe siècle, dans la musique de tradition occidentale, la composition de l'espace physique n'a pas eu une importance fondamentale, à quelques exceptions près.

> « C'est l'autonomisation de la musique – sa défonctionnalisation, si l'on préfère – qui lui a fait perdre la pensée de l'espace, notamment dans le cadre de la musique de chambre ; quant à la musique de concert, l'espace n'a pas disparu, mais il s'est limité à la scène et au rapport frontal avec le spectateur. La reconquête de l'espace peut parfois être interprétée comme une refonctionnalisation de la musique, non pas à travers une fonction sociale, mais à travers un lieu. Mais elle relève peut-être encore plus de la rationalisation du matériau et de l'évolution vers la totalité articulée : l'espace devenant lui aussi justiciable d'une écriture, d'une construction, un pas de plus est fait en direction de cette totalité. » [Sol13]

L'intégration à l'écriture musicale de l'espace physique comme un paramètre structural créateur de morphologies sonores est déjà manifeste au XVIe siècle avec l'utilisation des particularités architecturales de la cathédrale de San Marco à Venise avec ses deux orgues et balcons. Les expériences stéréophoniques des *Cori Spezzati* de Adrian Willaert, Andrea et Giovanni Gabrieli avec les contrepoints qui passent d'un chœur à un autre dans les balcons de la cathédrale constituent déjà une écriture spatiale. Avec *Spem in alium* (1570), motet pour 40 voix séparées pour huit groupes de cinq chanteurs autour de l'audience de Thomas Thallis, ou *Deo gratias*, canon à 36 voix spatialisées de Johannes Ockeghem, on assiste à une véritable écriture des voix dans l'espace ou ce qu'on appelle aujourd'hui des sources sonores. On peut citer d'autres exemples comme la *Serenade Notturno* KV 239 (1776) pour deux orchestres et le *Notturno* KV 286 pour quatre orchestres de Mozart... Un exemple marquant plus proche de nous est la *Grande Messe des Morts* (1837) de Berlioz pour orchestre, chœur et quatre groupes d'instruments à cuivres placés dans les quatre coins du lieu de représentation. Citons aussi Debussy qui réfléchissait également à la dimension spatiale de la musique :
« On peut entrevoir un orchestre nombreux s'augmentant encore du concours de la voix humaine [...]. Par cela même, la possibilité d'une musique construite spécialement pour le “plein air”, toute en grandes lignes, en hardiesses vocales et instrumentales qui joueraient et planeraient sur la cime des arbres dans la lumière de l'air libre. »
[Deb87]

Dans les musiques électroacoustiques, la spatialisation des sons est présente dès les débuts. Le premier concert avec spatialisation en direct a été donné en 1951 avec Pierre Schaeffer et Pierre Henry, diffusion sonore en relief spatial appelé « bureau en relief ».

## Une préoccupation personnelle

Mon travail sur l'espace débute en 1996 quand j'ai eu l'occasion de travailler au LIPM (Laboratoire de recherche et de production musicale) à Buenos Aires. Ce studio permettait de faire de la quadriphonie, mais seulement en temps différé avec des langages tels que CLM (Common Lisp Music<sup>116</sup>) ou Csound<sup>117</sup> tournant sur un système NeXTSTEP<sup>118</sup>.

En 1997, avec le développement de MSP dans Max, un nouveau monde s'est ouvert pour les compositeurs n'ayant pas nécessairement accès à l'époque à des plateformes spécialisées (comme la station ISPW : Ircam Signal Processing Workstation). L'apparition de MaxMSP tournant sur un ordinateur personnel Macintosh a constitué une grande révolution pour un jeune compositeur habitant dans un pays où ce genre de recherches étaient loin d'être une préoccupation ou un paradigme dominant chez les musiciens. J'ai commencé mes premières expériences avec un système quadriphonique en temps réel et la première pièce réalisée en 1999, *Attract*, pour clarinette et électronique en temps réel, basée sur des modèles chaotiques pour la composition et le contrôle en temps réel fut une expérience marquante pour le reste de mon travail.

Mon passage par le CNSMD de Lyon et son département SONVS créé par Philippe Manoury et Denis Lorrain m'a permis de continuer l'exploration de l'espace avec des systèmes plus performants et avec des outils de spatialisation comme le Spat Ircam intégrant plus fortement les aspects perceptifs.

Un événement que je n'avais pas du tout prévu m'a amené à renouveler mon approche de la spatialisation et de l'électronique en général : la rencontre avec le compositeur Emmanuel Nunes et le travail avec Eric Daubresse en tant que RIM à l'Ircam, d'abord pour la programmation de *Lichtung III* pour grand ensemble et électronique et puis pour celle de *Einspielung I* pour violon et sa nouvelle version avec électronique en temps réel. L'écriture de l'électronique et la spatialisation dans ces deux œuvres ont eu une influence majeure dans ma façon de concevoir l'électronique et la spatialisation. Dans ces pièces, les paramètres d'une note – hauteur, rythme, intensité, agogique –

<footnote n="116">116 https://ccrma.stanford.edu/software/clm/</footnote>

<footnote n="117">117 https://csound.com</footnote>

<footnote n="118">118 https://fr.wikipedia.org/wiki/NeXTSTEP</footnote>
sont élargis avec une notion d'« espace composable » dans le traitement de l'électronique.

## VII.2. Synthèse spatiale

« Ma première tentative pour donner à la musique une plus grande liberté fut l'utilisation de sirènes dans plusieurs de mes œuvres (Amériques, Ionisation), et je pense que ce sont ces trajectoires de sons paraboliques et hyperboliques qui ont amené certains écrivains à s'emparer de ma conception spatiale de la musique, dès 1925. Zanotti Bianco, par exemple, qui écrivait dans The Arts, parlait à cette époque de "masses de sons coulées dans l'espace" et de "grandes masses dans l'espace astral". Bien sûr, il ne s'agissait encore que d'un "trompe l'oreille", d'une illusion auditive ; on pourrait en parler, mais cela n'existait pas encore », Edgar Varèse [Var83].

Le concept de synthèse spatiale vient de l'utilisation de la notion de perception spatiale (localisation absolue, relative, mouvement et trajectoires dans l'espace d'un son) pour créer ou transformer des morphologies sonores ou des structures musicales en fonction de leur position ou de leur déplacement dans un environnement imaginaire (espace virtuel en 3D) ou réel (salle de concert).

Ces idées ont commencé à s'élaborer plus précisément à partir des musiques des années 1950 avec la figure d'Edgar Varèse, pionnier dans l'idée de composer l'espace comme une « projection sonore ». Par exemple, Varèse écrit à propos d'Intégrales :

> « Les Intégrales furent conçues pour une projection spatiale. Je les construisis pour certains moyens acoustiques qui n'existaient pas encore, mais qui, je le savais, pouvaient être réalisés et seraient utilisés tôt ou tard... [...] Par projection j'entends la sensation qui nous est donnée par certains blocs de sons, je pourrais dire "rayons de son" si proche est cette sensation de celle produite par les rayons de lumière qu'émettrait une puissante torche d'exploration. Pour l'oreille comme pour l'œil, ce phénomène donne un sentiment de prolongation, de voyage dans l'espace. » [Var83]

D'après Pierre Boulez :

> « Je ne puis, quant à moi, me résoudre à une vue aussi simpliste ; la répartition spatiale me paraît mériter une écriture [plus] raffinée [...]. Elle ne doit pas seulement distribuer des ensembles éloignés suivant des figures géométriques simples, lesquels arrivent toujours, en fin de compte, à s'inscrire dans un cercle ou une ellipse : elle doit aussi, et plus encore, disposer la microstructure de ces ensembles [...]. Il est bien certain que l'indice de répartition (l'espace) ne joue pas seulement dans la durée sur les durées, mais aussi bien sur les hauteurs et les dynamiques, et sur les timbres. » [Bou63]

Karlheinz Stockhausen a beaucoup expérimenté, notamment dans sa pièce électronique Gesang der Jünglinger, dans des pièces instrumentales comme Gruppen pour trois groupes instrumentaux ou encore dans Carré où la construction spatiale devient un paramètre à part entière. Dans ces pièces, l'écriture de l'espace est directement liée à l'écriture instrumentale puisque pour faire passer un son d'un endroit à l'autre par des fondus enchaînés, il faut réfléchir au mouvement spatial, son orchestration et sa
temporalité. Dans son article écrit en 1958, « Musique dans l'espace », il écrit par exemple :

« *La ressemblance des trois formations orchestrales entre elles résulte de la volonté de faire circuler des groupes de sons dans l'espace, d'un corps sonore à l'autre, et de segmenter simultanément des structures sonores semblables entre elles ; chaque orchestre doit pouvoir interpeller les autres, leur répondre ou leur faire écho.* »

En relation avec l'espace comme paramètre musical à part entière, il écrivait :

« *Dans le cas particulier d'une organisation spatiale unidimensionnelle des sources acoustiques, nous pouvons à présent mettre en relation les proportions de hauteur, de durée, de timbre et de sonie avec celle du lieu du son. Nous aboutissons ainsi au concept de "mélodie spatiale" (Raum-Melodie).* » [Sto17]

Avec les premiers essais de John Chowning [Cho71] de réverbérations artificielles pour simuler des espaces par ordinateur, une nouvelle dimension s'est ouverte au traitement du son dans l'espace. À l'Ircam, le développement dès le début des années 1990 du Spat est une avancée technologique dans la manipulation de la perception spatiale d'un son qui a permis de composer avec l'espace, et tout particulièrement dans les musiques mixtes [CNW15]. Le Spat est un système modulaire temps réel intégré en tant que librairie dans le logiciel Max. Depuis sa création, il a été utilisé pour la spatialisation d'un grand nombre de pièces réalisées à l'Ircam et ailleurs et est passé par différentes étapes de développement. Au début, le système était limité à une entrée stéréo et une douzaine des sorties audio ; aujourd'hui, il peut gérer des centaines de canaux audio et plusieurs formats de spatialisation.

Depuis sa première version, le Spat fonctionne sur un paradigme de source sonore, c'est-à-dire que le système reçoit un signal mono ou stéréo en entrée représentant une source qu'on va pouvoir placer dans un espace virtuel indépendamment de la disposition particulière des haut-parleurs dans la salle. Comme pour les autres paramètres de l'électronique, il devient possible d'écrire la position et les mouvements des sources dans l'espace dans une partition électronique. Dans ce paradigme de sources spatialisées, deux concepts se dégagent, celui de la position fixe et celui de trajectoire spatiale.

Avec des techniques numériques de plus en plus élaborées (Ambisonic, WFS [DAMONI03], VBAP) et la multiplication des lieux de diffusion équipés (espace de projection de l'Ircam, Kubus du ZKM, Satosphère à la SAT, etc.), l'espace est devenu aujourd'hui un élément incontournable dans la création musicale contemporaine, un paramètre de la composition qui impacte la structure, la compréhension et l'écoute de l'œuvre.

Si la problématique de la spatialisation du son est présente assez tôt dans mes compositions mixtes et électroacoustiques, l'idée de synthèse spatiale se manifeste plus précisément avec ma pièce *Gravita*, pour alto, système de captation gestuelle et électronique temps réel, puis dans la pièce *M-brana* pour percussions, contrebasse, système de captation gestuelle et électronique temps réel. Dans ces pièces, les positions
des sources sonores (issues des traitements en temps réel des instruments) sont contrôlées par des modèles physiques (fondés sur les librairies PMPD<fnref n="119" /> et MSD<fnref n="120" />). Ces modèles sont eux-mêmes contrôlés par la captation gestuelle. Dans ma pièce électroacoustique par ailleurs, j'utilise la notion de déformation spatiale, une réfraction qui se traduit par une transformation des sources en fonction de la position dans laquelle elles se trouvent dans l'espace. Quand une ou plusieurs sources sonores se déplacent, elles sont soumises à différents traitements qui dépendent de la région qu'elles traversent. Dans cette pièce, la synthèse granulaire [Gab47] est répartie dans l'espace et dans des zones en 2D.

<figure><img src="image_53.png" /><figcaption>**Fig. 7.1** Programme de réfraction du son en fonction de sa position spatiale (réalisé en Max/Spat). On peut choisir pour chaque zone en 2D une transformation spécifique, quand une source sonore passe par une zone spécifique, elle sera transformée en fonction du traitement assigné à la zone. Ces zones circulaires à gauche de 1 à 8, peuvent changer dynamiquement de position et de taille dans le temps.</figcaption></figure>

Avec la librairie AntesCollider, les possibilités de traitements et de synthèses spatiales s'ouvrent vers de nouvelles explorations grâce à la flexibilité, le dynamisme et l'intégration de différents algorithmes de génération morphologiques dans l'espace physique, mais aussi grâce à l'intégration des techniques de spatialisation (VBAP, HOA, WFS...). L'écriture de la spatialisation et la restitution spatiale bénéficient grandement de ces techniques puisqu'on ne va pas écrire pour une configuration spécifique de haut-parleurs, mais pour un espace virtuel qui pourra par la suite être diffusé dans n'importe quelle configuration de haut-parleurs, analogue à ce qu'on

<footnote n="119">¹¹⁹ http://drpichon.free.fr/pmpd/</footnote>

<footnote n="120">¹²⁰ http://drpichon.free.fr/msd/</footnote>
appelle dans le cinéma le *mixage orienté objet*<fnref n="121" /> (des sources sonores avec des métadonnées spécifiant leurs positions et mouvements pour être diffusées dans différentes configurations de haut-parleurs dans les salles de cinéma).

Si le paradigme de source sonore est largement utilisé pour la spatialisation des sons avec des trajectoires ou des positions fixes, une nouvelle approche émerge avec la notion d'objet sonore spatial<fnref n="122" />. Le terme d'objet sonore spatial décrit une construction morphologique présentant une étendue spatiale plus complexe qu'une source sonore ponctuelle localisée à une position fixe ou bien se déplaçant sur une trajectoire. Il désigne des structures sonores composites avec des relations entre ses composants, par exemple des masses ou des textures sonores, qui à leur tour peuvent se métamorphoser dans l'espace/temps. La composition et l'écriture de ces objets sonores spatiaux, puis leur perception, sont conditionnées par les réflexions du son dans l'espace. La morphologie sonore avec tous ses paramètres ne peut donc pas être séparée de la position, de la vitesse de déplacement, de la distance, de l'orientation, du lieu (réel ou virtuel) et de sa réverbération.

Dans la librairie AntesCollider, il n'y a plus besoin de définir des sources sonores puisque les ressources nécessaires sont automatiquement et dynamiquement allouées lors de la création de l'acteur<fnref n="123" /> associé à l'objet spatial. Cet aspect technique donne une grande liberté dans la création des structures sonores spatiales et facilite le maintien d'une cohérence entre ses composants et l'espace physique. Il est aussi assez facile d'intégrer différents algorithmes pour la création de trajectoires complexes. Les figures 2 et 3 illustrent l'intégration de la librairie Trajectory Score Library de Nadir Babouri dans AntesCollider pour la création de trajectoires en 2D et 3D. Dans la figure 4 suivante, on voit quelques exemples de création algorithmique de sources sonores par un contrôle global des mouvements spatiaux, notamment par des modèles physiques (mécanique newtonienne) ou relevant de la vie artificielle comme les nuées d'oiseaux [Rey87].

<footnote n="121">¹²¹ T. Sporer, J. Plogsties et S. Brix, *CARROUSO – An European Approach to 3D-Audio*, Audio Engineering Society Convention 110, mai 2001.</footnote>

<footnote n="122">¹²² Le terme d'objet n'est pas utilisé ici dans le même sens que dans la notion de mixage orienté objet, même si techniquement le mixage objet peut intervenir dans la réalisation d'un objet spatial.</footnote>

<footnote n="123">¹²³ Rappelons qu’un « acteur » est un objet dont les calculs s’effectuent en parallèle à ceux des autres acteurs. Cette notion est introduite dans le chapitre sur Antescofo.</footnote>
<figure><img src="image_54.png" /><figcaption>**Fig. 7.2** Une capture d'écran des différentes sources dans un environnement ambisonique réalisé dans AntesCollider avec l'intégration de la librairie programmée à l'aide de la librairie Antescofo Trajectory Score Library originalement conçue pour contrôler le Spat Ircam.</figcaption></figure>
```c
// 2D
obj::crea_track_HOA("track_traj_2D_1", "group_hoa1", [["Impulse_Pluck", "freq", @rand_range(900, 1130), "freq_imp", $tracks("track_traj_2D_1").traj_lib_ellipse(loop_num = 20, speed=4)

obj::crea_track_HOA("track_traj_2D_2", "group_hoa1", [["Impulse_Pluck", "freq", @rand_range(900, 1130), "freq_imp", $tracks("track_traj_2D_2").traj_libSin(2, -2, 0.2, 3, 0., 2, loop_num = 20, elev=0.1)

obj::crea_track_HOA("track_traj_2D_3", "group_hoa1", [["Impulse_Pluck", "freq", @rand_range(900, 1130), "freq_imp", $tracks("track_traj_2D_3").traj_lib_lissajou(loop_num = 20)
$tracks("track_traj_2D_3").traj_lib_lissajou(loop_num = 20, b=2)
$tracks("track_traj_2D_3").traj_lib_lissajou(loop_num = 20, m=5)

obj::crea_track_HOA("track_traj_2D_4", "group_hoa2", [["TestSynth3", "freq", @rand_range(150, 444), "amp", -8]])
$tracks("track_traj_2D_4").traj_lib_lissajou_bis(k=7, loop_num = 20, elev=0.05)

obj::crea_track_HOA("track_traj_2D_5", "group_hoa2", [["TestSynth3", "freq", @rand_range(150, 444), "amp", -8]])
$tracks("track_traj_2D_5").traj_lib_deltoide(loop_num = 20, elev=0.05)

obj::crea_track_HOA("track_traj_2D_6", "group_hoa2", [["BassSynth1", "freq", @rand_range(30, 60), "fmrange", 1.5, $tracks("track_traj_2D_6").traj_lib_rosace(loop_num = 20, elev=0.5)
// $tracks("track_traj_2D_6").free()
obj::crea_track_HOA("track_traj_2D_7", "group_hoa3", [["BassSynth1", "freq", @rand_range(30, 60), "fmrange", 1.5, $tracks("track_traj_2D_7").traj_lib_rosace_var(loop_num = 20, elev=0.5)

obj::crea_track_HOA("track_traj_2D_8", "group_hoa3", [["BassSynth1", "freq", @rand_range(30, 60), "fmrange", 1.5, $tracks("track_traj_2D_8").traj_lib_gauss(iniT=-2, targeT=0.5, k = 0.2, loop_num = 20)

obj::crea_track_HOA("track_traj_2D_9", "group_hoa3", [["BassSynth1", "freq", @rand_range(30, 60), "fmrange", 1.5, $tracks("track_traj_2D_9").traj_lib_hypocycloide1(loop_num = 20, elev=0.1)

obj::crea_track_HOA("track_traj_2D_10", "group_hoa4", [["BassSynth1", "freq", @rand_range(30, 60), "fmrange", 1.5, $tracks("track_traj_2D_10").traj_lib_hypocycloide2(loop_num = 20, elev=0.1)

obj::crea_track_HOA("track_traj_2D_11", "group_hoa4", [["BassSynth1", "freq", @rand_range(30, 60), "fmrange", 1.5, $tracks("track_traj_2D_11").traj_lib_curvoide(loop_num = 20, elev=0.1)

obj::crea_track_HOA("track_traj_2D_12", "group_hoa4", [["BassSynth1", "freq", @rand_range(30, 60), "fmrange", 1.5, $tracks("track_traj_2D_12").traj_lib_hypo_var(loop_num = 20, elev=0.1)

obj::crea_track_HOA("track_traj_2D_13", "group_hoa5", [["BassSynth1", "freq", @rand_range(30, 60), "fmrange", 1.5, $tracks("track_traj_2D_13").traj_lib_epi(m = $pi/2, speed = 20, loop_num = 20)

// 3D
obj::crea_track_HOA("track_traj_3D_1", "group_hoa5", [["Impulse_Pluck", "freq", @rand_range(900, 1130), "freq_imp", $tracks("track_traj_3D_1").traj_lib_generic3D(loop_num = 20, speed=4)

obj::crea_track_HOA("track_traj_3D_2", "group_hoa5", [["Impulse_Pluck", "freq", @rand_range(900, 1130), "freq_imp", $tracks("track_traj_3D_2").traj_lib_helicoide3D(loop_num = 20)

obj::crea_track_HOA("track_traj_3D_3", "group_hoa6", [["Impulse_Pluck", "freq", @rand_range(900, 1130), "freq_imp", $tracks("track_traj_3D_3").traj_lib_couronne3D(loop_num = 20)

obj::crea_track_HOA("track_traj_3D_4", "group_hoa6", [["TestSynth3", "freq", @rand_range(150, 444), "amp", -8]])
$tracks("track_traj_3D_4").traj_lib_clelie3D(loop_num = 20, offsetX = 0, offsetY = 0)
```

<caption>Fig. 7.3 Code AntesCollider pour la création des trajectoires à partir de la librairie Trajectory Score Library. Chaque track crea_track_HOA peut être spatialisé avec une trajectoire créée par une fonction mathématique, comme ellipse, lissajou, gausse, etc. L'avantage par rapport à d'autres systèmes est qu'il n'y a pas besoin de spécifier le numéro de la source que l'on va traiter puisque la trajectoire s'applique directement à un track déterminé.</caption>
<figure><img src="image_55.png" /><figcaption>**Fig. 7.4** Visualisation des sources dans un environnement ambisonique en 3D dans l'interface `antescollider_spatial_interface`. L'image n° 1 est une capture d'écran d'un système de particules qui se déplacent aléatoirement dans un cube virtuel. L'image n° 2 représente 90 sources qui suivent une trajectoire orbitale avec un type de synthèse qui peut changer dynamiquement ainsi que tous ses paramètres. L'image n° 3 est la sonification/visualisation d'un algorithme de simulation de nuées d'oiseaux (*flocking birds* ou *boids*) en 3D. L'image n° 4 est un système de particules en 3D avec des mouvements aléatoires circulaires qui peuvent, par exemple, simuler les déplacements d'insectes autour d'un auditeur. Les paramètres des modèles physiques peuvent être modulés en temps réel pour changer le comportement du système.</figcaption></figure>

1. **NOTE 60 1 HOA_orbits**
2. **// decodeur hexa**
3. **obj::mix_group_HOA("group_hoa1", "localhost", "hexa", 3)**
4. **5. // visualisation**
5. **$gui_enabled := true**
6. **8. // création des tracks**
7. **obj::crea_track_HOA("track_hoa1", "group_hoa1", [["Impulse_Pluck", "freq", 548.83, "freq_imp", 10.7, "del", 0.006, "amp", -3]])**
8. **11 $tracks("track_hoa1").ambi_orbit(0, 0.06)** // méthode orbit pour créer des orbites <angle de départ, vitesse de déplacement>
9. **12. // visualisation**
10. **obj::crea_track_HOA("track_hoa2", "group_hoa1", [["Impulse_Pluck", "freq", 600, "freq_imp", 20, "del", 0.0005, "amp", -3]])**
11. **14 $tracks("track_hoa2").ambi_orbit(0, 0.04)**
12. **15. // création des tracks**
13. **obj::crea_track_HOA("track_hoa2_1", "group_hoa1", [["Impulse_Pluck", "freq", 300, "freq_imp", 20, "del", 0.00051, "amp", -3]])**
14. **17 $tracks("track_hoa2_1").ambi_orbit(0, 0.033)**
15. **18. // création des tracks**
16. **obj::crea_track_HOA("track_hoa3", "group_hoa1", amp = 6, [["Impulse_Pluck", "freq", 400, "freq_imp", 30, "del", 0.0002, "amp", 0]])**
17. **20 $tracks("track_hoa3").ambi_orbit(0, 0.01)**
18. **21. // visualisation**
19. **obj::crea_track_HOA("track_hoa4", "group_hoa1", [["TestSynth3", "freq", 123, "amp", -8]])**
20. **23 $tracks("track_hoa4").ambi_orbit(60, 0.01)**
21. **24. // visualisation**
22. **obj::crea_track_HOA("track_hoa5", "group_hoa1", [["TestSynth3", "freq", 234, "amp", -8]])**
23. **25 $tracks("track_hoa5").ambi_orbit(90, 0.08)**
24. **26. // visualisation**
25. **obj::crea_track_HOA("track_hoa6", "group_hoa1", [["TestSynth3", "freq", 345, "amp", -8]])**
26. **29 $tracks("track_hoa6").ambi_orbit(120, 0.067)**
27. **30. // visualisation**
28. **obj::crea_track_HOA("track_hoa7", "group_hoa1", [["TestSynth3", "freq", 456, "amp", -8]])**
29. **32 $tracks("track_hoa7").ambi_orbit(160, 0.055)**

<caption>**Fig. 7.5** Extrait du code AntesCollider pour la création de synthèses spatialisées suivant une trajectoire orbitale (image n° 2 de la figure précédente). Chaque fois qu'on instancie un nouvel objet `obj::crea_track_HOA`, une nouvelle source est créée automatiquement. La méthode `.ambi_orbit` va appliquer un algorithme de génération d'orbites pour contrôler la position et la vitesse de chaque synthèse définie avec un dosage d'effet doppler dans chaque track (source).</caption>
<figure><img src="image_56.png" /><figcaption>**Fig. 7.6** Code dans le langage Antescofo avec la libraire AntesCollider et des modèles physiques pour la création du système de particules (image n° 4 de la figure précédente). De la ligne 3 à 6, on définit des variables globales pour l'ordre HOA, le nombre de particules, leur masse et les limites spatiales. À la ligne 27, on définit un tableau des masses avec l'objet Mass3D, puis à la ligne 30, les limites dans une sphère. La ligne 33 montre l'utilisation d'un acteur (objet) ambient pour générer des mouvements aléatoires. Les lignes 35 à 54 définissent l'itération qui va calculer un nouvel état du système tous les 0.2 pulsations (ou secondes avec un BPM de 60).</figcaption></figure>

L'une des principales applications de la localisation d'une source sonore dans l'espace est la synthèse granulaire spatiale en 2D [Kim05] ou 3D [Fon13] et ses dérivés comme la synthèse concatenative [Sch00] ou *mosaicing* [ZiPa01], notamment dans un environnement ambisonique HOA [Mar09] [DeSh09]. Ces techniques de synthèse étendues pour intégrer l'espace physique, vont permettre de sculpter le son non seulement au niveau du timbre, mais aussi de l'espace et du temps. En effet, plusieurs grains peuvent être utilisés simultanément pour reconstituer une morphologie spécifique stationnaire ou évolutive dans le temps. Ces systèmes granulaires peuvent aussi reconstituer une ambiance sonore en traitant chaque grain de manière indépendante. Cette approche peut aussi être utilisée pour recréer virtuellement des ambiances synthétiques imaginaires ou réelles en 3D comme la rumeur de la ville, la présence de la pluie, le crépitement du feu, le vent, etc.

La synthèse granulaire spatiale permet de composer l'espace d'une manière très dynamique et précise car il est possible de définir le type de timbre, d'intensité,
d'enveloppe, de durée et de position spatiale 3D de chaque grain pour créer différentes typologies de sons dans l'espace. Au niveau spatial, on peut créer des mouvements individuels ou collectifs. Par exemple, un son qui se crée dans un point de l'espace va pouvoir exploser ou, à l'envers, une masse dispersée peut imploser en un point. Ces mouvements de masses sonores peuvent voyager tout en transformant continûment ses paramètres, réalisant ainsi des *morphings* spatiaux (interpolation d'une forme vers une autre sur le plan de l'espace et du timbre). On peut aussi différencier différents groupes de grains pour créer des sonorités complexes et leur appliquer différents traitements comme des réverbérations pour simuler des espaces virtuels et donner plus de réalisme aux sons dans un contexte déterminé. L'utilisation des réverbérations par convolution (*Impulse Response*) dans le domaine ambisonique ouvre également un vaste champ d'expérimentation pour le son immersif.

Mon exploration de ces techniques granulaires spatiales a débuté il y a longtemps dans mes pièces électroacoustiques et mixtes, mais leur utilisation avec les techniques HOA (et orientées objet) s'approfondit dans la pièce électroacoustique *Curvatura II*. Ces problématiques sont encore davantage traitées dans la pièce audiovisuelle *Las Pintas*. Ces pièces ont pu être développées grâce au système d'écriture et de synthèse offert par la librairie AntesCollider. Ces fonctionnalités sont aussi utilisées dans le domaine des pièces mixtes, notamment dans la pièce pour ensemble instrumental et électronique en temps réel en cours de développement.

<figure><img src="image_57.png" /><figcaption>**Fig. 7.7** Visualisation de trois groupes de synthèse granulaire implémentés dans AntesCollider. La synthèse granulaire spatiale permet un traitement très expressif de l'espace grâce à ses multiples possibilités de contrôle du timbre et de l'espace.</figcaption></figure>

La synthèse concatenative par corpus [Sch07], technique de synthèse assez répandue ces dernières années, permet de composer le son à partir d'une base de données de sons
préenregistrés, segmentés et spatialement indexés par l'analyse de descripteurs audio comme la hauteur, l'énergie, l'harmonicité, le taux de bruit, etc. Ce corpus est exploité par un algorithme qui choisit les unités sonores du corpus les plus proches du son visé à partir des descripteurs<fnref n="124" />. Dans cette approche, on peut composer et explorer l'espace par rapport à des qualités sonores. Par exemple, on peut organiser la diffusion des sons dans l'espace physique en fonction de leur distribution dans l'espace des descripteurs. La flexibilité du système AntesCollider permet d'imaginer des organisations arbitrairement sophistiquées.

<figure><img src="image_58.png" /><figcaption>**Fig. 7.8** Exemple de synthèse concatenative par analyse et segmentation « à la CataRT » en 3D. Plusieurs curseurs (têtes de lecture) en 3D représentés par une sphère peuvent déclencher les segments avec l'algorithme KNN implémenté dans le langage Antescofo.</figcaption></figure>

Au-delà de la technique qui sera utilisée pour reproduire la spatialisation ou la perception spatiale, l'important est d'utiliser cet espace physique virtuel pour créer et transformer le son ou les morphologies musicales.

Une des motivations pour la création de la librairie AnteCollider est de permettre une grande liberté afin d'imaginer des scènes sonores spatiales complexes et une écriture expressive et fine de l'espace. Les *acteurs* du langage sont utilisés pour définir aussi bien la synthèse sonore que pour définir une trajectoire. Ce découplage permet une combinatoire très riche. Plusieurs approches ont été explorées pour la spécification des paramètres de contrôles ou bien des trajectoires. L'une des premières expériences a été l'utilisation des modèles physiques de contrôle PMPD (portés comme librairie dans Antescofo).

<footnote n="124">¹²⁴ AnteCollider utilise l'algorithme KNN (k-nearest neighbors algorithm) qui permet de retrouver efficacement tous les points dans un rayon donné d'un autre point (voir le chapitre II).</footnote>
Dans ce contexte, on peut aussi intégrer des techniques mises en œuvre dans certaines pièces d'Emmanuel Nunes, liant la position spatiale à un grain ou à une enveloppe.

Les approches à base de modèles physiques et leur sonification avec des systèmes particulaires comme PMPD, et l'introduction de solveurs (voir chapitre sur Antescofo) de systèmes hybrides (équations différentielles plus événements discrets) dans AntesCollider, ouvrent de nouvelles possibilités pour la synthèse et l'écriture de l'espace, possibilités qui n'ont été que très partiellement explorées.

### VII.3. Projet Stück für die Schwerkraft avec la compagnie de théâtre suisse ultra

La composition et l'écriture de l'espace peuvent aussi s'articuler dans d'autres contextes, espaces et environnements que celui d'une composition musicale. La composition spatiale peut aussi s'écrire pour un espace concret avec des objets physiques réels, comme c'est le cas du projet Stück für die Schwerkraft (Pièce pour la gravité), idée originale de la compagnie de théâtre ultra de Lucerne.

En partant de l'idée de pesanteur, de force gravitationnelle et d'objets qui chutent du ciel et se dirigent à différentes vitesses vers le bas (le centre de la terre), la compagnie a imaginé une machine capable de lâcher sur scène des objets depuis les cintres. Il s'agit d'une machine conçue par Thomas Köppel qui comporte 400 trappes dont l'ouverture de chacune est contrôlée par ordinateur. Dans ce dispositif, la scène du théâtre devient un espace concret de composition audiovisuelle spatiale dans lequel des objets tombent à différentes vitesses selon leur géométrie et leur densité. La notion de composition de l'espace ou d'écriture spatiale prend un sens littéral : il faut écrire le mouvement de chute des objets physique afin de régler les sons produits quand chaque objet percute le sol. La conception musicale et compositionnelle est donc directement liée à l'espace physique de la scène et aux trajectoires des objets.

Le travail de création de la pièce s'est articulé autour de deux résidences, la première pour définir le contexte, la dramaturgie, les objets à jeter et la programmation d'un système d'écriture simple, expressif et facile à mettre en œuvre. La deuxième résidence a été consacrée à la composition de la partie musicale/temporelle avec l'écriture de la pièce proprement dite.

Pour ce genre de projet d'écriture, on voit comment un langage de programmation du temps tel que Antescofo peut s'adapter assez facilement au contrôle de la machine. Dépassant la simple spécification de la séquence temporelle des ouvertures des trappes, le langage permet de créer des modes de jeux particuliers grâce aux processus. On peut spécifier par exemple des séquences d'ouvertures suivant des lignes ou des figures arbitraires associées à des rythmes, des accords, des contrepoints, etc., et on peut composer ces figures – par exemple en parallèle ou en séquence – ou bien les transformer temporellement – par exemple les accélérer ou bien les ralentir. La combinaison de ces modes permet une écriture riche, dynamique et fluide, bien plus expressive que la programmation de bas niveau consistant à ouvrir ou fermer les trappes.
Au niveau technique, la machine fonctionne avec 400 électroaimants qui sont pilotés par un *Raspberry Pi*. Le *Raspberry Pi* communique avec l'ordinateur de la régie centrale par OSC à l'aide d'un câble RJ-45.

<figure><img src="image_59.png" /><figcaption>Fig. 7.9 Schéma de la disposition des trappes au plafond de la scène du théâtre.</figcaption></figure>
<figure><img src="image_60.png" /><figcaption>**Fig. 7.10** Photos de la structure de la machine et son installation dans la scène de la salle de théâtre Südpol à Lucerne. Il s'agit de 50 cages en bois avec 8 trappes dont l'ouverture est contrôlée par un électroaimant. Chaque trappe est remplie avec des objets de différents matériaux.</figcaption></figure>

<figure><img src="image_61.png" /><figcaption>**Fig. 7.11** Capture d'écran du patch Max de visualisation et composition du système de 400 trappes. L'interface permet de situer les différentes trappes dans l'espace et voir le contenu de chacune. Il y a des matières « neige », différentes tailles de billes, des rondelles en métal et « fx » qui correspond à différents éléments comme des punaises, petits objets en métal, des papillons en métal, etc. Les panneaux de la machine sont séparés en 4 colonnes de gauche à droite avec des coordonnées pour chaque trappe. La première colonne a plus de densité d'éléments au centre, la deuxième plus de densité aux bords, la troisième plus au centre et la quatrième plus aux bords.</figcaption></figure>
<figure><img src="image_62.png" /><figcaption>Fig. 7.12 Quelques processus pour jouer la machine avec différents modes pour créer des figures, par exemple des colonnes, des lignes, des régions avec des rythmes ou en accords.</figcaption></figure>
```python
424 group
425 { 
426 group @tempo 45
427 {
428 label INIT
429     ::play0([25, 6])      //BB6 1
430     30 ::play0([15, 6])    //BB4 1
431     40 ::play0([3, 12])    //BB3 1
432     20 ::play0([24, 6])    //*neige 1
433     20 ::play0([20, 1])    //*neige 1
434     20 ::play0([4, 11])    //*neige 2
435     17 ::play0([20, 2])    //*neige 1
436     19 ::play0([8, 5])      //*neige 2
437     4 ::play0([28, 6])      //*neige 1
438     4 ::play0([4, 1])       //*neige 1
439     //174 / 02:54
440     40 ::play0([8, 6])      //*neige 1
441     4 ::play0([16, 12])     //*neige 1
442     4 ::play0([0, 1])       //*neige 1
443     4 ::play0([20, 12])     //*neige 1
444     4 ::play0([0, 12])      //*neige 1
445     4 ::play0([16, 1])      //*neige 1
446     4 ::play0([12, 6])      //*neige 1
447     4 ::play0([13, 6])      //*BB5 1
448     2 ::play0([19, 11])     //*BB3 2
449 }
450 //mini premier klimax
451 +=> 20 ::play0([0, 2])      //neige 2
452     3 ::play0([8, 8])        //neige 2
453     5.5 ::play0([8, 4])      //neige 3
454     7.5 ::play([19,1, 19,3, 19,5, 19,9], 0.58) //BB3 1 / BB3 3 / BB3 ++ / BB3 +
455 //rytm
456     30 ::play([0, 10, 3, 10, 6, 10, 9, 10, 12, 10, 15, 10, 18, 10, 21, 10, 24, 10, 27, 10,
457     2 ::play0([31, 7])        //*BB add 1
458     // 2 ::play0([21, 6])      //*BB6 ++
459     2 ::play0([11, 0])        //*BB add back 1
460     2 ::play0([13, 7])        //*BB add 1
461     2 ::play0([12, 7])        //*BB add 1
462     2 ::play0([12, 0])        //*BB add back 1
463     2 ::play0([1, 1])         //*BB6 1
464     2 ::play0([8, 0])         //*BB add back 1
465     2 ::play0([11, 7])        //*BB add 1
466     2 ::play0([27, 6])        //*BB3 1
467     2 ::play0([13, 0])        //*BB add back 1
468     2 ::play0([27, 7])        //*BB add 1
469     2 ::play0([14, 0])        //*BB add back 1
470     2 ::play0([17, 1])        //*BB1 1
471     2 ::play0([5, 0])         //*BB add back 1
472     2 ::play0([28, 7])        //*BB add 1
473     2 ::play0([4, 0])         //*BB add back 1
474     2 ::play0([19, 12])       //*BB3 1
475     2 ::play0([14, 7])        //*BB add 1
476     2 ::play0([15, 0])        //*BB add back 1
477     2 ::play0([3, 1])         //*BB3 1
478     2 ::play0([6, 0])         //*BB add back 1
```

<caption>**Fig. 7.13** Extrait du début de la partition électronique de la pièce *Stück für die Schwerkraft* pour 400 trappes. Le tempo du premier group à la ligne 426 est variable pour accélérer ou ralentir le début de la pièce. À la ligne 451, on retrouve un opérateur de continuation « +=> » pour commencer à jouer juste après la fin du premier groupe d'actions. Toutes les fonctionnalités du langage Antescofo vont permettre de créer très facilement un environnement de programmation pour contrôler la machine et ses 400 trappes.</caption>
<figure><img src="image_63.png" /></figure>

<figure><img src="image_64.png" /></figure>

<figure><img src="image_65.png" /></figure>

<figure><img src="image_66.png" /></figure>
**Fig. 7.14** Différents états du dispositif lors de *Stück für die Schwerkraft*. En haut, le début de la pièce, deux états intermédiaires au cours de la performance puis l'état final avec tous les objets par terre.
# VIII. Musiques acousmatiques

## VIII.1. Orchestration de l'électronique dans les pièces électroacoustiques

Dans ma pièce acousmatique *Fond diffus*<fnref n="125" />, mon but était de confronter le monde du son électroacoustique et de la synthèse à une approche orchestrale de l'écriture de l'électronique. Cet objectif implique une écriture précise de la superposition de couches sonores avec plusieurs échelles temporelles ainsi qu'une écriture très détaillée de la synthèse sonore et de la spatialisation.

Ce travail déjà ancien a été le point de départ d'une réflexion plus profonde sur la notation de l'électronique dans un langage de programmation textuel plutôt qu'à travers la représentation graphique des événements musicaux sur une ligne temporelle dans une station audionumérique (DAW). La figure suivante présente un extrait de la session.

<figure><img src="image_67.png" /><figcaption>**Fig. 8.1** Capture d'écran de la session Logic de la pièce électroacoustique *Fond diffus* avec plus de 150 canaux audio.</figcaption></figure>

La composition dans un DAW est conditionnée par l'utilisation d'une vue graphique et des proportions spatiales relatives des clips qui représentent les sons. La structure interne des sons est fixe et ne peut pas être modifiée une fois les sons enregistrés.

<footnote n="125">¹²⁵ *Fond diffus*, pièce électroacoustique 24 canaux créée au ZKM à Karlsruhe en 2012, Prix résidence Musiques & Recherches.</footnote>
Lorsque l'on calcule le rendu final de la pièce, l'espace de diffusion et de réverbération est fixé.

Toutes ces considérations et ces limitations rendent impossible le développement de pièces électroacoustiques en temps réel dans lequel le matériel électroacoustique doit pouvoir être modifié à tout moment avec des superpositions temporelles et des interactions complexes.

Ces limitations m'ont amené à utiliser AntesCollider pour pallier ces problèmes.

## VIII.2. Pièces électroacoustiques jouées en live, entre écriture et improvisation

La musique électroacoustiques ou acousmatique se caractérise principalement par une composition en *temps différé*, hors temps d'exécution, et fixée sur bande ou sur un support informatique. Bien que cette musique puisse présenter une grande liberté (rythmes, timbres, morphologies...) dans sa conception/composition, le résultat est fixé sur un support et ne peut pas être modifié en cours de diffusion. Il est certes possible d'interpréter la diffusion avec des haut-parleurs, comme c'est le cas des œuvres jouées sur un acousmonium, pratique répandue dans le milieu de la musique acousmatique. Cette interprétation consiste principalement à moduler la diffusion d'une bande en choisissant les haut-parleurs de diffusion dans un ensemble réunissant différents types et différents modèles (acousmonium). Ce choix permet de jouer sur la position, la spatialisation ou encore le timbre et apporte un relief supplémentaire à l'écoute. Si la musique se renouvelle à chaque fois du fait de son interprétation, celle-ci reste limitée à une petite partie du contenu musical.

L'idée de jouer la musique électronique en « live » redonne à la musique son caractère d'art de l'instant (avec tout ce que cela implique : spontanéité, accidents, interactions de l'environnement, etc.). Dans le domaine de la musique électronique live, on trouve principalement des musiques improvisées (ou pseudo-improvisées) ou encore des musiques avec une composante très écrite dans laquelle seuls quelques paramètres sont variables et seront modifiés au cours de l'interprétation de la pièce. Il y a aussi des cas dans lesquels la musique est entièrement écrite et interprétée par un instrumentiste électronique comme dans le cas d'une partition de musique acoustique écrite.

Ma démarche dans la pièce acousmatique *Curvatura II*, et surtout dans la pièce audiovisuelle *Las Pintas*, se positionne à la frontière de ces différentes modalités dans le sens où bien que tout soit complètement écrit dans une partition électronique, l'interprète peut à tout moment intervenir et orienter le déroulement musical dans la limite de certaines modifications rendues possibles à certains endroits spécifiques de la partition. La caractéristique principale de ces pièces électroacoustiques est qu'elles sont générées en temps réel par l'ordinateur, ce qui leur confère une très grande liberté et flexibilité lors de la diffusion. Voici quelques modifications possibles au cours de la diffusion par un interprète ou via d'autres dispositifs :
* modification des processus de génération d'événements musicaux, par exemple plus ou moins de densité d'éléments ou modification des synthèses sonores et des traitements ;

* modification des synthèses et des traitements à partir des données de l'extérieur comme de la vidéo (dans le cas de la pièce *Las Pintas*);

* modification de la spatialisation pendant la performance ;

* modification de l'espace sonore à travers le changement des réverbérations locales et globales de la composition ;

* modification du dispositif de diffusion, par exemple en changeant le décodeur ambisonique pour l'adapter au système qui sera utilisé pendant la performance<fnref n="126" />.

### VIII.3. Curvatura II

*Curvatura II* est une composition acousmatique générée en temps réel dans un système de spatialisation HOA. Elle est d'abord une exploration, une recherche sur la création de différentes superpositions de couches sonores et sur la transformation du matériau sonore à travers le temps et l'espace. La courbure du temps réalisée à travers la déformation continuelle des tempi (*accelerandos*, *rallentandos*, modulations) et des paramètres de la synthèse du son ainsi que de leurs superpositions génèrent aussi bien la micro- que la macro-structure de la pièce. La superposition de ces éléments en constante transformation et leurs mutations donne naissance à des agrégats sonores à partir desquels émerge un effet sonore et perceptif global qui, en même temps, construit la directionnalité et la trajectoire du discours musical.

Au niveau technique, la pièce est entièrement écrite dans le langage de programmation Antescofo en utilisant la librairie AntesCollider, ce qui permet, d'une part, de jouer avec des transformations et des superpositions temporelles en temps réel et, d'autre part, d'avoir un contrôle fin de tous les paramètres de synthèse et de spatialisation du son. Cette écriture et cette génération en temps réel vont permettre aussi de modifier des paramètres comme la spatialisation pour adapter la diffusion à différentes configurations et systèmes de diffusion, mais aussi pour moduler des paramètres perceptifs comme les réverbérations. Cette approche temps réel permet la prise en compte de paramètres inconnus lors de la composition comme la taille de la salle ou des égalisations et autres traitements spécifiques en fonction de l'acoustique du lieu. La pièce peut de cette façon se réadapter à chaque fois au lieu où elle sera reproduite, ce qui amène une flexibilité qui n'est pas possible avec une musique fixée.

<footnote n="126">¹²⁶ Ceci est rendu possible car toutes les descriptions spatiales sont exprimées en coordonnées cartésiennes ou polaires indépendamment du système de diffusion et donc transposables sur n'importe quel système.</footnote>
Au niveau rythmique, la pièce réalise des superpositions de différents tempi qui peuvent être statiques, en *accelerando* ou en *rallentando*. Dans certains passages, il peut y avoir jusqu'à une trentaine de voix en parallèle, chacune avec ses propres rythme et tempo. Des mouvements plus globaux peuvent être réalisés en modulant un ou plusieurs tempi par un autre tempo global qui à son tour peut lui aussi être modulé. Cette possibilité faisant dépendre des tempi « fils » d'un tempo « parent » permet d'organiser les interactions temporelles en hiérarchies, les niveaux hauts permettant d'avoir un contrôle plus global et les niveaux bas, un contrôle plus fin sur les fils.

<figure><img src="image_68.png" /><figcaption>**Fig. 8.2** Représentation graphique de la modulation des tempi pour les événements et les processus musicaux ; le tempo 1 et le tempo 2 (fils) ont leur propre tempo qui module dans le temps. Le tempo 0, le tempo global « parent » à son tour module les deux tempi « fils » 1 et 2, ce qui permet de générer des modulations imbriquées avec une relation et une interaction entre les tempi.</figcaption></figure>

<figure><img src="image_69.png" /><figcaption>Fig.</figcaption></figure>

8.3 Représentation graphique d'un extrait de 30 secondes de *Curvatura II* d'une couche temporelle. Chaque losange représente une synthèse granulaire qui joue des rythmes générés à partir de probabilités de manière fixe, en *accelerando* ou en *rallentando*.
# IX. Musiques mixtes

## IX.1. La captation gestuelle

Le geste comme producteur des sons électroniques existe depuis un siècle (Thérémine 1919, Ondes Martenot 1927). À l'Ircam et dans la tradition des musiques mixtes, les recherches commencent dans les années 1980, notamment avec les travaux de Barry Vercoe et du flûtiste Larry Beauregard avec une flûte MIDI qui incorporait des interrupteurs optiques pour connaître l'état d'ouverture ou de fermeture des clés. L'objectif était de réaliser un suivi de partition, identifié comme un composant clé pour réaliser un accompagnement automatique<fnref n="127" />.

À partir des années 2000, avec l'avènement de matériels plus accessibles et miniaturisés pour la captation des gestes des instrumentistes, l'utilisation de ces technologies de captation a commencé à intéresser directement les compositeurs. Des musiciens s'y sont aussi intéressés afin d'étendre les possibilités de jeux de leur instrument pour en faire des « instruments augmentés ».

Comme le microphone pour la captation du signal audio, la captation gestuelle dans la pratique des musiques mixtes a permis une description en temps réel des événements musicaux joués par les instrumentistes. Cette description peut être analysée et utilisée pour différentes opérations de production du son. La captation gestuelle vient ainsi compléter l'analyse du jeu instrumental avec des paramètres que les seules données audio ne peuvent pas fournir – comme la vitesse et le sens du mouvement des mains, la préparation et l'accompagnement du geste instrumental (par exemple chez les percussionnistes), les mouvements dans l'air, les déplacements sur la scène, les positions relatives et absolues des mains ou des archets pour les cordes, etc.

### Les capteurs

Parmi les différents types de capteurs (optiques, mécaniques, magnétiques, etc.) utilisés en musique mixte, j'ai surtout travaillé avec des IMU (Inertial Measurement Unit) comme les accéléromètres ou les gyroscopes, mais aussi avec les magnétomètres permettant de caractériser une orientation absolue. Les capteurs optiques, notamment avec les capteurs infrarouges (comme la Kinect, caméra conçue pour capter les mouvements du corps), ont aussi beaucoup été utilisés pour compléter les données d'accéléromètre et obtenir une position absolue des mains ou du corps du performeur (musicien, danseur ou comédien).

<footnote n="127">¹²⁷ https://www.youtube.com/watch?v=vOYky8MmrEU</footnote>