La CAO met en Ïuvre des techniques de calcul numériques et symboliques permettant de modéliser certains aspects d'une Ïuvre musicale tels que l'harmonie, le contrepoint, la structure temporelle, le rythme, etc. Avant d'essayer de caractériser plus précisément la CAO, nous allons commencer par un court rappel historique sur les principaux mouvements de ce siècle dans la CAO.
1.1. Bref parcours historique.
Nous pouvons situer les premières expériences d'utilisation de l'ordinateur dans la composition musicale vers le milieu des années 50. En 1956 R. C. Pinkerton propose un système de composition qu'il appela le " banal tunemaker ". Il utilisa 39 mélodies précomposées qui servaient de matériau à un processus aléatoire qui les mettait en séquences. Apparemment Pinkerton n'a pas été très satisfait par ses résultats et il ne semble pas qu'il ait implémenté ses expériences. Par contre le travail de Pinkerton ainsi que l'implantation du jeux de dé de Mozart par D. A. Caplin en 1955 ont été des sources d'inspiration pour J. Cohen et J. Sowa dans leur construction de la " Machine to Compose Music ". Cette dernière utilisait comme matériau un ensemble de pièces monodiques pour piano soigneusement préparées. Ce type de procédé que l'on peut résumer en trois étapes : la sélection du matériau, la combinaison aléatoire et les choix de résultats, laissa voir rapidement que l'ordinateur n'a aucun rôle à jouer dans la troisième phase, chose qui de nos jours reste vraie.
Personne ne discute la paternité de Hiller sur la composition automatique avec ordinateur [Hill69]. L. Hiller en compagnie de L. Issacson et R. Baker créent en 1957 la première pièce composée avec ordinateur : " Illiac suite for String Quartet ". La suite Illiac est le résultat d'expériences qui consistaient en le choix d'éléments musicaux parmi une quantité presque illimitée de matériau brut. Hiller argumente sa composition par une démarche soustractive en utilisant le langage de la théorie de l'information ou théorie générale de systèmes très à la mode à l'époque : "...le processus de composition musicale peut être caractérisé comme l'extraction d'ordre d'une multitude chaotique de possibilités disponibles...". Les expériences conduites pour la suite Illiac ne sont pas éloignées du paradigme de Pinkerton, cependant Hiller introduit des innovations dignes d'être mentionnées. Le matériau de base pour la suite Illiac est généré dynamiquement et en grandes quantités avec l'utilisation de l'algorithme de MonteCarlo. L'algorithme de MonteCarlo génère des nombres qui sont codifiés et associés à différents paramètres musicaux comme des hauteurs, des intensités, des groupes rythmiques et même des modes de jeu. Une fois associés, les paramètres sont soumis à un ensemble de règles compositionnelles (inspirées des travaux de J. J. Flux en 1725, basés sur les traités harmoniques de Palestrina). C'est une des innovations introduites dans la suite Illiac, car à différence des premiers travaux où le choix était fait en regardant dans des tables, dans les travaux de Hiller ce sont les règles qui déterminent la validité ou non du matériau. Les règles ont été implémentées en utilisant la technique des chaînes de Markov. Nous allons donner un exemple pour illustrer l'utilisation de cette technique dans le domaine musical : supposons que nous prenons une mélodie existante et que nous construisons une table dans laquelle, pour chaque note nous calculons les probabilités qu'elle soit suivie par chacune des autres notes de l'échelle dodécaphonique. Une fois la table construite nous pouvons, en partant d'une note quelconque, produire différentes mélodies tout en respectant les probabilités établies, produisant ainsi un ensemble de mélodies qui partagent certains intervalles avec la mélodie d'origine. De manière analogue, nous pouvons refaire l'expérience en créant la table sans avoir besoin d'une mélodie donnée a priori. Cet exemple montre une utilisation simple d'une chaîne de Markov. En effet, l'exemple ne prend en compte que le prédécesseur immédiat de chaque nouvelle note. On parle alors, d'une chaîne de Markov de degré 1. Les règles de Hiller sont plus compliquées que notre exemple, ainsi dans les règles de composition il y a en général des relations de degré n. Il faut signaler que plus grand est le degré dans la chaîne de Markov, plus il y a d'ordre dans le choix. La recherche de Hiller nous semble plus intéressante sur le plan de l'ingénierie musicale nouvelle que sur le plan du résultat artistique. Elle ouvre le champ de la composition automatique qui est toujours vivant en particulier aux Etats-Unis.
Les travaux menés par P. Barbaud et R. Blanchard en France au début des années 60 ont une place importante dans l'histoire de la CAO [Barb68]. " 7! ", datée de 1960, est reconnue comme la première Ïuvre réalisée par ordinateur en France. De même que pour Hiller, Barbaud reprend les théories aléatoires pour construire ses pièces, en argumentant sur le fait que la musique oscille entre l'ordre et le désordre. Cependant il va plus loin dans la manière dont le compositeur traduit ses idées dans un langage propre aux machines. Les travaux de Barbaud reposent sur la théorie des ensembles, qui sert de base pour l'analyse du langage tonal. On définit par exemple les demi-tons par Z/12 et l'opération de transposition par l'addition. D'autres acteurs du langage tonal comme les gammes, les accords, etc. sont réduits à des ensembles ou à des ensembles d'ensembles. L'Ïuvre automatique chez Barbaud est le résultat de l'application de divers types de règles sur des données exprimées sous la forme d'ensembles. Les règles sont exprimées en utilisant des automates finis ou des matrices stochastiques. À l'aide de ce dispositif, Barbaud peut générer du contrepoint avec harmonisation et contrôler jusqu'à un certain point l'imitation stylistique. Avec cette vision ensembliste cependant, le problème du temps musical est sujet à diverses questions, car la seule façon de parler du temps est la succession d'événements, ce qui implique un temps strictement linéaire et irréversible, nous reviendrons à ce sujet tout au long du chapitre 3 de cet ouvrage. Les travaux de Barbaud mettent en évidence que le calcul d'une série dodécaphonique, solution d'un certain nombre de contraintes, est un travail digne d'être exécuté par un ordinateur. Chez Barbaud, plus que dans les expériences précédemment mentionnées, il existe une démarche artistique qui nous semble intéressante. En effet, le compositeur a un contrôle plus local dans le choix du matériau et l'écriture d'un algorithme de calcul. La démarche artistique de Barbaud inclut une formalisation cohérente de la théorie musicale. D'autres précurseurs, comme Philippot ou Riotte ont permis à cette école française d'occuper une place importante dans la genèse de la composition assistée par ordinateur. Le lecteur intéressé, peut trouver des formalisations intéressantes dans [Fatu89].
La composition algorithmique est l'une des premières utilisations de l'ordinateur en musique. L'argument de base est la division de la composition en ses aspects technique et créatif. Il est alors possible, qu'un algorithme subvienne aux manques techniques pour faciliter ainsi la création. Cette séparation est cependant discutable. Dans cette vision de partage des processus compositionnels entre la machine et l'homme, c'est G. KÏnig [Koen71] qui est allé le plus loin avec ses programmes PROJECT1 et son extension PROJECT2. Les programmes de KÏnig calculent des structures musicales à partir d'une spécification fixe de la forme de la pièce. Ainsi le compositeur donne des listes de paramètres comprenant les durées, les tempi, les accords, etc. et le programme calcule la distribution périodique ou apériodique des éléments pour produire la composition. La composition est le résultat des combinaisons symboliques (indépendantes de phénomènes physiques) et d'une spécification uniquement au niveau de la forme. La spécification de la forme est donnée a priori et son contrôle n'est pas accessible au compositeur. La composition algorithmique vue de cette manière continue d'avoir un nombre significatif d'adeptes. Des compositeurs comme D. Cope ou Ch. Ames, entre autres, mènent des recherches basées sur l'idée principale d'établir des domaines de paramètres musicaux sur lesquels on impose des structures de contrôle automatiques dont l'exécution engendre la structure d'une pièce. Cope a évolué récemment vers un modèle de bases de données contenant une grande quantité de gestes musicaux élémentaires capturant des éléments de style. L'algorithmique porte alors sur la recombinaison de ce matériel "génétique" selon des formes préétablies en résolvant les problèmes d'articulation et en imposant les transformations très locales nécessaires à la reconstitution d'un discours cohérent. Cope a produit des simulations intéressantes du style de Bach, Mozart, Beethoven ; mais il compose lui-même. Dans ce cas, la problématique consiste pour lui à définir les atomes de son propre style. On voit tout de suite le problème esthétique qui émerge de ce dernier ensemble de démarches : il y a là l'hypothèse implicite que la création musicale consiste en la recombinaison et la mise en forme d'éléments préexistants qui contiennent, eux, la part non modélisable où réside l'originalité absolue d'un créateur, en d'autres termes, le style. Si cette démarche peut faire sens sur le plan musicologique, elle nous semble empreinte d'un idéalisme naïf en ce qui concerne la création contemporaine. Elle nie l'idée même d'invention à laquelle elle substitue celle de découverte combinatoire de notre "moi" musical, et, par là, semble peu susceptible d'atteindre à l'inédit.
Bien sûr dans ce parcours historique de la composition assistée par ordinateur nous devons mentionner les travaux de I. Xenakis [Xena81] qui a basé sa musique de manière originale et sans précédents sur le principe d'indéterminisme. Le naturel avec lequel la musique de Xenakis peut se servir de l'ordinateur vient du fait que le langage de ses idées correspond au langage des machines. Dans les divers écrits de Xenakis se manifeste le désir de développer un langage pour la manipulation des événements sonores dérivés de la mathématique, la logique et la physique des particules. Pour Xenakis, l'application du sérialisme à d'autres paramètres compositionnels que les hauteurs dégénère dans la perte de la cohérence polyphonique ayant comme résultat ce qu'il appelle un nuage de notes. Suite à cette remarque, les éléments primitifs dans les compositions de Xenakis n'étaient plus les notes, mais ces nuages dont le développement dans le temps est manipulé à l'aide des distributions de probabilités. Une composition pour Xenakis est le remplissage d'un espace bidimensionnel temps-fréquence avec des primitives sonores réparties dans différentes régions avec différentes densités.
Pour finir cette première étape historique nous dédions quelques lignes au logiciel MUSICOMP (Music Simulator Interpreter for Compositional Procedures), que nous considérons comme le premier logiciel d'aide à la composition, par opposition à la composition automatique. MUSICOMP a été écrit par Robert Baker vers 1963 avec l'expertise de L. Hiller et peut être vue comme un ensemble d'outils pour résoudre des problèmes spécifiques à la composition musicale. En réalité ces outils sont des sous-routines en FORTRAN. On trouve dans MUSICOMP trois familles de routines : les routines génératrices (principalement des chaînes de Markov), les manipulations sérielles et géométriques que l'on groupe sous la famille d'outils modificateurs et un ensemble de règles de sélection, pour la plupart des règles harmoniques classiques. Les trois expériences musicales principales réalisées avec MUSICOMP furent : la résolution des problèmes d'organisation rythmique pour percussion ; la génération de musique sérielle en utilisant le modèle de Structures pour deux pianos de Boulez et en général la recherche de structures verticales et horizontales dans des échelles tempérées [Hill69].
Après cette période pionnière, la place principale de l'informatique musicale est prise par le domaine de l'analyse et synthèse de son, avec tous les progrès que l'on connaît. En ce qui concerne la composition, cette époque que l'on pourrait situer vers les années 70 est caractérisée par l'utilisation de diverses techniques mathématiques comme modèles de composition. Parmi les techniques les plus utilisées nous citerons : les chaînes de Markov, les automates et les grammaires formelles, les systèmes de production, etc.
La CAO "moderne" telle qu'on la voit émerger depuis le milieu des années 80 est conditionnée par un certain nombre de facteurs : la disponibilité des ordinateurs personnels ; les progrès dans les interfaces graphiques ; la création de standards, parmi lesquels, depuis 1983, la norme MIDI (Music Instrument Digital Interface) ; et les progrès réalisés dans le domaine des langages de programmation, ce qui constitue selon notre point de vue le facteur le plus important. De la même façon que le langage influence le programmeur, le choix d'un langage de programmation joue un rôle dans la formalisation d'une idée musicale. En effet, l'utilisation d'un langage peut susciter des expressions qui ne seraient pas favorisées dans un autre contexte. Les progrès dans le domaine des langages de programmation ont donc été fondamentaux pour la CAO. L'utilisation d'un langage de programmation oblige le musicien à réfléchir sur les processus même de formalisation et lui évite de considérer l'ordinateur comme une boîte noire qui lui impose ses choix. Les langages de programmation offrent au compositeur une énorme liberté de décision, en échange d'un effort dans la formulation et la conception.
Cette CAO contemporaine a été progressivement définie par les contributions de personnes comme S. Pope [Pope91] qui a proposé plusieurs systèmes basés sur le langage Smalltalk, ouvrant la possibilité pour le compositeur de définir ses propres objets et méthodes et de bénéficier d'une interface graphique de haut niveau, E. Taube [Taub91] qui a réalisé à Stanford le programme de composition par patterns " Common Music " en Common Lisp, F. Pachet qui met en Ïuvre objets et contraintes dans MusES [Pach94]. Notons que ce qui caractérise ces environnements est l'utilisation de langages de haut niveau, de concepts de programmation modernes comme les objets, d'interfaces graphiques sophistiqués. Mais surtout ce sont des systèmes ouverts, qui demandent une implication informatique de la part du compositeur, au prix de laquelle il pourra lui-même étendre les représentations et les fonctionnalités. Un travail récent qui va dans ce sens est Elody. Elody est un environnement de composition basé sur un langage fonctionnel visuel [OrFL97]. Le lecteur trouvera des descriptions intéressantes d'autres travaux dans [LoyG88].
La contribution de l'Ircam à l'émergence de cette discipline mérite un traitement à part car c'est un des rares endroits qui se soit impliqué institutionnellement et avec constance depuis une quinzaine d'années dans la défense de ces idées. Nous y consacrons la prochaine section.
Depuis le début des années 80 se sont succédé à l'Ircam un certain nombre d'équipes qui ont adopté des noms différents mais qui ont toutes travaillé sur la manière de manipuler et de représenter les structures et les connaissances avec des buts compositionnels. Par la suite, nous ferons un bref résumé chronologique de ces investigations, en laissant de côté l'équipe Représentations musicales.
Nous considérons FORMES comme le premier environnement de CAO à l'Ircam, FORMES fut conçu par Xavier Rodet et Pierre Cointe et implémenté en VLisp entre 1982 et 1985. FORMES a été conçu comme un logiciel de SCM (Synthèse et Composition Musicale) qui concevait le son comme une production logique, cependant ce type d'application n'est qu'un cas particulier des énormes possibilités qu'offre cette environnement.
FORMES est basé sur l'idée de représenter les objets musicaux comme des acteurs, dans le sens informatique, et les structures de contrôle grâce au mécanisme d'envoi de messages. Ce langage très original à son époque était orienté vers la composition et l'ordonnancement des objets temporels. Les processus sont à la base de FORMES. La structure d'un processus est définie par un ensemble de règles, un moniteur, un environnement et une descendance. Le comportement d'un processus est défini par les messages qu'il reçoit : un processus peut principalement s'endormir, se réveiller, attendre ou se synchroniser. Tout processus a une durée définie a priori, sans qu'elle soit nécessairement explicite ; la durée d'un processus correspond au temps où il est actif. Le processus exécute ses règles au moment où il est actif. En général dans FORMES activer un processus revient à lancer une synthèse sonore. La descendance d'un processus est un ensemble de processus satisfaisant certaines conditions, principalement, la durée de tout processus fils doit être contenu dans la durée du processus père. Le moniteur d'un processus indique le mode selon lequel sont organisés ses descendants. Les deux modes possibles, en séquence et en parallèle sont schématisées dans la Figure 1-1.
Figure 1-1 Processus en séquence et en parallèle dans Formes.
Un programme en FORMES peut être vu comme l'envoi d'un message d'activation à un processus racine. L'exécution du programme peut être considérée comme la répétition à des temps successifs des étapes suivantes : mise à jour des règles qui constituent l'arbre de calcul et exécution des règles de l'arbre de calcul. L'arbre de calcul à un instant t est une liste de règles, appartenant aux processus actifs à cet instant, ordonnées en fonction de la position de chaque processus dans la hiérarchie définie par les processus et leurs descendants.
Le lecteur qui voudrait mieux connaître FORMES peut se référer à [RoCo85]. FORMES fut et continue d'être un langage intéressant et original. L'intégration entre synthèse et composition est encore un problème d'actualité. Malheureusement ce qui fait la caractéristique majeure de FORMES est en même temps son grand défaut, car nous pensons que le temps continu et irréversible nécessaire pour la synthèse n'est pas le paradigme le plus approprié pour la composition en général. Pourtant, il est à noter que dans FORMES on peut parler du temps ce qui n'est pas les cas dans MAX [PuZi90], le plus répandu des logiciels de contrôle de processus sonores en temps réel.
Grâce au bon accueil fait à FORMES, l'étape suivante a été la construction d'une interface graphique qui tournait sur la plate-forme Macintosh. Ce fut l'origine de PREFORM implémenté par Lee Boyton et Jacques Duthen en 1987. PREFORM a été écrit en Le_lisp 15.1. La première nécessité était de définir un langage de programmation à objets qui serait compatible avec Lisp (à l'époque CLOS n'existait pas). En commençant par l'implémentation de ce langage le projet PREFORM dévia de son but principal. PREFORM est donc une extension de Lisp avec :
PFOOL avait certaines déficiences : la redéfinition d'une classe effaçait toutes les méthodes définies pour cette classe ; les méthodes n'étaient pas des citoyens de première classe et en général la fusion objet-fonctionnel n'était pas faite à 100%, car les méthodes ne pouvaient pas être invoquées en utilisant la même syntaxe que les fonctions. Parmi les avantages de PFOOL on trouve l'existence d'un protocole pour la persistance d'objets qui faisait partie du langage même. PFOOL a été remplacé par la suite par CLOS. Une spécification syntaxique, de même que les divers composantes de PREFORM peuvent être trouvés dans [DaDu90].
Une des principales applications implémentées sur PREFORM a été ESQUISSE. Conçue par P.-F. Baisnee et J. Duthen avec l'aide d'un groupe de compositeurs dont on peut distinguer Tristan Murail, ESQUISSE part de la nécessité pour un compositeur de disposer d'objets multidimensionnels et d'appliquer sur eux des fonctions qui les modifient ou produisent de nouveaux objets. Ainsi ESQUISSE peut se concevoir comme une boîte à outils servant à faire des opérations musicales. Le premier grand pas a été de faire une classification des dites fonctions par rapport au type de connaissance musical qu'elles représentent. Nous trouvons dans ESQUISSE des fonctions orientées intervalles ; des fonctions de traitement harmonique ; d'interpolation d'accords, de motifs et d'objets en général. ESQUISSE a donné de la force à la démarche fonctionnelle et l'on a très vite vu que ce paradigme pouvait être appliqué de manière homogène au domaine de la synthèse et de la CAO.
L'environnement CRIME [AsMa84] représente la première tentative pour réaliser un environnement général où l'utilisateur pouvait manipuler des formalismes musicaux avec des résultats visualisés sous la forme d'une partition musicale en notation classique. Il y a ainsi eu à disposition des compositeurs des langages formels leur permettant de définir des structures rythmiques, des motifs harmoniques, polyphoniques, etc. CRIME a été écrit en Lisp par Gérard Assayag en collaboration avec Claudy Malherbe et tournait sur un mini-ordinateur digital Vax. La grande importance dans notre parcours, de la Cellule de Recherche Informatique Musique Etc. (CRIME), a été la mise en évidence d'un problème fondamental en CAO auquel on n'avait pas accordé l'attention suffisante : la notation.
Dans les articles [AsTi86] et [AsTi87], on aborde les diverses problématiques concernant les éditeurs musicaux. Des solutions sont proposées pour développer non seulement des éditeurs plus "intelligents", mais aussi des standards de notation. En effet, une extension du langage Postscript est proposée permettant à l'utilisateur d'ajouter son propre style de notation tout en gardant une cohérence avec la notation musicale. Il est dommage que cette proposition ne se soit pas imposé comme un standard. En effet, les travaux qui ont été faits et qui se font sur la notation musicale sont nombreux et pourtant les résultats ne sont pas encore en rapport avec l'effort investi. Il est clair que le problème de la notation musicale dépasse largement la problématique de l'informatique musicale, de même que le cadre de cette thèse. Depuis les diverses réflexions de l'équipe CRIME on a conclu qu'il était nécessaire d'arriver à représenter non seulement le résultat d'une composition sous la forme d'une partition musicale, mais aussi les divers processus propres à l'acte de composition dans un environnement intégré.
Un des premiers logiciels adapté à la visualisation des processus de composition a été CARLA. CARLA est un langage de CAO qui a pour rôle principal d'assister le compositeur la formalisation de la syntaxe des structures musicales. Écrit en prolog II par Francis Courtot entre 1989 et 1990, CARLA est une interface graphique pour la programmation logique. CARLA part du principe que "...s'il est certain qu'il est impossible de formaliser toutes les syntaxes musicales en une représentation universelle, il doit être possible de formaliser un langage permettant à chaque compositeur de définir son propre ensemble de syntaxes. ".
L'environnement CARLA est constitué par : des types de base et un ensemble d'heuristiques associées à chaque type ; un modèle et une interface graphique qui formalisent les relations entre types ; et un outil de programmation logique. Il existe deux classes de types en CARLA : les types primitifs, définis à l'aide d'un langage de premier ordre et les types complexes. Un type primitif est défini par un ensemble d'attributs et en particulier un domaine. Les types complexes se construisent à partir de types déjà existants à l'aide de 4 constructeurs : *ho pour la construction en séquence ; *ve pour la construction en parallèle ; *nup pour l'union d'attributs et *union pour l'union de types. La Figure 1-2 représente sous une forme arborescente l'ensemble de tous les types pour un programme donné :
Figure 1-2 Signature d'un programme en CARLA.
Cet arbre montre les différents types représentant la syntaxe des structures musicales qui seront utilisées pendant le processus de composition. Cet arbre est appelé la signature, bien que la signature puisse être visualisée graphiquement, son édition graphique n'est pas permise.
Le compositeur peut définir une structure sémantique en associant une valeur sémantique à chaque type et en établissant des relations sous la forme d'un graphe conceptuel. CARLA produit une valeur sémantique par défaut pour chaque type, ce qui facilite la tâche du compositeur. De même que pour la signature, une interface graphique de visualisation nous permet d'examiner le graphe conceptuel où les nÏuds correspondent aux types et les arêtes sont un ensemble de relations binaires entre types.
Jusque-là, les constructions présentées ont servi à définir statiquement les structures musicales. La dernière étape dans CARLA consiste en la manipulation de ces structures. Pour cela une interface graphique a été créée, permettant au compositeur d'écrire ses propres programmes. Le compositeur dispose d'un ensemble de prédicats prédéfinis, représentés sous la forme de boîtes. Chaque boîte contient le nom du prédicat et son arité (visualisée par le nombre de rectangles dans la partie inférieure). Un prédicat dans CARLA ressemble à :
Figure 1-3 Une boîte en CARLA.
Le travail du compositeur consiste à placer un ensemble des boîtes sur une fenêtre et à créer des relations entre elles à l'aide de connexions. Une connexion n'est pas autre chose qu'une contrainte d'égalité. Le réseau de contraintes ainsi créé, peut être abstrait sous la forme d'un nouveau prédicat et peut être alors représenté comme une boîte dans un autre réseau, ce qui permet de masquer graphiquement la complexité du programme. La Figure 1-4 montre un programme dans CARLA :
Figure 1-4 Un programme en CARLA.
Dans le programme précédent, de même que dans Prolog, l'ordre d'évaluation joue un rôle important ; cela oblige à une hiérarchisation des boîtes dans les catégories suivantes :
Pour évaluer un réseau de boîtes, on commence par évaluer les contraintes, les transformations, puis les théories et finalement les boîtes de sortie. Cette stratégie n'est pas toujours la meilleure, mais l'utilisateur peut définir l'ordre d'évaluation (chose qui dans la plupart de cas reste une tâche compliquée). Une description en détail de CARLA peut être trouvée dans [Cour90] et [Cour93].
1.2.2 L'équipe représentations musicales.
L'équipe représentations Musicale, fondée en 1992, a bénéficié de tous les travaux préalables exposés aux sections précédentes pour essayer de construire une démarche cohérente clairement identifiée sous le nom de Composition Assistée par Ordinateur, avec un accent particulier mis sur la notion de composition elle même. Nous essayons de définir ici le cadre général dans lequel nous situons notre recherche.
La composition est présente, à l'état de projet ou à l'état de réalisation, dans tous les secteurs de l'informatique musicale ; par conséquent, pourquoi constituer en discipline autonome cette alliance de la technologie et de la composition ? Nous proposons cet élément de réponse : la spécificité de l'écriture musicale, entendue d'abord comme écriture pour les instruments, et la nécessité pour une pensée musicale en devenir, en mutation perpétuelle, d'accéder, comme le font aujourd'hui tous les systèmes de pensée formalisée, à la puissance et la souplesse de l'outil informatique. L'écriture instrumentale nous semble alors un champ d'étude à la fois précis et ouvert : elle constitue un modèle encore inégalé d'adéquation entre des systèmes d'opérations combinatoires sur des ensembles de symboles et un univers sonore disposant de ses propres règles de fonctionnement perceptif et cognitif, la notation opérant un lien cohérent entre ces deux instances. Par là, elle ouvre aussi à l'intégration de matériaux sonores nouveaux - extensions du monde instrumental, synthèse et transformation sonores. Le développement d'une technologie informatique spécifique se justifie alors de plus en plus au fur et à mesure que s'étend son champ d'action et que se complexifient ses procédures. Nous emploierons donc le terme "aide à la composition" en privilégiant, parmi toutes les interprétations possibles, celle qui se rapproche le plus de l'idée d'écriture instrumentale dans ce qu'elle porte d'exemplaire quant à la formalisation, la codification, la notation, et la relation au monde physique. Les systèmes de CAO seront au moins capables d'apporter une aide efficace dans le cas spécifique de l'écriture pour instruments ; ils devront constituer une passerelle cohérente entre ces derniers et les nouveaux champs sonores. Ils pourront à terme constituer de bons modèles pour le contrôle de la synthèse pure. Nous structurons notre cadre conceptuel autour de trois axes : langage, notation et perception.
Tout d'abord, il nous faut mettre en adéquation deux activités d'ordre symbolique et combinatoire : d'un côté, la recherche inlassable de nouveaux éléments de langage musical et de nouveaux modes de structuration de ces derniers ; de l'autre, la spécification et l'exploitation interactive d'algorithmes permettant d'actualiser ces idées et d'en explorer systématiquement les conséquences techniques et artistiques.
Construire des structures, exprimer des calculs n'a d'utilité que dans la mesure où données et résultats peuvent être interprétés et représentés dans des dimensions musicalement significatives telles que hauteur, durée, intensité, ou timbre pour se limiter aux catégories traditionnelles. Fournir des interfaces visuelles et auditives qui améliorent cette interprétation est alors une nécessité impérative. Dans la perspective d'aide à l'écriture où nous nous plaçons, une grande importance est donnée à la notation musicale traditionnelle. Celle-ci agit idéalement dans un logiciel de CAO non seulement comme matérialisation des informations circulant dans le système mais aussi comme support de l'inventivité formelle. À ce titre, la notation devrait être dotée de la même souplesse, de la même ouverture (en termes d'extensibilité et de programmabilité) que le langage même et constituer à terme le "milieu" naturel d'expérimentation de l'utilisateur. Les niveaux du langage et de la notation tendront alors à se confondre du point de vue de l'utilisateur.
Les manipulations sur un matériau compositionnel ont un caractère éminemment combinatoire. Toute l'entreprise pourrait rester au stade de la spéculation formelle si un lien solide n'était pas établie avec la perception. Plusieurs principes peuvent être appliqués pour arriver à cette fin, mentionnons la constitution de tests auditifs à partir des sorties musicales, la connexion du logiciel de CAO à des outils d'analyse et de synthèse, ou enfin l'intégration de modèles acoustiques et psycho-acoustiques au sein même du logiciel. Ainsi, un environnement d'aide à l'écriture instrumentale permettra d'indiquer certains effets perceptifs saillants et par là de mieux intégrer des éléments hétérogènes (instruments, synthèse, objets sonores, contrôle spatial).
Si un certain progrès des environnements de CAO s'est récemment manifesté dans le sens d'une expressivité accrue des langages informatiques et dans l'apparition de véritables éditeurs graphiques, la représentation cohérente de la trilogie qui guide notre propos - langage, notation, perception - reste un idéal à atteindre. En particulier, le niveau de la notation devra tendre à la même modularité que celui de la programmation de façon à constituer à terme un système d'interface programmable et personnalisable intégrant contraintes et connaissances musicales. Pour cela les concepts originaux développés dans le domaine de la programmation visuelle devront trouver leur contrepartie dans celui de la notation. Ainsi le compositeur programmera-t-il lui même en toute liberté le calcul fonctionnel qui déterminera les contours de son champ d'expérimentation musicale, les contraintes qui informeront ce dernier et lui imprimeront une structure, les degrés de liberté qui permettront une navigation dans l'espace de connaissances alors constitué, les modalités sensibles de cette exploration - graphisme, son, interaction gestuelle. Enfin il pourra choisir de masquer toute l'étape d'élaboration en définissant une "partition potentielle" où se superposeront affichage des résultats, contrôle interactif des degrés de liberté, entrée des paramètres musicaux - sorte de feuille blanche "informée" par une hiérarchie d'obligations menant des contraintes de cohérence élémentaire du langage musical à celles, de plus haut niveau, exprimant les caractéristiques stylistiques qui lui seront personnelles.
Au centre de cette idée de partition potentielle se trouve la notion de modèle informatique d'une structure musicale, plus puissante et plus générale que celle d'esquisse ou de processus employées jusqu'alors. Ce concept est au cÏur des recherches actuelles dans le domaine de l'analyse comme dans celui de la composition assistées : il n'est pas inutile de s'y arrêter quelque peu. Riotte et Mesnage notent que s'est établie, depuis une trentaine d'année, la légitimité de la simulation compositionnelle comme démarche d'analyse assistée par ordinateur ; tout d'abord simulation stylistique [Cope91] puis reconstitution, à partir d'un modèle informatique, d'une partition complète comme le modèle de la première Pièce pour Quatuor à Cordes de celui des variations pour piano opus 27 de Webern par Riotte et Mesnage [MeRi89].
Mais qu'entend-t-on exactement ici par modèle? De manière générale, le modèle est un dispositif formel qui, rendant compte, au moins partiellement, des caractéristiques d'un processus matériel, en autorise expérimentalement la simulation aux fins de vérification, d'observation ou encore de production de processus similaires. Ainsi des modèles utilisés en synthèse des sons, comme la modulation de fréquence ou les modèles physiques. Si la simulation stylistique entre bien dans cette définition, puisqu'elle est à même de produire un nombre indéfini d'instances musicales obéissant aux lois d'un genre, les modèles de partitions de Mesnage et Riotte constituent un cas extrême dans la mesure où ils sont entièrement dévolus à la restitution d'un objet unique. Ils ne constituent pas cependant une simple description de ce dernier- qu'ils généralisent dans la mesure où ils lui substituent une collection de mécanismes formels dont une paramétrisation particulière fournira l'objet final. Il est alors loisible d'envisager, en essayant d'autres jeux de paramètres ,la génération de variantes du texte analysé.
Ainsi, des lois d'un genre (et de la classe des modèles adaptés) à la formalisation d'une Ïuvre il y aurait une transformation opérant dans le champ même des modèles, une "résolution" au sens que donne M. Chemilier à ce mot [Chem90]. Pour cet auteur, en effet, une résolution, au sens mathématique, permet de passer de passer " d'une définition équationnelle (équivalente à une liste de contraintes) de l'ensemble des séquences musicales recherchées à une définition paramétrique équivalente ". Par ce tour de passe-passe consistant à jouer sur l'ambiguïté du terme modèle (le modèle est à la source de l'Ïuvre, l'Ïuvre constitue le modèle destiné à être pastiché lors de la simulation) l'analyse moderne tend à se situer dans la catégorie de la création. En effet, la démarche de l'analyste utilisant des outils scientifiques n'est plus très différente de celle du compositeur confronté aux mêmes outils. Cela reste vrai jusque dans la distorsion du concept de modèle, que chacun opère pour son compte : dans la finalité qu'ils lui forgent de ne devoir engendrer qu'une singularité : singularité passée dans le cas de l'analyste, singularité à venir dans le cas du compositeur.
C'est dans leur action sur le modèle que divergent cependant les deux démarches. Dans le cas analytique, les raffinages successifs du modèle ont tendance à minimiser le nombre de paramètres _le cas idéal étant leur disparition complète, les valeurs des paramètres d'un niveau de formalisation étant engendrées par un formalisme de niveau supérieur. Ainsi, sauf dans le cas des variantes, ce n'est pas tant l'expérimentation sur le modèle _la simulation _qui prévaut, que son raffinement progressif depuis le stade de la paraphrase jusqu'à celui de l'explication.
Pour le compositeur au contraire seule l'expérimentation productive compte. Le modèle est alors manipulé selon deux modalités : d'une part les objets qu'il produit constituent des éléments de matériau structuré qui pourront être mis de côté au fur et à mesure de l'exploration. D'autre part, l'observation de ces éléments peut conduire à la remise en question de la théorie musicale sous-jacente qui sera remaniée en conséquence, conduisant à l'élaboration d'un nouveau modèle. On retrouve alors le concept classique de simulation comme validation de la théorie, à ceci près que _et c'est une différence fondamentale avec la démarche scientifique _le phénomène de référence permettant de conduire la comparaison validante n'existe pas autrement qu'à l'état d'idéal dans l'imaginaire du compositeur.
Le modèle informatique est aujourd'hui à la jonction de l'analyse et de la composition. La discussion n'a cependant porté jusqu'ici que sur la notion de modèle en général. Qu'en est-il de la spécificité informatique ? Elle est tout d'abord pragmatique. Il est banal mais important de rappeler que le tout-numérique donne sa pleine puissance à la notion de simulation (encore qu'il y ait eu des exemples de simulation compositionnelle analogique). Plus significativement, il existe des correspondances fortes entre les problématiques rencontrées dans les diverses branches de la recherche musicale informatique. Enfin, l'informatique a tendance à unifier les deux instances, explicative et générative, du modèle. En effet, un programme d'ordinateur est d'abord un "texte", exprimant avec les conventions d'un langage formel, un réseau de relations. Il donne lieu lors de son exécution au déploiement dans le temps d'un processus dont la forme est réglée par ces relations. Il reproduit ainsi lui-même, par une sorte de mise en abyme, la dialectique modèle/simulation. Le programme d'ordinateur, implémentant un calcul compositionnel ou une formule d'analyse, occupe donc une position idéale pour peu qu'il veuille bien exhiber sous une forme assimilable sa composante logique. C'est le pas, important à nos yeux, qui a été franchi avec la "programmation visuelle", technique par laquelle on substitue au langage formel évoqué plus haut une représentation graphique schématique équivalente.
Du fait de la très grande diversité de modèles esthétiques, techniques, formels (ou anti-formels) qui coexistent chez les compositeurs aujourd'hui, on ne peut plus imaginer un environnement de CAO comme une application figée offrant une collection finie de procédures de génération et de transformations musicales. Au contraire, nous concevons un tel environnement comme un langage, au sens informatique, à l'aide duquel chaque compositeur pourra constituer son univers personnel. Bien entendu, il ne s'agit pas de fournir un langage informatique traditionnel, dont la maîtrise demande une grande expertise technique, mais un langage aménagé spécialement pour le compositeur. Ceci nous conduit à réfléchir sur les différents modèles de programmation existants, sur les interfaces, de préférence graphiques, intuitives, qui permettent de contrôler cette programmation, et sur les représentations, internes et externes, des structures musicales, qui seront construites et transformées à l'aide de cette programmation.
Dans le cadre général qui vient d'être posé, un certain nombre d'environnements expérimentaux ou de production ont été réalisés par l'équipe Représentations Musicales, notamment, PatchWork, Situation, et OpenMusic. Ces environnements sont décrits dans la prochaine section sur les modèles de programmation. OpenMusic, qui est l'objet central de cette thèse, est décrit en détail au chapitre 2.
1.3 CAO et Modèles de programmation.
Comme nous l'avons suggéré dans les sections précédentes, la notion de langage informatique devient prépondérante dans la problématique de la CAO. En effet, la recherche musicale est si ouverte aujourd'hui qu'on ne peut prévoir a priori la nature des expériences que désirera mener le compositeur ; plutôt donc qu'une application fermée, c'est un langage qu'il faudra lui fournir. Derrière la diversité des langages informatiques se profilent quelques grandes familles de modèles de programmation. Nous allons décrire dans cette section différents environnements contemporains de CAO qui d'une manière ou d'une autre se réfèrent à un modèle ou à un ensemble de modèles de programmation.
1.3.1 Modèle fonctionnel et visuel : PatchWork.
PatchWork (PW) est un langage de programmation orientée CAO, cependant il peut être utilisé pour des propos plus généraux [Laur96]. PW a été conçu et implémenté par M. Laurson, J. Duthen and C. Rueda au début des années 90, puis repris et amélioré dans le cadre de l'équipe Représentations Musicales de l'Ircam. PW a été utilisé depuis quelques années par plusieurs centaines d'utilisateurs dans des styles musicaux très divers. Citons notamment : Antoine Bonnet, Brian Ferneyhough, Paavo Heininen, Magnus Lindberg, Claudy Malherbe, Tristan Murail, Kaija Saariaho.
PW est une interface graphique pour la version Macintosh de Common Lisp (MCL). Un programme en PW consiste en un graphe orienté et acyclique dont les nÏuds sont des "boîtes" représentant des fonctions et les arcs matérialisent l'application fonctionnelle. Les "boîtes" peuvent être associées à un éditeur graphique (notamment en notation musicale) qui permet de visualiser et d'éditer un état interne.
Comme la plupart des environnements visuels PW est basé sur la notion d'événement. L'interface de PW est formée principalement de fenêtres dans lesquelles divers types d'items graphiques sont positionnés, déplacés et en général édités par rapport aux événements externes tels que click de souris ou touche de clavier. Il existe toujours dans PW une fenêtre active. Cette fenêtre est responsable de la traduction des événements externes en actions spécifiques. L'interface de PW est programmée en CLOS (Common Lisp Object System [Stee98]).
La notion de base dans PW est le patch. Un patch est une disposition de vues à l'intérieur d'une fenêtre. Ces vues sont appelées boîtes. Une boîte est un rectangle contenant éventuellement un ou plusieurs rectangles d'entrée et exactement un rectangle de sortie. Le rectangle de sortie d'une boîte peut être lié à un ou plusieurs rectangles d'entrée contenus dans d'autres boîtes à l'aide de segments formant des connexions. Une boîte contient aussi une chaîne de caractères qui précise sa fonction (mais n'est pas un identificateur). Deux textes sont associés à chaque rectangle d'entrée, l'un est une valeur par défaut qui peut être éditée et l'autre est une documentation de l'entrée. L'utilisateur peut basculer d'un type à l'autre par l'interface souris.
Chaque boîte représente l'invocation d'une fonction particulière. Les connexions entre les boîtes définissent la composition fonctionnelle. Un événement de click sur un rectangle de sortie déclenche l'invocation de la fonction représentée par la boîte qui contient le rectangle de sortie en question. Le processus d'évaluation déclenche récursivement l'évaluation des boîtes liées aux rectangles d'entrée de chaque boîte.
Les boîtes sont implémentées comme des objets CLOS. Dans le cas le plus général, les boîtes sont instances d'une classe définie ainsi :
(defclass patch-box (view)
((input-boxes)
(input-data)
(output-rectangle)
(meaning-function)) )
Le champ input-boxes contient une liste des boîtes connectées aux entrées. Les champs input-data et output-rectangle définissent respectivement les vues qui représentent les rectangles d'entrée et le rectangle de sortie contenus dans la boîte. Finalement le champ meaning-function fait référence à la fonction Lisp qui donne une sémantique à la boîte.
Les boîtes, ainsi que les rectangles d'entrée et de sortie sont des sous-classes de la classe standard view de MCL. Elles constituent des subviews de la fenêtre de patch qui les contient, et qui appartient elle même à une sous-classe de la classe standard window. Tous ces éléments bénéficient automatiquement, par héritage, des fonctionnalités graphiques standard de MCL.
Une fenêtre PatchWork est définie par :
(defclass pw-window (window) ((boxes)) )
où le champ boxes contient une liste de toutes les boîtes dans la fenêtre. Ainsi, dessiner un patch est une tâche exécutée directement par MCL avec la spécialisation de la méthode standard view-draw-contents pour la classe pw-window :
(defmethod view-draw-contents :before ((self pw-window))
(tell (boxes self) '#view-draw-contents) )
Un patch visuel définit un modèle de calcul simple dans lequel les boîtes assument le rôle d'invocation de fonctions. PW ajoute aussi l'abstraction procédurale, mécanisme par lequel un patch peut être abstrait en une boîte simple (appelée boîte abstraction). L'action contraire, qui est l'expansion d'une boîte abstraction en une fenêtre affichant le patch associé, est contrôlée par un événement de double click (Figure 1-6). Les boîtes d'abstractions sont instances d'une sous-classe de patch-box avec deux champs additionnels, l'un qui garde une adresse vers la pw_window contenant le patch associé, et l'autre qui fait référence à la boîte particulière de ce patch définissant le résultat de l'abstraction. Lors de l'évaluation d'une boîte d'abstraction, au lieu de regarder son champ meaning-function , on évalue cette boîte résultat.
Ce processus interprétatif permet de rendre immédiatement effectif toute modification au patch associé à une abstraction.
Figure 1-6 Une boîte abstraction et son patch associé.
D'autres boîtes que les abstractions peuvent être associées à une fenêtre. En effet, cette idée a été généralisée dans PW pour pouvoir associer des représentations visuelles de structures musicales complexes aux boîtes qui les calculent. A cette fin, le modèle computationnel de PW est enrichi de deux caractéristiques importantes : la préservation d'état d'une boîte et l'interprétation (visualisation et édition de données produites par une boîte). Une boîte à état calcule toujours un objet CLOS. Cet objet est préservé comme l'état local de la boîte à chaque évaluation. Un mécanisme de verrou (un bouton sur lequel l'utilisateur peut cliquer) permet d'inhiber le mécanisme normal d'évaluation de la boîte concernée : au lieu d'invoquer la fonction associée, c'est l'état local qui est directement retourné. Un éditeur graphique associé à la boîte à état peut être ouvert dans une fenêtre. Les données de l'objet local sont alors affichées graphiquement selon une convention (notation musicale, courbe mathématique, etc.) qui dépend du type de boîte. Ces données peuvent être éditées graphiquement par l'utilisateur ; l'objet local est alors directement mis à jour. Lors d'une évaluation avec verrou, l'objet local est, comme nous l'avons dit, directement retourné. Lors d'une évaluation sans verrou, les données graphiques de l'éditeur sont mises à jour avec le nouvel objet construit par invocation de la fonction associée à la boîte. Ainsi est maintenue la cohérence entre l'objet local associé à la boîte, la sémantique visuelle définie par la boîte et ses connexions au sein du patch, et enfin l'éditeur graphique et la représentation intuitive qu'il offre à l'utilisateur. Notons qu'il est indispensable de verrouiller une boîte à état lorsqu'on modifie son état interne à l'aide de l'éditeur ; sans cela, à l'évaluation suivante, ces modifications sont évidemment perdues.
Dans la Figure 1-7, la boîte chordseq est une boîte à état qui calcule une séquence d'accords à partir de listes de hauteurs, de durées, de vélocités etc. Elle est associée à un éditeur qui représente visuellement cette séquence d'accords (ici réduits à une seule note) en notation musicale proportionnelle.
Figure 1-7 Une boîte avec éditeur dans PW.
De même que pour les boîtes d'abstraction, les boîtes à état sont implémentées comme une sous-classe de patch-box. Par exemple la boîte qui interprète une note peut être définie par :
(defclass note-box (patch-box)
((midic)
(velocity)
(duration)
(channel)) )
où les divers champs définissent les caractéristiques de hauteur, dynamique, durée et instrument de la note. L'association d'un éditeur de note à cette boîte nécessite seulement de changer dans la définition de sa super-classe, la classe patch-box par la classe box-with-editor . Cette classe en addition à la structure standard d'une boîte associe une fenêtre qui représente l'éditeur. La classe box-with-editor gère l'allocation de la fenêtre éditeur associée. Les fenêtres éditeur possèdent une structure très simple :
(defclass mn-editor (window)
((menu-bar)
(patch-box)
(view-controller)) )
Un éditeur possède trois champs : la barre de menu propre à cet éditeur, une référence à la boîte associée et un contrôleur de vue (view-controler). Le contrôleur de vue est chargé, entre autres, de l'édition de paramètres qui affectent globalement la visualisation de l'éditeur (le zoom, par exemple). Pour cela, il contient un ensemble de contrôles graphiques qui permettent à l'utilisateur d'affecter de tels paramètres. Un contrôleur de vue contient par ailleurs un certain nombre de panels.
Un panel est une view qui gère des actions d'édition spécifiques dans une région graphique déterminée (le changement de hauteur d'une note, par exemple). Tout panel dans un contrôleur de vue peut traiter les événements de souris qui le concernent. Cette structure hiérarchique simple donne une certaine flexibilité à la visualisation et à l'édition des données.
Contrôleurs de vue et panels peuvent être facilement sous-classés et adaptés pour visualiser notes, accords, séquences d'accords, rythmes, etc. La Figure 1-8 permet de visualiser la même donnée (une liste de valeurs numériques) comme une fonction par segments, comme une liste ou comme une structure rythmique. Il est ainsi aisé de construire à l'aide d'un patch simple un ensemble de représentations graphiques distinctes d'un même objet. Notons cependant, et c'est là la limite de PW, que la cohérence entre ces diverses représentations n'est pas maintenue par le système ; elle peut être brisée, par exemple, lorsque l'utilisateur édite manuellement dans un des éditeurs.
Figure 1-8 Représentations multiples des données.
Finalement il existe aussi un schéma de typage statique dans PW. Deux boîtes peuvent être connectées si le type de la sortie de la boîte source est compatible avec le type de l'entrée de la boîte cible. Ainsi chaque boîte définit un ensemble de types admis pour chacune de ses entrées, ainsi qu'un ensemble de types des résultats. Les instances de la classe pw-box conservent l'information concernant les différents types d'entrée et de sortie comme une propriété Lisp (P-List) du symbole associé à sa meaning-function. L'éditeur de patchs permet une connexion, si et seulement si l'intersection entre la liste de types de sortie de la boîte source et la liste de types de l'entrée de la boîte cible n'est pas vide.
Le comportement fonctionnel d'un patch a une correspondance
directe avec le comportement d'une expression dans Common Lisp. Plus
précisément un patch dans PW peut être vu comme
un graphe. Un graphe de patch est un graphe acyclique 
, où B
est un ensemble de nÏuds appelé boxes, E est un
ensemble de nÏuds appelé entries, C est un
ensemble d'arêtes dirigées appelé
connections, F est un ensemble d'étiquettes de
nÏud appelé values et O est un ensemble
d'étiquettes d'arête appelé orderings. C
est un sous-ensemble de 
. Les graphes de patch sont en correspondance un
à un avec les patchs PW. La Figure 1-9 nous montre le graphe
de patch associé au patch PW montré dans la Figure 1-5.
La sémantique formelle d'un programme dans PW est
définie par une fonction d'évaluation 
qui fait
correspondre chaque graphe de patch P à une expression
bien formée dans Lisp. Nous appelons V[P] le
signifié d'un patch P. Dans les lignes suivantes, nous
décrirons la fonction V en expliquant comment les actions dans
un patch PW lors de son évaluation, correspondent à une
expression Lisp donnée.
Figure 1-9 Un graphe de patch.
L'évaluation d'une boîte par un événement de click dans son rectangle de sortie produit l'évaluation de l'expression lisp suivante :
(patch-value (view-container self))
où l'argument self correspond au rectangle de sortie de la boîte (i.e. l'objet contenu dans son champ output-rectangle). L'expression (view-container self) fait référence à la boîte (patch-box) qui est évaluée. La définition de la méthode patch-value invoquée lors de l'évaluation d'une boîte est la suivante :
(defmethod patch-value ((self patch-box))
(apply (meaning-function self)
(ask-all (input-boxes self) 'patch-value)) )
La macro ask-all envoie le message spécifié dans son deuxième argument à chacun des éléments de la liste passée comme premier paramètre. La fonction meaning-function est donc appliquée aux résultats de l'évaluation de chaque argument d'entrée.
Le signifié d'une boîte standard dans un patch est donc défini par la fonction V du graphe de patch équivalant au Patch PW, ayant comme racine le nÏud correspondant à la boîte évaluée. L'expression suivante indique la sémantique de l'évaluation d'une boîte :
V [BOX.patch-box] = ( value(BOX.patch-box)
V [connexion (1,BOX.patch-box)]
V [connexion (2,BOX.patch-box)]
...
V [connexion (n,BOX.patch-box)] )
où connexion (i,BOX.patch-box) dénote la cible de l'arête d'étiquette (ordering ) i partant du nÏud BOX.patch-box. L'expression value (nÏud) fait correspondre les nÏuds de boîte et d'entrée avec leurs étiquettes respectives. L'évaluation d'un nÏud entry est défini par :
V [ENTRY] = (QUOTE value(ENTRY))
L'évaluation du graphe de patch dans la Figure 1-9 ayant comme racine le nÏud g+ sera donc :
(g+ (quote 25)
(g* (const (quote (60 64 67)) )
(quote 100))
Ce type de traduction sémantique est bien défini uniquement s'il n'y a pas de cycles dans le graphe de patch. L'éditeur de patch est chargé de vérifier à chaque nouvelle connexion que cette condition est satisfaite. L'évaluation définie précédemment est suffisante si toutes les boîtes appartenant au patch sont instances de la classe patch-box. Cependant, les patchs construits avec des boîtes qui préservent l'état ou avec des boucles demandent un traitement plus complexe.
Figure 1-10 Un patch et son graphe correspondant.
Le patch PW et son graphe correspondant, illustrés dans la Figure 1-10, spécifient une boucle qui construit une liste d'objets note avec des hauteurs D#, G, A. La sémantique du patch est donnée par :
V [BOX.pw-map] =
(MAPCAR
(FUNCTION (LAMBDA (V [connexion (1,BOX.pw-map)] )
[connexion (2,BOX.pw-map)] ))
[ connexion (1,connection (1,BOXpw-map) )] ) )
et
V [BOX.enum] = *AN-ENUM-VARIABLE*
Ce qui est traduit en code Lisp par :
(mapcar
(fonction (lambda (*AN-ENUM-VARIABLE*)
(mk-note *AN-ENUM-VARIABLE*
(quote 75) (quote 100) (quote 1))) )
(const (quote (6300 6700 6900)))))
Les boîtes qui préservent leur état sont traduites par des clôtures, c'est-à-dire, des expressions Lisp contenant un état [Sain93].
Comme les patchs sont construits à l'aide d'un éditeur faisant partie de l'environnement et aussi grâce au système de types mentionné précédemment, l'évaluation d'un patch PW sera toujours exprimée comme une expression Lisp bien formée. Dans ce sens, un patch est toujours syntaxiquement correct. Bien évidemment, il y a des patchs qui ne correspondent pas aux attentes du compositeur. Nous disons simplement que le comportement d'un patch est équivalent à l'évaluation de son graphe de patch correspondant dans la sémantique Lisp. Il existe donc, une correspondance étroite entre patchs PW et programmes Lisp. Cette décision correspond principalement à deux raisons : d'un côté nous disposons d'un mécanisme direct pour sauvegarder, charger et optimiser les patchs dans leur codification en code Lisp, de l'autre nous bénéficions d'une interaction dans les deux sens entre Lisp et PW. Plus particulièrement il existe un mécanisme de décompilation qui permet de transformer la définition d'une fonction Lisp en termes de boîtes et connexions. Cela se traduit par la possibilité de faire coexister différents modèles de programmation en utilisant le même environnement graphique et en profitant du mécanisme de visualisation, représentation et édition graphique des structures musicales fournies par PW.
PW peut être facilement étendu et adapté à différentes conceptions et manipulations de structures musicales. Le compositeur a la possibilité de grouper patchs et boîtes dans une librairie. Un ensemble d'outils est à la disposition du compositeur pour la construction d'une hiérarchie exprimée sous la forme d'un menu où seront stockées ses propres boîtes, qui auront alors le même statut que les boîtes prédéfinies dans le kernel. Tout au long de l'utilisation de PW un ensemble de librairies ont été construites par des compositeurs et des informaticiens. Un grand nombre d'entre elles sont distribuées avec l'environnement PW soulignant ainsi la diversité d'applications musicales propres à chaque compositeur ou à chaque style de composition. Parmi les plus importantes nous citons :
· Chaos, de Mikhail Malt, pour la définition de structures musicales à l'aide de manipulations stochastiques et de modèles dynamiques.
· Kant, par Augusto Agon, Gérard Assayag et Camilo Rueda, pour la quantification rythmique.
· AAC, par Augusto Agon, pour la communication inter applications.
· PWConstraints, par Mikael Laurson, pour la programmation par règles.
· Situation, par Camilo Rueda et Antoine Bonnet, pour la génération de structures harmoniques et rythmiques à l'aide de contraintes.
· AS->PW, par Peter Hanappe, pour la communication synthèse/CAO.
· C-sound, par Laurent Pottier, pour la communication entre PW et le langage de synthèse Csound.
· RepMus, par Claudy Malherbe et Gérard Assayag, pour des manipulations symboliques de structures musicales.
1.3.2 Programmation par Objets : MusES.
La programmation par objets est appréciée entre autres pour la facilité de partage des structures de données et de contrôle. Dans le cas particulier de la CAO, on voit clairement l'utilité des objets, car très souvent les différents types de paramètres musicaux obéissent à un comportement homogène. Une autre caractéristique des langages à objets, la réusabilité, est presque nécessaire pour les langages de CAO, car la démarche artistique demande constamment l'extension des objets préalablement construits. Plus généralement, l'extensibilité des langages à objets permet de construire des applications plus dynamiques ; les langages à objets permettent d'insérer des nouveaux objets, ce qui dans autre style de programmation revient souvent à réécrire le programme. Si l'on ajoute à cela l'aspect "naturel" de la notion d'objet nous voyons que la programmation par objets est un très bon paradigme pour la CAO.
Plusieurs travaux relatifs à la programmation par objets et à la CAO ont été réalisés. Dans [DeHo94] on trouve la formulation d'un système de représentations musicales en CLOS. Nous citons aussi le système MODE [Pope91], ainsi que Common Music [Taub91]. Pour une synthèse de travaux plus complète, voir [RoPa97]. Le système MusES [Pach97] est un représentant caractéristique de cette approche.
Le système MusES, conçu et implémenté en SmallTalk par François Pachet, est un environnement qui fournit une bibliothèque de classes pour l'expérimentation dans le domaine de la musique tonale. En plus de contenir la représentation des concepts de l'harmonie (i.e. intervalles, échelles, accords, etc.) et leurs manipulations les plus courantes ; MusES possède aussi une collection de connaissances consensuelles au sujet de l'harmonie tonale.
L'une des particularités de base de MusES est la définition d'une classe pour représenter la notion de note de façon indépendante de l'octave et des altérations. Ainsi le système est capable de rendre compte de la différence dans "l'intention harmonique" des notes Eb et D#, par exemple, bien qu'elles soient équivalentes au niveau de leur fréquence dans un système tempéré. Dans MusES, les notes sont des instances de classes représentant la notion musicale de pitch-class (classe de notes modulo 12). Les altérations à leur tour sont des méthodes définies par les classes de notes. Ainsi chaque classe de note résout pour son compte les problème d'enharmonie en tirant parti du polymorphisme.
En se basant sur les définitions basiques, d'autres notions plus complexes sont additionnées au système, la limite de la bibliothèque étant fixée de manière arbitraire. MusEs possède aussi des éditeurs musicaux graphiques. Ces éditeurs sont utilisés principalement pour la visualisation de mélodies et de séquences d'accords sous la forme de grilles.
Figure 1-11 Editeur de mélodies en MusES.
Figure 1-12 Editeur de séquences d'accords en MusES.
Plus qu'une application, MusES doit être vue comme " une couche de base de représentation, utilisée pour construire des applications ". Nous citons parmi les applications plus représentatives : la simulation des improvisations de jazz, en temps réel ; un système d'analyse des séquences d'accords ; l'extraction automatique des motifs dans un corpus improvisé de jazz et un système d'harmonisation automatique. Nous allons détailler cette dernière application dans 1.3.3.3. Une description complète de MusES se trouve dans [Pach94].
1.3.3 Programmation par contraintes.
La programmation par contraintes est de nos jours un domaine de recherche très actif, dont l'application à la CAO est reconnue. Nous allons décrire trois systèmes : PwConstraints, Situation et BackTalk ; ces systèmes sont basés sur la notion de programmation comme recherche d'éléments satisfaisant un certain nombre de propriétés ou contraintes. PWConstraints et Situation ont été implémentés à l'origine sous la forme de librairies PatchWork. Les deux systèmes offrent la possibilité de construire des structures musicales à l'aide de la technique de satisfaction de contraintes. Ils diffèrent significativement dans les stratégies et algorithmes utilisées de même que dans leurs domaines d'application. Comme pour PatchWork, PWConstraints est neutre dans le sens où il n'existe pas d'effort pour favoriser une notion particulière d'objet musical. En effet, en suivant l'esprit de PatchWork, les objets sont musicaux dans la mesure où le compositeur décide de les interpréter comme tels. Les éléments que le moteur de résolution de PWConstraints essaie de trouver ne possèdent pas nécessairement une structure complexe comme celle des objets musicaux prédéfinis dans PatchWork, bien que de telles structures puissent être utilisées pendant la résolution. Situation de son côté définit une structure très générale pour les objets qu'il traite. Ses objets doivent être exprimables sous la forme d'ensembles de points et de distances sur un certain espace. Avec cette structure, on peut facilement exprimer des accords, des séquences d'accords, des voix, des motifs rythmiques, etc. Le fait que situation connaisse la structure des objets qu'il cherche permet une grande optimisation de la recherche dans la plupart des applications particulières. Il est évident que tous les problèmes ne peuvent pas être exprimés avec ce type de structure ; pour cela Situation est aussi capable de traiter des objets arbitraires, mais dans ce cas l'optimisation n'est pas appliquée.
BackTalk est une librairie pour MuSES implémentant un moteur général de contraintes dans lequel tous les concepts inhérents à ce paradigme de programmation (variables, contraintes, etc.) sont réifiés sous la forme de classes SmallTalk.
PWConstraints est un système basé sur des règles qui permet la résolution de problèmes musicaux complexes où l'utilisateur décrit le résultat final sous divers points de vue. PWConstraint a été conçu et implémenté en Common Lisp par Mikael Laurson [Laur93] et tourne comme une librairie dans l'environnement PatchWork. L'écriture de contrepoints est un bon exemple de ce que peut faire PWConstraints. Le résultat désiré est décrit par le compositeur à l'aide de règles contrôlant les lignes mélodiques, l'harmonie, la direction horizontale de chaque voix, etc. La première étape que le compositeur doit réaliser lors de l'utilisation de PWConstraints est liée à la définition d'un espace de recherche. Grâce à un algorithme de backtracking, PWConstraints cherche systématiquement des solutions en produisant des résultats potentiels qui satisfont un ensemble de contraintes donné. L'espace de recherche est défini comme un ensemble de variables. Chaque variable a un domaine consistant en un ensemble de valeurs. PWConstraints offre à l'utilisateur un protocole pour l'écriture de règles. Ainsi un algorithme de pattern-matching est utilisé pour l'extraction d'information pertinente pour une solution potentielle. Cette information est donnée à une fonction Lisp de test qui accepte ou rejette la solution potentielle proposée par le moteur de recherche. Le compositeur peut aussi définir des préférences à l'aide d'heuristiques.
PWConstraints contient plusieurs extensions. La plus importante est destinée à la résolution de problèmes polyphoniques. Comme dans une partition polyphonique l'utilisateur agit à différents niveaux. La structure rythmique est donnée a priori par l'utilisateur et le moteur cherche à la remplir avec des hauteurs obéissant aux règles données.
Figure 1-13 Un programme en PWConstraints.
Dans [Laur96], le lecteur trouvera une description de l'utilisation de PWConstraints ainsi que de nombreux exemples.
Situation, écrit par Camilo Rueda en collaboration avec le compositeur Antoine Bonnet [RuBo98] permet la construction d'objets à partir de deux notions : les points et les distances. Un objet contient un ou plusieurs points espacés par certaines distances exprimées par une unité donnée. Les distances peuvent être internes ou externes aux objets. Les intervalles dans un accord sont des distances internes, tandis que les intervalles mélodiques (entre accords) sont des distances externes. L'unité de mesure dans le cas des intervalles peut être le demi-ton, le quart de ton ou une autre division définie par l'utilisateur. Le rythme peut être vu comme un objet contenant un ensemble de points d'articulation espacés par des distances temporelles exprimées par rapport à une unité rythmique arbitraire (e.g. la croche).
La spécification d'un problème dans Situation consiste à fournir le nombre d'objets désirés, l'espace de possibilités pour les points, le nombre de distances dans chaque objet et l'ensemble des possibilités pour les valeurs de ces distances. La construction des contraintes est le moyen de spécifier chaque objet ainsi que les relations entre objets. Tout point ou toute distance d'un objet ou d'un ensemble d'objets peuvent être mis en relation par une contrainte. La construction des contraintes établit des profils généraux que les objets doivent suivre. Le lecteur trouvera dans [Rued98] une description technique de Situation. L'annexe I de ce texte expose la manière dont Situation a été intégré à OpenMusic ainsi que quelques exemples.
1.3.3.3. BackTalk.
BackTalk est un moteur de résolution de contraintes écrit par Pierren Roy et François Pachet en Smalltalk-80 (Visual Works, 2.5). BackTalk est conçu comme une bibliothèque de classes pour résoudre des problèmes de satisfaction de contraintes à domaines finis.
L'implémentation de BackTalk est basée sur la réification systématique des concepts principaux de la satisfaction de contraintes :
En outre, BackTalk fournit un ensemble d'heuristiques prédéfinies, qui sont organisées en une hiérarchie de classes. La définition d'heuristiques par l'utilisateur est également admise. BackTalk ne présente aucune extension syntaxique du langage SmallTalk, car la formulation et la résolution des problèmes sont réalisées en utilisant des éléments et des techniques standard de la programmation par objets : instantiation de classes et envoi de messages. Considérons par exemple le problème suivant : trouver deux nombres p et q entiers, tels que l'égalité p + 2.q = 0 soit satisfaite. De plus, p est un nombre entre 1 et 10, et q appartient à l'ensemble {1, 3, 5, 7, 9, 11}. Le code de ce problème en BackTalk est le suivant :
| pb p q |
"création des deux variables comme instances de la classe BTVariable"
p := BTVariable label: 'p' from: 1 to: 10.
q := BTVariable label: 'q' domain: #(1 3 5 7 9 11).
"formulation de la contrainte entre p et q"
p - (2 * q) @= 0.
"création du problème"
pb := BTSolver new
label: 'my first BackTalk problem' ; "nom du problème"
variables: (Array with: p with: q) ; "ses variables"
print: p; print: '- 2.'; print: q; print: '=0'.
^pb
Si nous envoyons le message printFirstSolution à l'objet pb le résultat sera :
pb printFirstSolution 2 - 2.1 = 0
Si nous envoyons le message printAllSolutions à l'objet pb le résultat sera :
pb printAllSolutions
2 - 2.1 = 0
6 - 2.3 = 0
10 - 2.5 = 0
No more solution
BackTalk a été utilisé avec succès dans plusieurs applications. En ce qui concerne la musique, l'un des projets les plus intéressants est l'élaboration d'un système automatique d'harmonisation pour la musique tonale. Ce système résout des exercices d'harmonie comme ceux qui sont donnés aux étudiants dans les écoles de musique : étant donné une mélodie simple, le but est d'établir un accompagnement à quatre voix qui respecte les règles de l'harmonie tonale. La voix soprano de la pièce résultante correspond à la mélodie donnée comme entrée.
La satisfaction de contraintes et l'harmonie musicale ont souvent été mises en relation. Parmi les travaux les plus représentatifs, citons : le système CHORAL de Kémal Ebcioglu [Ebci92] ; les travaux de Russel Ovans qui utilisent la programmation logique par contraintes [Ovan92] ; ainsi que ceux de Philippe Ballesta et Ilog Solver. Tous ces travaux sont à peu près basés sur le même principe : les variables du problème représentent les objets atomiques du problème comme les notes. Les règles d'harmonies sont donc représentées comme des relations entre ces éléments atomiques. Cette approche complique la définition des règles musicales et conduit à des problèmes complexes et donc difficiles à résoudre.
C'est pour cette raison que Pierre Roy propose une approche radicalement différente. Dans BackTalk, les variables du problème représentent les objets musicaux complexes (comme les accords). Ainsi la définition des règles musicales est plus simple car elle peut se faire dans un langage de plus haut niveau. De plus, les performances finalement obtenues sont en très nette amélioration par rapport aux systèmes similaires existants.
À titre d'exemple voici comment Backtalk peut harmoniser une mélodie bien connue :
Figure 1-14 Une harmonisation dans BackTalk.
BackTalk a été implémenté comme une librairie du système MusES. Le lecteur intéressé par BackTalk et l'intégration des contraintes et des objets en général peut se référer à [RoPa97] et [PaRo95].
1.3.4 Programmation fonctionnelle, objet, visuelle : OpenMusic.
OpenMusic est un environnement de CAO permettant de combiner les approches fonctionnelles, objet, visuelle et par contraintes. Mis au point dans le cadre de l'équipe représentations musicales de l'Ircam, il constitue l'objet central de cette thèse et sera complètement détaillé dans les chapitres 2 et 3. Nous donnons ici un résumé des buts qui ont présidé à la conception d'OpenMusic :
Plus généralement nous voulons disposer d'un langage de CAO qui soit extensible ; qui permette le polymorphisme dans la mesure où la plupart des structures partagent certaines propriétés. Nous voulons aussi un langage dynamique, et qui fournisse des protocoles qui permettent de spécifier les concepts et définitions propres à un compositeur particulier. Notre langage doit posséder un grand pouvoir d'expression dans la mesure où il s'agit d'un environnement de créativité.
L'enjeu est ici d'intégrer tous les aspects mentionnés précédemment, que l'on peut par ailleurs retrouver de manière fragmentaire dans d'autres environnements, en une architecture cohérente et simple d'utilisation.