imitative ou d’un son de synthèse pour une orchestration générative. Le compositeur doit en outre préciser la composition de l’orchestre qu’il utilise, et est libre de spécifier un ensemble de contraintes supplémentaires sur les attributs des solutions qu’il souhaite obtenir (voir sec-tion 7.5 et chapitre 10).
L’algorithme d’orchestration, que nous avons présenté au chapitre 9, va alors chercher selon les critères de timbres proposés en 8.1.2 un ensemble de configurations efficientes, en optimisant les distances entre leurs descripteurs et ceux de la cible. Au cours de cette recherche, un solveur de contraintes (voir chapitre 10) s’assure que les configurations proposées sont consistantes avec le réseau de contraintes définies par le compositeur.
Une fois la recherche terminée, une interface de navigation permet au compositeur d’ex-plorer l’ensemble des configurations efficientes trouvées par le système, selon plusieurs points de vue. Espaces de décisions, espace des descripteurs et espace de critères (voir section 7.6) sont simultanément accessibles à l’utilisateur, et ce de façon croisée (les déplacements dans un espace se propageant dans les deux autres). Couplé à cette interface, un échantillonneur per-met, grâce aux échantillons instrumentaux de la base de données, de simuler les propositions d’orchestration.
L’interface de navigation incorpore les mécanismes d’inférence des préférences de l’utili-sateur introduits à la section 7.2.4. Le compositeur a la possibilité de relancer la recherche à partir d’une solution intermédaire ; dans ce cas, le système privilégie la combinaison de cri-tères qui a implicitement présidé au choix de cette solution. Tout se passe donc comme si la recherche s’intensifiait dans son voisinage. L’utilisateur peut également éditer manuellement les solutions, ainsi que les transformer par ajout de contraintes suppémentaires.
La figure 12.1 montre que le signal audio intervient de façon privilégiée dans la communi-cation entre le compositeur et l’outil d’orchestration, que ce soit au niveau de la construction de la cible ou de l’exploration des solutions. Ce « primat du sonore » permet d’éviter le recours à un vocabulaire peu précis pour la caractérisation du timbre, et de se cantoner aux symboles usuels de l’écriture musicale (hauteurs, intensités, mode de jeu,. . .). De plus amples détails sur l’interaction avec l’outil seront donnés au chapitre 13.
12.2 Composantes héritées des outils existants
Nous avons vu au paragraphe 4.1 que l’aide à l’orchestration est un domaine de recherche au carefour de nombreuses disciplines. Le contrôle du timbre dans un environnement de composi-tion assistée par ordinateur impose d’établir une connexion entre la représentacomposi-tion symbolique des structures musicales et les connaissances récentes en psychoacoustique et en description du signal audio. En outre, de larges banques d’échantillons sonores sont nécessaires pour la modélisation des possibilités instrumentales, et éventuellement la simulation d’orchestrations. Le développement d’un environnement d’aide à l’orchestration passe donc par l’intégration de toutes ces compétences au sein d’un même outil. C’est une tache évidemment impossible à accomplir seul dans le cadre d’une thèse de recherche. Il n’est donc pas surprenant que dans sa version actuelle, notre prototype utilise un certain nombre d’outils existants et nécessite l’exécution — en parallèle de Matlab c — d’autres programmes. Il s’agit là d’une contrainte lourde : en informatique musicale, les utilisateurs n’adoptent en général une technologie que si l’ensemble des opérations qui lui sont rattachées sont réalisables dans un unique environne-ment, où si cette technologie communique de manière souple (par exemple via une architecture maître/esclave, en général sous forme de « plug-in ») avec un environnement de référence.
180 CHAPITRE 12. PROTOTYPE ACTUEL
Analyse d'un son Mapping des fondamentales Connaissance instrumentale MaxMSP Matlab OpenMusic pm2 Disque dur Construction de cible abstraite (orchestration générative) Construction / édition de cible concrète (orchestration imitative) Recherche d'orchestrations Exploration / transformation des solutions d'orchestrations OSC OSC Extraction des partiels principaux (pm2) SDIF Sampler Editeur Echantillons OSC OSC
Fig. 12.2 – Prototype d’aide à l’orchestration : espace disque et outils existants nécessaires. Les communications internes sont en pointillés ; celles par fichier ou par OSC sont en traits pleins.
Nous sommes aujourd’hui loin de cette encapsulation idéale des technologies. Nous ne pouvons pas même dire si, dans sa version finale, l’outil d’orchestration sera un programme à part entière (standalone), un « plug-in », ou une bibliothèque (mais dans quel langage ?) dans l’environnement de CAO OpenMusic [Ago98]. En vérité, nous pensons qu’il faut d’abord en passer par une phase conséquente d’expérimentation auprès des compositeurs avant de décider d’une architecture finale et d’une stratégie de développement ; car ces dernières devront être suffisamment souples et visionnaires pour intégrer les résultats de recherches futures.
En attendant, nous tirons parti des technologies existantes et implémentons, de ma-nière rapide et sûre, les modules « satellites » de notre outil au sein d’environnements tels qu’OpenMusic ou Max/MSP [Puc91]. Quant à Matlab c, nous y réservons le cœur de notre recherche : optimisation combinatoire multicritère (chapitre 9), gestion des contraintes (chapitre 10), et interfaces de navigation dans les propositions d’orchestration (chapitre 13).
La figure 12.2 résume l’ensemble des interactions entre Matlab c d’une part, les techno-logies et bases de données disponibles aujourd’hui à l’IRCAM d’autre part.
Comme on peut le constater, la majeure partie des modules externes ont été développés dans Max/MSP [Puc91], un environnement conçu à l’IRCAM par Miller Puckette à la fin des années 80. Comme OpenMusic, Max/MSP établit une correspondance entre un programme et sa représentation graphique sous forme de boîtes connectés entre elles au sein d’un « patch ».
12.2. COMPOSANTES HÉRITÉES DES OUTILS EXISTANTS 181
Mais là où OpenMusic permet, à travers des structures de données complexes, un haut niveau d’expressivité pour la programmation, Max/MSP propose un langage plus pauvre, mais d’une très grande efficacité pour le contrôle et le traitement du signal en temps réel. OpenMusic est donc préféré pour la composition, tandis que Max/MSP est utilisé avant tout dans des contextes performatifs.
En ce qui nous concerne, Max/MSP s’est naturellement imposé pour la conception des interfaces dans lesquelles circulent des flux audio : analyse du son cible, simulation des propo-sitions d’orchestration (sampler ), édition des solutions. Dans les deux derniers cas, la difficulté est de déclencher la lecture simultanée de plusieurs échantillons de la base de sons. Cet ordre peut être passé aussi bien depuis Matlab c que Max/MSP, et la lecture doit commencer aussitôt après, sans quoi l’interaction avec le compositeur à travers une écoute des proposi-tions d’orchestration n’est pas possible. La rapidité de Max/MSP en termes d’accès disque et de chargement des buffers audio et sa grande facilité d’utilisation (due au paradigme de pro-grammation visuelle) permettent de satisfaire ces exigences tout en économisant de fastidieuses heures de développement. Par ailleurs l’aspect modulaire de Max/MSP permet d’imaginer un certain nombre de traitements possibles (individuels ou collectifs) sur les échantillons impliqués dans une orchestration : modification continue de paramétres de jeu (intensité, hauteur. . .), modulations (vibratos, tremolos. . .), déplacements dans l’espace (à l’aide du spatialisateur Spat [Jot97] par exemple). Ces « mouvements » permettent, à travers un processus interactif d’essais/erreurs, de créer des timbres dynamiques ; ils correspondent à des paramètres tradi-tionnels de l’écriture musicale. D’autres traitements sont également envisageables, si le son des échantillons est pensé comme une « matière ». A l’instar du compositeur Gérard Buquet (voir section 14.5), on peut en effet utiliser l’aide à l’orchestration comme un environnement de production sonore.
La souplesse et la rapidité dans la gestion des flux audio ne sont pas les seules raisons du choix de Max/MSP. Cet environnement comporte également un certain nombre d’« objets » prédéfinis, tels que le clavier de piano ou la représentation d’un accord sous forme de partition, qui permettent d’agir de façon rapide et intuitive sur le paramétrage d’une orchestration. Ces éléments sont particulièrement utiles pour le « mapping de fondamentales » opération qui consiste à « expliquer » le spectre de la cible par un ensemble de spectres harmoniques (pour plus de détails, voir sections 13.1 et A).
Les communications entre Matlab c et Max/MSP se font par échange de fichiers tem-poraires ou par messages OSC (OpenSound Control ) [WFM03]. Développé au CNMAT1
, OSC est un protocole de communication entre ordinateurs, synthétiseurs et contrôleurs multimédia, basé sur la norme UDP2 et optimisé pour les technologies organisées en réseaux.
Nous avons insisté au paragraphe 7.1.1 sur la nécessité de trouver une alternative à l’orches-tration imitative, dans laquelle le timbre cible est donné par le compositeur sous forme d’un son enregistré. Nous avons proposé pour cela le concept d’orchestration générative : à partir d’un matériau musical symbolique (un accord par exemple), le compositeur va générer un son de synthèse dont les caractéristiques sont déterminées par des paramètres de haut niveau. Modifiable à souhait jusqu’à l’obtention d’un timbre satisfaisant, ce son est alors considéré comme la cible d’un problème d’orchestration imitative. D’un point de vue formel, il s’agit d’une abstraction : lisse et froid, ce son de synthèse est un « portrait-robot » qui cristallise les propriétés acoustiques du timbre recherché. Face à la difficulté de caractériser verbalement le
1
Center for New Music and Audio Technology, Université de Californie, Berkeley.
2
182 CHAPITRE 12. PROTOTYPE ACTUEL
Fig. 12.3 – Construction d’une cible dans OpenMusic à l’aide de paramètres exclusivement symboliques (orchestration générative).
timbre (voir chapitre 2 et section 7.1.1), c’est encore le moyen de s’entendre sur une « idée de timbre ».
Cette piste de travail a été explorée en parallèle de nos travaux, en collaboration avec Jean Bresson, chercheur à l’IRCAM dans l’équipe Représentations musicales, et en charge notamment du développement d’OpenMusic. OpenMusic (OM) est un environnement de CAO basé sur la programmation visuelle et doté d’un haut niveau d’expressivité. Il permet la mise en relation d’objets musicaux (symboliques ou concrets) au travers d’un ensemble de « boîtes » interconnectées au sein d’un « patch », et formalisant un processus compositionnel (voir la figure 14.2 pour un exemple de patch OM).
Un objet sound-target (voir figure 12.3) a donc été implémenté dans OM : il prend en entrée un accord (objet chord) et propose un ensemble d’outils pour sa « spectralisation » : chaque note est assortie d’un spectre dont les caractéristiques (enveloppe, inharmonicité, fré-quences et amplitudes des partiels. . .) sont aisément éditables. Un spectre complexe peut ainsi être construit, puis affiné par un filtre global avant d’être « rendu » par un moteur de synthèse additive dans CSound [Bou00]. Le compositeur peut ainsi « construire » le timbre recherché à travers un processus itératif. Une fois satisfait, le son cible est « envoyé » au système d’aide à l’orchestration par un message OSC.
L’extraction des descripteurs du son cible se fait d’une part grâce au programme ircamdes-criptor de Geoffroy Peeters [Pee04] (développé en Matlab c), d’autre pat via la commande pm2 [Rod97] qui sert en partie de noyau au logiciel AudioSculpt [BR05]. Dans l’état actuel