21. SEQUENCEUR D'ORCHESTRATION
6.3 Conclusions sur la programmation des orchestrations
Dans les paragraphes précédents, nous avons vu que nous avions utilisé la plupart des instructions5 HipHop.js. Si nous nous contentons de traduire une représentation graphique en HipHop.js, il est possible de réaliser des orchestrations avec un nombre réduit d’instructions. Des orchestrations simples, donnant des résultats musicalement satisfaisants, peuvent se construire avec des
5await, count, immediate, emit, abort, weakabort, loop, fork, par, hop, every, break, val,
preval, now, yield et run. Parmi les commandes que nous n’avons pas rencontrées dans ces exemples il reste essentiellement sustain et suspend que nous utilisons pour des cas complexes de dépendances entre sessions.
92
instructions emit et await, en séquence ou en parallèle, entourées d’instructions abort par exemple. Dans ce cas, ce qui caractérise notre programmation d’orchestration n’est donc pas la complexité de la programmation HipHop.js. Les automates que nous avons vus dans ce document ne sont pas très difficiles à comprendre avec la syntaxe de HipHop.js. En revanche, nos programmes destinés à des orchestrations riches se traduisent par des automates avec un nombre d’états très important (jusqu’à 10 000 pourl’Opus2). Ce qui signifie que sous une apparente simplicité de struc- ture du programme, l’automate généré est très complexe et serait ingérable avec un langage géné- raliste. Cette simplicité d’expression est un des apports importants de l’expressivité de HipHop.js à notre projet. Ce volume élevé d’états est lié à l’utilisation d’un nombre important de signaux. Dans le cas de l’Opus 1 par exemple, nous avions 72 groupes de patterns, ce qui donne 144 signaux OUT et IN à gérer pour un seul automate d’orchestration. Ceci nous a posé initialement des problèmes de performance, car si l’automate est censé s’exécuter en temps nul d’un point de vue théorique, l’activation d’un automate avec beaucoup d’états peut prendre un temps non négligeable au regard des contraintes de déroulement de l’orchestration. Pour que le comportement de l’automate soit perçu en temps nul, il faudra que son temps d’exécution soit inférieur à l’intervalle de temps qui sépare deux appels. Les appels à l’automate d’orchestration sont réalisés à un intervalle de temps qui est défini comme un multiple de la pulsation du métronome. Le métronome est fixé par le
tempo de la pièce musicale. Comme nos orchestrations produisent des automates avec beaucoup
d’états, au début de nos travaux les durées d’exécution des automates n’étaient pas négligeables vis-à-vis des cycles d’appel. Dans un premier temps ceci a limité le type de traitement que l’orches- tration pouvait contrôler. Fort heureusement, le compilateur s’est considérablement amélioré, ren- dant possibles certains scénarios impossibles initialement. Néanmoins si la simplicité d’expression d’automates volumineux est un point important, il n’est qu’une première étape dans la relation circulaire entre outil informatique et création musicale. HipHop.js avec son catalogue d’instruction est aussi source de propositions. Ainsi, initialement nous n’avions pas utilisé les commandes sus- tain et suspend. Nous n’avions pas trouvé un usage immédiat de ces instructions pour traduire nos représentations graphiques. C’est en nous interrogeant sur leur sens que nous nous sommes demandé ce qui pourrait être suspendu ou maintenu dans le déroulement d’une orchestration. C’est de cette question que nous est venue l’idée de contrôler des interactions entre sessions en prenant en compte des événements très particuliers, comme des sélections de patterns uniques pouvant perturber en profondeur le déroulement d’une session en introduisant une autre session en parallèle, en interrompant ou pas celle en cours. Nous n’avons pas donné d’exemple de ce type de codage pour ne pas alourdir nos présentations de programmation d’orchestration, nous avions cependant évoqué leur existence en commentaire de la Figure 9: Exemple de superposition de ses- sions, p.51. En allant encore plus loin sur les enchevêtrements de sessions, pourquoi ne pas imagi- ner des événements particuliers ayant des probabilités faibles de se produire, mais qui remettraient en cause l’enchaînements des sessions, les interrompant, les réinitialisant, les mettant en paral- lèles, etc. Ainsi ces deux instructions nous permettent d’imaginer des scénarios originaux qui auront pour caractéristique de ne pas pouvoir s’exprimer graphiquement. Nous pouvons aussi imaginer qu’en mettant en œuvre des scénarios variés de combinaison de sessions, nous ouvrions d’autres pistes musicales nécessitant de penser d’autres formes d’algorithmes, continuant ainsi le processus dialectique entre outil et création. Toujours dans le registre de l’impact de l’outil sur la création, la sémantique de HipHop.js, issue d’Esterel, sous-entend qu’il sera possible de faire des preuves sur l’orchestration et notamment de vérifier que certains scénarios sont impossibles. La mise en œuvre de « preuves », c’est-à-dire la vérification formelle que certains états sont possibles ou non, sera certainement un compagnon d’un nouveau type pour le compositeur de musique interactive selon nos principes. Imaginons qu’un compositeur souhaite être certain qu’un groupe de flûte ne puisse
93
pas être sélectionner avec un groupe de trombone. Cette vérification sera pratiquement impossible à faire « à la main » pour une orchestration un peu complexe. Un outil de preuve pourra la faire. Pour conclure ce chapitre sur la programmation, nous pouvons constater que HipHop.js est en l’état proche d’un DSL musical. Nous avons démontré que l’expressivité de HipHop.js est adaptée à notre objectif et qu’elle est aussi une source de propositions pour le compositeur. Il serait néanmoins possible de concevoir une évolution de HipHop.js encore plus adaptée à la musique en travaillant sur une intégration plus approfondie avec les mécanismes d’interaction et de simulation que nous verrons par la suite. On peut aussi imaginer une traduction vers HipHop.js d’une représentation graphique de l’orchestration. Cette traduction n’offrirait pas le même champ de possibilités qu’une programmation en HipHop.js, mais rendrait notre méthode accessible à des musiciens non infor- maticiens. En effet, la souplesse qu’apporte HipHop.js ne doit pas faire oublier que programmer avec un langage réactif « à la Esterel » peut devenir difficile dès que l’automate se complexifie. La gestion des cycles de causalité est une des difficultés inhérentes à la programmation HipHop.js que nous avons rencontrée régulièrement et qui est difficile à maîtriser.
Nous avons posé les bases de notre méthode de composition et vu sa relation avec la programma- tion HipHop.js, il s’agit à présent de l’évaluer musicalement et donc de mettre en œuvre la durée, en donnant vie aux orchestrations. C’est ce que nous allons voir dans les chapitres suivants tout d’abord au travers des interfaces avec une audience, puis à l’aide d’un outil de simulation.