# ÉTUDE ET APPROPRIATION DE L'AUGMENTATION INSTRUMENTALE
## PROPOSÉE PAR JEAN-CLAUDE RISSET DANS L'ÉLABORATION
## DE SES DUOS POUR UN PIANISTE

Sébastien Clara

Université Lyon – Saint-Étienne

sebastien.clara@univ-st-etienne.fr

## RÉSUMÉ

En 1989, Jean-Claude Risset est invité au Media Lab du M.I.T. en tant que compositeur en résidence. Il élabore un dispositif réactif autour d'un piano reproducteur Disklavier commercialisé par la firme Yamaha. Avec cette gamme de piano, Yamaha effectuait une mise à jour au standard de la fin du XXe siècle du piano dit mécanique. Les pianos mécaniques génèrent de la musique automatiquement et ils ont bénéficié d'une grande popularité au début du XXe siècle. Le piano reproducteur est quant à lui capable d'enregistrer l'exécution d'une pièce en temps réel et de la reproduire fidèlement. Jean-Claude Risset a détourné la fonction de ce piano reproducteur pour construire un instrument augmenté et compose avec celui-ci une série de pièces qu'il intitule *Huit esquisses en duo pour un pianiste*.

Dans cet article, nous retraçons les différents développements que nous avons réalisés autour des pièces composées par Jean-Claude Risset durant cette résidence. Nous étudierons en premier l'augmentation instrumentale établie par Jean-Claude Risset pour personnaliser et varier les réponses de son automate suivant les particularités d'une interprétation. Puis, nous relaterons notre appropriation de l'augmentation de son instrument.

## 1. INTRODUCTION

En 1989, Jean-Claude Risset expérimente plusieurs modalités d'interaction entre un musicien et un automate lors de sa résidence au M.I.T. Il conclut ce travail de recherche par la composition d'une série de pièces qu'il intitule *Huit esquisses en duo pour un pianiste*. Son dispositif se compose d'un ordinateur et d'un piano acoustique, mais de type automatophone.

Un automatophone est un instrument de musique couplé à un mécanisme qui permet de simuler le jeu d'un instrumentiste. Il peut être actionné automatiquement ou par un humain. Dans l'imaginaire occidental, l'automatophone correspond à l'orgue de Barbarie des joueurs de rue ou au piano dit mécanique. La culture populaire a utilisé ces pianos comme un personnage des saloons de l'ouest sauvage des États-Unis du début du XXe siècle, jouant sans peur et

inlassablement des Ragtimes très en vogue à ce moment-là.

Le principe du codage de la musique des automatophones voit le jour à Bagdad au IXe siècle. La fratrie Banu Musa met au point un automate joueur de flûte, mû par la force hydraulique. Les leviers qui obstruent les trous de la flûte sont commandés par un cylindre à picots. La mélodie est programmée suivant la disposition spatiale des picots sur le cylindre. L'écoulement de l'eau dans le système met en mouvement le cylindre. Les picots déclenchent alors la levée et la descente des leviers et modifient la note émise par la flûte [3].

De nombreux compositeurs<fnref n="1" /> se sont approprié ces automates, mais ces machines génèrent de la musique régulière, inapte à entamer un dialogue expressif avec un musicien. Les automatophones étaient généralement utilisés pour reproduire la musique populaire ou religieuse, mis à part quelques exemples créatifs notables durant le XXe siècle [5].

L'essor de l'électronique pendant le XXe siècle a augmenté significativement l'importance de l'automatisation dans nos sociétés et a entraîné la création de nouveaux outils destinés à la production sonore, notamment le synthétiseur, le séquenceur ou l'arpégiateur<fnref n="2" />. Cependant, le principe de codage de la musique du cylindre à picots a été transposé<fnref n="3" /> sur ces nouveaux instruments, avec sa rigueur métronomique jusqu'à aujourd'hui dans nos stations audionumériques.

À la fin des années 1950, Max Mathews crée le premier logiciel de synthèse sonore. Toutefois, les ordinateurs de cette période demandent plusieurs minutes pour calculer une seconde de son. Dans ces

<footnote n="1">¹ Joseph Haydn (Hob. XIX: 1–32), Wolfgang Amadeus Mozart (K. 594, 608 et 616), Ludwig van Beethoven (Op. 91, arrangé ultérieurement pour orchestre), Igor Stravinsky (Étude pour Pianola), György Ligeti (certaines études pour piano), etc. À noter que Conlon Nancarrow a consacré sa production au piano automatique.</footnote>

<footnote n="2">² La fonction de l'arpégiateur est de transformer un accord en arpège suivant un tempo donné. Il fonctionne en temps réel et il dispose de plusieurs paramètres pour varier ses réponses. À partir des années 1980, cette fonction est régulièrement implantée dans les synthétiseurs. Aujourd'hui, elle est disponible par défaut dans la majorité des stations audionumériques ou par l'adjonction de logiciels tiers.</footnote>

<footnote n="3">³ De même pour l'industrie avec l'automatisation du métier à tisser par rubans perforés ou de l'informatique avec son système d'entrée-sortie par cartes perforées.</footnote>
conditions, l'interaction musicale entre une machine
numérique et un humain est impossible. À la fin des
années 1960, Mathews et Moore mettent au point le
système Groove pour pallier cette carence. Cependant,
Groove est un système hybride. En effet, l'ordinateur
n'est toujours pas capable de calculer des sons en temps
réel, mais il peut générer du contrôle en temps réel.
L'ordinateur commande alors un synthétiseur
analogique [9].

Les moyens technologiques limitent les possibilités
artistiques et c'est à partir des années 1980 que la
création de dispositifs interactifs ou réactifs [1] se
démocratise. Les ordinateurs deviennent plus
puissances, plus petits, plus abordables et ils ont à leur
disposition de plus en plus de mémoire. La norme MIDI
permet de découpler les contrôleurs et les modules de
production sonore et de créer des dispositifs hétérogènes
dont l'ordinateur peut devenir un maillon.

L'avènement de la norme MIDI ravive aussi l'intérêt
pour les interfaces homme-machines alternatives – quête
qui démarre avec les premiers instruments électroniques
comme les efforts fournis par Léon Theremin, Maurice
Martenot ou encore Donald Buchla, mais pour le
moment aucune n'a supplanté la popularité des
contrôleurs qui reproduisent la forme des instruments
acoustiques ou des équipements de studio [4].

Une autre approche de contrôle d'un dispositif
consiste à augmenter les capacités d'un instrument
acoustique ou électronique. Au M.I.T., Tod Machover
fait partie des pionniers de ce type de démarche avec
son projet d'hyperinstrument.

The hyperinstrument project was
started in 1986 with the goal of
designing expanded musical
instruments, using technology to give
extra power and finesse to virtuosic
performers. Such hyperinstruments
were designed to augment guitars and
keyboards, percussion and strings, and
even conducting. [...] The research
focus of all this work is on designing
computer systems (sensors, signal
processing, and software) that
measure and interpret human
expression and feeling, as well as on
exploring the appropriate modalities
and innovative content<fnref n="4" />.

Deux modalités de contrôle sont possibles pour
augmenter un instrument. La première consiste à ajouter
des contrôleurs à l'instrument. Cette méthode implique
l'apprentissage de nouveaux gestes de la part du
musicien pour maîtriser ce type d'augmentation.
L'exemple emblématique de cette méthode est
l'augmentation de la guitare. L'amplification électrique
a permis à cet instrument acoustique de faible intensité
sonore de devenir un instrument soliste de premier plan

dans l'orchestre. Mais l'électricité a aussi permis de
modifier radicalement son timbre. L'insertion d'une ou
plusieurs pédales d'effet entre la guitare et
l'amplificateur fournit des contrôles en temps réel pour
altérer le timbre par des gestes inusités par la technique
instrumentale traditionnelle de cet instrument.

La seconde méthode pour réaliser un instrument
augmenté est transparente pour le musicien. À partir de
différents moyens techniques, un système capture une
performance instrumentale classique pour s'alimenter en
données et générer des réponses sonores. Jean-Claude
Risset a utilisé cette dernière méthode d'augmentation
pour construire son dispositif. En effet, Yamaha
commercialise un nouveau type de piano augmenté de
capteurs et de moteurs à partir de 1987. Le standard
MIDI permet à ce piano de dialoguer avec d'autres
machines équipées de ce protocole de communication.
Les capteurs indiquent les touches et les pédales
actionnées par un pianiste et les moteurs entraînent les
touches et les pédales du piano. Un ordinateur connecté
à ce type de piano peut donc « écouter » un pianiste
jouer ou commander le piano.

En 1989, les champs technique et conceptuel étaient
donc propices pour que Jean-Claude Risset puisse
réaliser son dispositif et composer sa série de pièces. Le
Disklavier de Yamaha reprend le principe du piano
reproducteur élaboré au début du XXe siècle. Le but de
ce piano est de saisir l'expressivité<fnref n="5" /> d'une interprétation
en temps réel et de la restituer le plus fidèlement
possible. La norme MIDI a permis à Jean-Claude Risset
de détourner la fonction de ce type de piano pour
fabriquer un instrument augmenté. Dans cet article, nous
nous focalisons exclusivement sur la solution
développée par Jean-Claude Risset. Toutefois, des
compositeurs ou des Réalisation s en Informatique
Musicale ont proposé des dispositifs instrumentaux
alternatifs [6].

## 2. PRÉSENTATION DES DUOS POUR UN PIANISTE

Jean-Claude Risset compose ses différents duos au
cours de deux résidences au M.I.T. La première date de
1989 et il nomme ces études *Duo pour un pianiste : huit
esquisses pour piano MIDI et ordinateur*. Le titre des
pièces évoque l'opération d'augmentation mise en
œuvre.

> Double. Le pianiste joue seul, puis
> à la reprise l'ordinateur ajoute des
> ornements. Ces ornements pré-
> enregistrés interviennent quand le
> pianiste joue certaines notes ; leur
> tempo peut être influencé par le tempo
> du pianiste.

<footnote n="4">⁴ http://opera.media.mit.edu/projects/hyperinstruments.html, dernière
consultation le 20/03/18.</footnote>

<footnote n="5">⁵ Cette problématique est déjà présente au XVIIIᵉ. Dans son traité sur l'art de noter les cylindres, Marie-Dominique-Joseph Engramelle signale l'écart entre la notation musicale et la pratique des musiciens et focalise son attention sur la transcription de ces détails d'expression [2].</footnote>
Miroirs. À chaque note jouée par le pianiste répond la note symétrique par rapport à certaine note du clavier – un procédé utilisé dans la seconde Variation op. 27 de Webern, citée au début (et aussi à la fin, à l'écrevisse). Les centres de symétrie et les retards de réponse sont variés au cours de la pièce.

Extensions. Aux arpèges joués par le pianiste, l'ordinateur ajoute des arpèges transposés.

Fractals. À chaque note jouée, l'ordinateur ajoute cinq notes espacées d'une octave altérée. Alors les mélodies jouées par le pianiste sont étrangement distordues : une montée d'une octave est perçue comme une descente d'un demi-ton.

Agrandissements. Comme dans Extensions, l'ordinateur ajoute des notes, mais les intervalles sont non pas transposés, mais agrandis dans des rapports allant de 1,3 à 2,7, ce qui agrandit les intervalles mélodiques et harmoniques.

Métronomes. Au début, l'ordinateur répond en canon, sur des hauteurs transposées et à des tempos plus rapides. Puis il joue simultanément plusieurs séquences à des tempos différents. Enfin il répète les mêmes hauteurs, mais encore à des tempos métronomiques différents, soit établis à l'avance, soit décidés par le pianiste.

Up-down. Des arpèges d'octaves altérées sont déclenchés par le pianiste, qui voit ses notes proliférer. Le tempo des arpèges est établi d'abord par le tempo du pianiste ; puis la note qu'il joue ; enfin par l'intensité du jeu.

Résonances. Au début et à la fin, l'ordinateur tient de longs accords. Dans la section médiane, le pianiste joue des accords muets : les cordes sont mises en résonance par les séquences jouées par l'ordinateur [7].

La seconde résidence date de 1991 et Risset l'intitule *Trois études en duo*. Le principe et le dispositif sont identiques à ceux de la première résidence. Cependant, il symbolise les opérations d'augmentation utilisées dans ces études par des personnages tirés de la mythologie grecque.

Echo. L'ordinateur fait écho au pianiste, mais il ne s'agit pas d'une simple répétition : les échos sont transposés en hauteur et en tempo, et ils interviennent avec des retards variés. Cette étude tire parti des résonances sur la table d'harmonie des notes jouées par le pianiste aussi bien que par son partenaire virtuel.

Narcisse. Ici la relation s'apparente à la réflexion par un miroir : les intervalles mélodiques sont renversés – une quarte devient une quinte et vice-versa. Le centre de symétrie est une note du clavier qui varie dans le courant de la pièce. La réflexion peut aussi intervenir avec un retard variable.

Mercure. Il s'agit d'une sorte de scherzo dans lequel le pianiste déclenche des arpèges à différentes vitesses. Le tempo des arpèges dépend soit du tempo de certains groupes de notes jouées par le pianiste, soit de la hauteur, soit de l'intensité de son jeu. Les arpèges investissent l'espace des hauteurs un peu à la façon des formes d'un kaléidoscope.<fnref n="6" />

Le glissement entre le mythe d'Écho et de Narcisse et les opérations musicales de canon et de renversement est clair. Toutefois, l'invocation de Mercure est moins évidente à saisir. En effet, cette divinité est le protecteur du commerce, des voleurs, des voyages et le messager des dieux. Une technique de communication longue distance, ancêtre du sémaphore que l'on trouve durant l'Antiquité grecque, transmet une information par un signal visuel de relais en relais jusqu'à son destinataire.

Clytemnestre : Héphaistos, en lançant de l'Ida une flamme brillante, puis, de feu en feu, le message igné est venu jusqu'à nous. L'Ida l'a envoyé au rocher d'Hermès, à Lemnos ; de l'île, l'éclatante lumière a été captée au troisième relais, au mont Athos voué à Zeus, puis franchissant d'un bond vigoureux les crêtes de la mer, l'ardent flambeau voyageur s'est élancé avec joie <...> et la torche a transmis sa clarté dorée, soleil de nuit, au poste de guet du Makistos.<fnref n="7" />

La propagation d'une note par les arpèges générés automatiquement pourrait se comparer à la propagation de l'information de la chute de Troie de la tragédie d'Eschyle. De torche en torche, ce message court au-

<footnote n="6">⁶ Note de programme, http://brahms.ircam.fr/works/work/11507/#program, dernière consultation le 20/03/18.</footnote>

<footnote n="7">⁷ ESCHYLE, *Agamemnon*, La Différence, Paris, 2004, p. 177.</footnote>
dessus des montagnes et de la mer jusqu'à
Clytemnestre. Toutefois, notre proposition sur la raison
de Jean-Claude Risset d'intituler cette pièce Mercure
reste une hypothèse. Aucun des documents que nous
avons consultés n'apporte de précision sur cette
question.

Par la suite, Jean-Claude Risset fusionne les travaux
produits durant ces deux résidences lorsqu'il interprète
ces pièces. Le nom générique Duo pour un pianiste fait
donc référence indistinctement aux pièces de ces deux
résidences.

### 3. LES PRINCIPAUX ALGORITHMES DES DUOS

Nous avons recensé dans cette section les principales
briques algorithmiques utilisées par Jean-Claude Risset
pour élaborer son augmentation instrumentale. Pour
effectuer ce travail, nous avons consulté les patchs Max
réalisés par le compositeur. Pour ce faire, nous avons
utilisé l'émulateur Basilisk II des versions 7 et 8 du
système d'exploitation de Macintosh. Sous cet
émulateur, nous avons utilisé Max 3 pour sauvegarder
les patchs en version texte. Nous avons pu alors les
ouvrir et les adapter avec Max/MSP 7 sous un système
d'exploitation récent et entièrement fonctionnel.

Pour alimenter les algorithmes de ces duos, Jean-Claude Risset exploite les données générées en temps réel par le pianiste. Les renseignements transmis par une note MIDI sont sa hauteur, sa vélocité, le moment de son l'attaque et de son relâchement. Une horloge est couplée aux transitoires des notes et elle permet de déterminer la durée des notes et la durée entre les attaques des notes. Ces données peuvent être sauvegardées pour réaliser des échos par exemple ou être consommées dans l'instant.

Risset programme principalement des algorithmes
qui transforment la hauteur et la durée des notes jouées
par un pianiste. Mais il parallélise aussi les traitements
tout en les configurant différemment. Il peut ainsi varier
la densité des notes générées par l'automate. De plus,
l'action de la pédale una corda du piano stoppe tous les
algorithmes en cours d'exécution et oblige l'automate
au silence. Nous classons ces algorithmes en trois
catégories avec pour critère de discrimination les
traitements réalisés sur la hauteur, le temps et les
traitements conditionnels.

#### 3.1. Traitement de la hauteur

* Transposition :
  `noteMidi + transpoDemiTon`

* Renversement :
  `(pointDeSymétrie * 2) - noteMidi`

* Accord et arpège à partir d'une note :

Exécution parallèle de l'algorithm e de transposition
avec un contrôle du délai d'exécution sur chaque
branche. Si les délais sont identiques, les notes seront
jouées simultanément. Sinon le programme égrainera
l'énoncé des notes dans le temps et produira un arpège.

* Agrandissement :
  `noteMidi * coefAgrandissement`

#### 3.2. Traitement temporel

* Agrandissement d'une durée :
  `duréeNoteMidi * coefAgrandissement`

* Détermination d'un tempo après trois notes
  attaquées :
  `120 / (dateNoteOnT3 - dateNoteOnT1)`

* Répétition d'une note :
  Tant Que répétitionPorte est
  ouverte Faire ...

#### 3.3. Traitement conditionnel

* Sensibilisation d'une réponse :
  `Si vélocitéNoteMidi < vélocitéSeuil`
  `Alors coefAgrandissement <-- 1.3`
  `Sinon coefAgrandissement <-- 0.7`

* Déclenchement d'une action suivant un
  groupement de notes jouées :
  `Si (noteMidi == noteMidiPivot) &&
  (noteMidi-1 == noteMidiPivot-1)`
  `Alors déclenchement d'une action`

Dans le vocabulaire de Jean-Claude Risset, ce
traitement conditionnel est encapsulé dans l'objet : *trig2*
*noteMidiPivot-1* *noteMidiPivot* (cf. figure 1).

### 4. MISE EN ŒUVRE DES OPÉRATIONS

La figure 1 représente la première partie du patch
Max de la pièce *Miroirs* et elle nous indique la
progression du paramétrage de l'opération de
renversement. À l'initialisation du programme, le point
de symétrie de l'opération reçoit la note MIDI 69. Le
délai avant que l'automate joue les notes renversées est
de 175 ms. La première note pivot (la note MIDI 27) est
activée. À ce moment, toutes les notes jouées par le
pianiste seront renversées suivant la note point de
symétrie avec une latence d'exécution de 175 ms.
Toutes les notes, sauf la note MIDI 27. Lorsque celle-ci
sera jouée par le pianiste, un nouveau paramétrage
algorithmique sera mis en place. Le point de symétrie deviendra la note MIDI 85 et la prochaine note pivot sera la note MIDI 64. Le délai avant de jouer les notes renversées n'est pour le moment pas modifié.

<figure><img src="image_36.png" /><figcaption>**Figure 1.** Première partie du patch Max de la pièce Miroirs [8].</figcaption></figure>

La pulsation de cette pièce est de 120 à la noire. Jean-Claude Risset note uniquement les barres de mesures du premier système. Nous sommes à 4/4, mais il ne l'écrit pas. Ces premières barres de mesures montrent la carrure générale des prochains systèmes, mais l'interprète n'a pas à suivre cette contrainte. Le premier déclenchement est placé sur le premier temps de la quatrième mesure. La première modification des paramètres de l'algorithme est donc programmée six secondes après le début de la pièce. La deuxième est prévue dix secondes après cette première modification et ainsi de suite.

Dans *Miroirs*, le paramétrage de l'opération est fixé par le compositeur, mais il évolue durant toute la pièce à une fréquence assez soutenue comme nous venons de le voir. Ces modifications récurrentes altèrent la régularité des réponses générées par l'automate. Nous représentons cette réalisation par la figure 2. À

l'initialisation du système, le traitement reçoit des arguments opératoires puis les notes à traiter, mais certaines notes provoquent des changements de paramètres.

<figure><img src="image_37.png" /><figcaption>**Figure 2.** Automatisation passive, mais avec une évolution des paramètres du traitement.</figcaption></figure>

D'autre part, pour rendre les réponses de l'automate actives et sensibles au jeu du pianiste, Jean-Claude Risset conditionne les valeurs du paramétrage d'un algorithme aux caractéristiques des notes jouées en temps réel. De même que pour un paramétrage passif, ces conditions évoluent durant le déroulement de la pièce. Par exemple, dans la pièce *Mercure* « le tempo des arpèges dépend soit du tempo de certains groupes de notes jouées par le pianiste, soit de la hauteur, soit de l'intensité de son jeu ».

Deux types de configurations alimentent les opérations, les arguments passifs et actifs. Mais en plus, ces deux types d'arguments évoluent durant l'exécution de la pièce. La figure 3 représente l'ensemble des possibilités de paramétrage d'une opération utilisé par Jean-Claude Risset pour élaborer la réactivité de son système.

<figure><img src="image_38.png" /><figcaption>**Figure 3.** Automatisation active.</figcaption></figure>
De plus, Jean-Claude Risset emploie des rapports
toujours complexes entre les paramètres d'une opération
afin de pulvériser la plupart des relations synchrones
dans ses duos. Dans la première partie de *Miroirs* (figure
1), le rapport entre le premier délai et le deuxième avant
que l'automate produise une réponse est de 20/7. Par
ailleurs, le premier délai de réponse de l'automate n'est
pas synchronisé au tempo du pianiste, noté 120 à la
noire et provoque un écart entre la pulsation du pianiste
et celle de l'automate. À la deuxième note pivot, le délai
de réponse de l'automate (de la durée d'une noire) et le
tempo du pianiste se synchronisent. Mais dans la
seconde partie du programme, Risset restaure cette
dichotomie entre les pulsations et il l'entretiendra
jusqu'à la fin de la pièce.

Dans les différents duos, l'automate génère
généralement des réponses asynchrones par rapport aux
données produites par le pianiste. Néanmoins, les
protagonistes de ces duos utilisent le même instrument.
L'auditeur ne perçoit pas un dialogue ou le
développement d'une opération compositionnelle, mais
un monologue riche, plus ou moins dense. Dans le
dispositif établi par Jean-Claude Risset, l'automate
rempli la fonction d'augmentation instrumentale en
accompagnant ou en amplifiant le jeu du pianiste. Pour
varier le discours musical et briser la monotonie des
réponses de son système, Risset fait fluctuer par
différentes méthodes les relations qui lient l'automate au
pianiste.

5. APPROPRIATION DES DUOS

Nous nous sommes approprié les principes établis par
Jean-Claude Risset dans l'élaboration de ces duos pour
présenter un instrument augmenté lors de l'exposition
IA² organisée dans les locaux de l'université de Saint-
Étienne pour animer les événements alternatifs (Off) de
la Biennale Internationale Design 2017 de Saint-
Étienne. Pour ce faire, nous disposions d'un piano
Schimmel TwinTone. Ce modèle est un piano droit
equipé d'un synthétiseur. Les entrées MIDI du
synthétiseur ne contrôlent pas la partie mécanique du
piano. Cette caractéristique technique implique que
notre automate peut produire des sons uniquement
synthétiques.

L'avantage de cette contrainte technique est que nous
n'avons pas été confrontés au problème de réinjection
des données dans la boucle établie entre les
entrées/sorties MIDI de l'ordinateur et du piano ni aux
distorsions rythmiques induites par des latences
variables des événements pour commander le piano. Ces
problèmes et leur solution sont discutés dans l'article
rédigé par Jean-Claude Risset et Scott Van Duyne [8].
L'inconvénient de cette contrainte technique est la piètre
mixité entre les parties acoustique et synthétique du
piano. Pour homogénéiser le résultat sonore de notre
installation, nous avons décidé d'utiliser uniquement le
son du synthétiseur.

Notre augmentation instrumentale propose au public
d'explorer six modes opératoires sensibles. Les notes les
plus graves du piano permettent de changer de mode et
l'action de la pédale *una corda* stoppe l'automate. Pour
faciliter l'interaction entre le public et l'automate, nous
affichons son état sur un écran. Nous utilisons ce retour
visuel pour présenter les différents contrôles, stipuler et
donner une explication du mode opératoire sélectionné
et indiquer les notes jouées par l'automate (cf. figure 4).

<figure><img src="image_39.png" /><figcaption>**Figure 4.** Retour visuel de l'état de notre
automate.</figcaption></figure>

Pour stabiliser l'expérience des utilisateurs, nous
avons utilisé uniquement une configuration active pour
conduire l'augmentation de notre instrument. Fixer le
paramétrage du système participe à la compréhension
globale des utilisateurs et accélère l'apprentissage du
fonctionnement du dispositif. Sensibiliser les réponses
de l'automate décuple l'expérience récréative de
l'installation et procure une plus grande satisfaction
lorsqu'on maîtrise musicalement cette augmentation.
Pour les personnes qui possèdent aucune notion
musicale, le retour visuel donne une clé d'écoute pour
comprendre le principe d'un instrument augmenté.

De plus, si l'installation n'est pas utilisée un certain
temps, elle émet un appel. Suivant le lieu d'exposition,
nous avons implanté deux types de signaux. Le premier
joue des extraits du répertoire occidental classique pour
piano. La seconde solution enregistre le jeu des
utilisateurs de l'installation et transforme ces données
pour produire un appel.

Nous avons réalisé notre installation avec Max/MSP.
Cependant, la majeure partie de notre système est
développée en JavaScript dans des objets Max dédiés.
Le fonctionnement asynchrone des tâches JavaScript
nous a semblé approprié pour répondre à nos attentes.
En effet, une tâche JavaScript est une fonction que l'on
gère dans le temps. On peut lui spécifier un nombre
d'exécutions, une condition d'arrêt particulière, la
stopper manuellement, etc<fnref n="8" />. Pour ne pas saturer l'espace
sonore par une accumulation des interventions de notre
automate, nous avons fixé le nombre de tâche pouvant
fonctionner en parallèle à trois.

<footnote n="8">⁸ https://docs.cycling74.com/max5/vignettes/js/jstaskobject.html,
dernière consultation le 20/03/18.</footnote>
Les principales actions de notre automate sont déclenchées lors de l'attaque ou du relâchement d'une note et suivant l'événement, notre automate réagit distinctement. Selon le mode opératoire sélectionné et ses conditions d'exécution, une réponse peut être délivrée (cf. figure 5).

<figure><img src="image_40.png" /><figcaption>**Figure 5.** Schéma du fonctionnement de notre automate.</figcaption></figure>

## 5.1. Exemple d'implémentation d'une opération

Pour traiter cet exemple d'implémentation, nous choisissons l'opération d'extension par ajout d'harmoniques. Cette opération est représentative de l'architecture de notre système. En effet, nous dédions un mode à cette opération (cf. la section 5.4). Nous l'exécutons dans ce mode lorsqu'une note est attaquée. Mais nous l'utilisons aussi dans notre dernier mode, où différentes opérations sont employées (cf. la section 5.7). Dans ce mode, nous l'exécutons au relâchement d'une note, si la durée de cette dernière est supérieure à une seconde et demi. Ces conditions d'exécution sont déterminées dans les blocs *midiOn operations* et *midiOff operations* de la figure 5.

Pour cette opération, le but de la tâche est de jouer une note de la série harmonique de la note jouée par le pianiste à chaque fois qu'elle est appelée. Par exemple, nous devons l'exécuter dix fois pour jouer les dix premières harmoniques de la note jouée par un pianiste. Une des propriétés des tâches JavaScript nous fournit le nombre de fois que la tâche a été appelée. Nous utilisons cette propriété pour déterminer le rang de l'harmonique à jouer (cf. lignes 4 et 5 de la figure 6). Nous avons

décidé que l'intensité des harmoniques diminuera suivant leur rang. Toutefois, l'amplitude de cette décroissance est corrélatée à la vitesse de la note jouée par le pianiste (cf. ligne 6 de la figure 6). La tâche dispose d'un contrôle pour vérifier la vraisemblance des données à émettre (cf. ligne 8 de la figure 6). Si le déroulement de cette tâche aboutit à produire des données invalides, elle met fin à son exécution (cf. ligne 11 de la figure 6).

```javascript
1 function overtonesOpe() {
2   var note = arguments.callee task Certificates[0][0];
3   var velocity = arguments.callee task Certificates[0][1];
4   var coef = arguments.callee task Iterations + 1;
5   var drift = freq2midi(midi2freq(note)*coef);
6   var amp = Math.round(velocity -
7     (arguments.callee task Iterations *midi2data(velocity, 0.01, 3)));
8   if((drift<128)&(amp>0)) {
9     outlet(0, [drift, amp, midi2data(velocity, 1000, 150)]);
10   } else {
11     arguments.callee task Cancel();
12   }
13 }
```

<caption>**Figure 6.** Tâche de l'opération d'extension par ajout d'harmoniques.</caption>

Nous gérons l'exécution de nos tâches avec un tableau. Nous l'initialisons pour qu'il contienne trois cellules, le nombre maximal de tâches pouvant fonctionner en parallèle. Nous l'utilisons comme une liste circulaire. Nous naviguons dans celui-ci avec un index que nous incrémentons de un à chaque appel d'une nouvelle tâche, modulo le nombre de cellules du tableau.

Avant d'affecter une nouvelle tâche à une cellule de notre tableau, nous nous assurons que la précédente est achevée. Si ce n'est pas le cas, nous l'interrompons (cf. ligne 2 de la figure 7, le test est réalisé dans la fonction *stopTask*). Nous affectons notre nouvelle tâche dans cette cellule pour qu'elle exécute l'opération d'extension par ajout d'harmoniques et nous la paramétrons avec les données MIDI fournies par le pianiste (cf. ligne 4 de la figure 7). Nous fixons une durée d'attente entre chaque itération de cette tâche. Toutefois, nous lions la valeur de cette durée à la vitesse de la note jouée par le pianiste (cf. ligne 5 de la figure 7). Enfin, nous exécutons et planifions quinze itérations de cette tâche (cf. ligne 6 de la figure 7). Cependant, l'exécution des quinze itérations de cette tâche sera menée à son terme seulement si les données qu'elle produit sont vraisemblables (cf. lignes 8 à 12 de la figure 6).

Nous pouvons exécuter une tâche JavaScript par différentes méthodes. Nous pouvons contrôler la vie d'une tâche par différents facteurs. Nous pouvons agir sur le fonctionnement des tâches en modifiant différentes propriétés. Cette variété d'usage favorise la flexibilité de notre système. Pour sensibiliser les réponses délivrées par notre automate, nous utilisons une mise à l'échelle classique entre les données MIDI fournies par le pianiste en temps réel et les paramètres de nos tâches. Dans les prochaines sections, nous
détaillons succinctement les différentes possibilités d'augmentation présentées au public.

1 function playOvertones(note, velocity, index) {
2 stopTask(taskRun[index]);
3
4 taskRun[index] = new Task(overtonesOpe, this, [note, velocity]);
5 taskRun[index].interval = midi2data(velocity, 1300, 25);
6 taskRun[index].repeat(15);
7 }

**Figure 7.** Gestion de la tâche de l'opération d'extension par ajout d'harmoniques.

## 5.2. Reflet

L'automate accompagne en miroir le pianiste. Le reflet est déterminé par le do central, point de symétrie de cette opération.

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

**Figure 8.** Opération de reflet.

## 5.3. Reflet propagé

L'automate accompagne en miroir le pianiste. Cependant, le reflet dérive d'octave en octave. La vitesse de la dérive est corrélée à l'intensité du jeu pianistique. Le reflet est déterminé par le do central, point de symétrie de cette opération.

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

**Figure 9.** Opération de reflet propagé.

## 5.4. Harmoniques

L'automate génère la série harmonique de la note jouée par le pianiste. La vitesse d'apparition des harmoniques est corrélée à l'intensité du jeu pianistique.

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

**Figure 10.** Opération d'extension par ajout d'harmoniques.

## 5.5. Répétition

L'automate répète la note jouée par le pianiste tout en ralentissant les itérations.

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

**Figure 11.** Opération de répétition.

## 5.6. Répétition transposée

L'automate répète une note plus grave que la note jouée par le pianiste tout en ralentissant les itérations. L'intervalle entre la note jouée et la note répétée est déterminé suivant l'intensité du jeu pianistique.

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

**Figure 12.** Opération de répétition transposée.

## 5.7. Opération multiple

Ce mode regroupe différentes opérations. Les échos sont exécutés si un intervalle particulier est joué et si le dispositif a enregistré plus de cinq notes.

Si l'intensité d'une note dépasse un certain seuil alors une répétition transposée est exécutée. Si la durée d'une note dépasse une seconde et demi alors l'ordinateur joue sa série harmonique. Si un intervalle d'octave est joué alors un double reflet (propagation dans les aigus et les graves) est exécuté. Si un intervalle montant de quarte est joué alors l'automate répète une section de notes jouée précédemment par le pianiste. L'écho est accéléré, rétrogradé et transposé symétriquement par rapport au do central.

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

**Figure 13.** Opération rétrograde et de symétrie d'un écho.

Si un intervalle de triton est joué alors l'automate répète une section de notes jouée précédemment par le pianiste. L'écho est accéléré, rétrogradé et transposé d'un demi-ton plus grave.
<figure><img src="image_47.png" /><figcaption>**Figure 14.** Opération rétrograde, d'accélération et de transposition d'un demi-ton plus grave d'un écho.</figcaption></figure>

Si un intervalle descendant de quinte est joué alors l'automate répète une section de notes jouée précédemment par le pianiste. L'écho est juste accéléré.

<figure><img src="image_48.png" /><figcaption>**Figure 15.** Opération d'accélération d'un écho.</figcaption></figure>

Si un intervalle de sixte mineure est joué alors l'automate répète une section de notes jouée précédemment par le pianiste. L'écho est accéléré et transposé symétriquement par rapport au do central.

<figure><img src="image_49.png" /><figcaption>**Figure 16.** Opération d'accélération et de symétrie d'un écho.</figcaption></figure>

## 6. CONCLUSION

L'objectif de notre projet de thèse est de réaliser une panoplie de captation du geste et de dispositifs de production de sons électroniques pour la musique vivante. L'étude et l'appropriation de l'augmentation instrumentale proposée par Jean-Claude Risset dans l'élaboration de ses duos pour un pianiste rentrent dans ce cadre. Suivant le même principe présenté dans cet article, nous avons programmé un arpégiateur en JavaScript dans Max/MSP. Nous avons développé aussi un certain nombre de synthétiseurs sous FAUST<fnref n="9" />. L'un des objectifs du langage de programmation FAUST est de pérenniser les traitements du signal et de synthèses sonores temps réel face à la volatilité des technologies et de les rendre ubiquitaires, exportables sur tous types de plates-formes, allant des extensions de différents formats à des applications pour téléphone portable.

Depuis l'introduction de la norme HTML5 et de la balise <audio>, il n'est plus nécessaire d'
user d'extensions tiers pour gérer le son dans un navigateur
web. De plus, la Web Audio API fournit aux
développeurs des outils pour générer et transformer le

son. En 2012, FAUST ajoute une brique à son projet pour traduire un code source DSP FAUST en fichier JavaScript. Nos développements d'augmentation instrumentale en JavaScript peuvent stimuler nos synthétiseurs FAUST dans Max/MSP, mais aussi dans un navigateur web<fnref n="10" />. Ces possibilités technologiques concourent à pérenniser notre travail. Nous pouvons le rendre accessible au plus grand nombre, sans qu'il soit restreint à l'usage d'un logiciel ou d'un système d'exploitation et cela pour des projets artistiques ou pédagogiques.

Nos prochains efforts se focaliseront sur la captation du geste afin d'irriguer de données nos différents modules d'augmentation et de synthèse. Nous validerons enfin nos différents développements par un travail artistique.

## 7. RÉFÉRENCES

[1] Drummond, J. "Understanding interactive systems", Organised Sound 14/2, Cambridge University Press, 2009.

[2] Engramelle, M.-D.-J. *Tonotechnie, ou l'art de noter les cylindres*, P. M. Delaguette, Paris, 1775.

[3] Koetsier, T. "On the prehistory of programmable machines: musical automata, looms, calculators", Mechanism and Machine Theory 36, 2001.

[4] Paradiso, J. A., O'Modhrain, S. "Current Trends in Electronic Music Interfaces. Guest Editors' Introduction", Journal of New Music Research 32/4, 2003.

[5] Patteson, T. W. *Instruments for New Music, Sound, Technology, and Modernism*, University of California Press, Oakland, 2016.

[6] Pottier, L. "Les musiques mixtes temps réel : pour une interprétation du son électronique en concert", colloque Soixante ans de musiques mixtes, Paris, 2012.

[7] Risset, J.-C. "Composer le son : expériences avec l'ordinateur, 1964-1989", Contrechamps n°11 – Musiques Électroniques, l'Age d'Homme, 1990.

[8] Risset, J.-C, Duyne, S. V. "Real-Time Performance Interaction with a Computer-Controlled Acoustic Piano", Computer Music Journal 20/1, 1996.

[9] Roads, C., Mathews, M. "Interview with Max Mathews", Computer Music Journal 4/4, 1980.

<footnote n="9">⁹ La librairie FAUST fournit plusieurs traitements et synthétiseurs opérationnels : http://faust.grame.fr/library.html.</footnote>

<footnote n="10">¹⁰ Nous avons réalisé une transposition de cette installation pour fonctionner dans un navigateur web pour la communication de Pottier, L. « Jean-Claude Risset : autour de la synthèse sonore, de ses œuvres, de la façon de les (re)présenter graphiquement, interactivement, sur le WEB », Rencontres internationales du Collegium Musicæ, Jean-Claude Risset : interdisciplinarités, Paris, 2018.</footnote>
# OUTILS INFORMATIQUES ET ANALYSE MUSICALE : REPRÉSENTER LE ROUTING DE JUPITER

Maxence Larrieu

LISAA

Université Paris-Est Marne-la-Vallée

maxence@larri.eu

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

orcid.org/0000-0002-1834-3007

## RÉSUMÉ

Cet article traite du routing de la pièce *Jupiter* (1987), pour flûte et électronique en temps-réel, composée par Philippe Manoury avec l'assistance de Miller Puckette. Le routing de cette pièce, l'interconnexion entre les modules audio, pose un problème particulier pour l'analyste qui souhaite s'appuyer sur le « document électronique de la pièce », le *patch*. Le problème tient dans le fait qu'il n'est pas possible de savoir quels sont les modules actifs et leur embranchement à un passage donné. Dans le cadre de notre thèse nous avons été confrontés à ce problème et nous avons développé une solution *ad hoc*, laquelle est l'objet du présent article. Nous avons développé des programmes informatiques qui simulent le fonctionnement du patch, et cela exclusivement à partir des *qlist* – les fichiers alphanumériques qui intègrent les données de synthèse. De cette simulation nous avons obtenu des représentations qui rendent compte de l'état du routing sur toute la durée de la pièce. Après avoir présenté la pièce et ces programmes informatiques, nous expliquons comment nous avons utilisé ces résultats dans le cadre de notre analyse musicale.

## 1. INTRODUCTION

*Jupiter*, pour flûte et électronique en temps-réel, est une pièce pionnière du répertoire d'informatique musicale. Elle ouvre en effet le célèbre cycle *Sonus Ex Machina*, avec lequel Philippe Manoury a développé les premières réflexions d'une « musique en temps-réel » [7]<fnref n="1" />. Composée dans les années 1985 avec l'aide de Miller Puckette, elle est créée en 1987 par Pierre-André Valade dans l'espace de projection de l'Ircam, lors d'un concert qui célèbre les 10 ans de l'institut<fnref n="2" />.

Dans notre doctorat portant sur l'analyse des musiques d'informatique [4], nous avons travaillé conséquemment sur cette pièce. Celle-ci a notamment été choisie pour ses possibilités d'interconnexion entre

modules, ce que nous désignons avec le terme *routing*, emprunté à l'ingénierie audio. En effet la composition de *Jupiter* se fait avec la possibilité de configurer un réseau d'une dizaine de modules tout au long de la pièce. Cette possibilité engendre néanmoins un contre-coup important : même avec le patch « sous les yeux », il n'est pas possible pour l'analyste de définir précisément quels sont les modules actifs à un passage donné. Ce problème n'est pas nouveau pour la communauté d'informatique musicale puisqu'il a été pointé en 2013 par Alain Bonardi sur une autre pièce du compositeur, *En Écho* (2003), dans le cadre d'un travail de reconstruction (cf. [1] et [2]).

Afin de mener à bien notre analyse nous avons dû trouver une solution à ce problème de routing. L'idée a été de simuler le fonctionnement du patch à l'aide uniquement des fichiers *qlist* et, durant cette simulation, d'en extraire les informations qui nous sont nécessaires. Nous avons conçu des programmes informatiques *ad hoc* qui scannent les 12 fichiers *qlist* de l'archive et qui simulent, à l'aide d'une forte compréhension du patch<fnref n="3" />, le fonctionnement du routing. De cette simulation nous avons ensuite extrait des chaînes de routing, des interconnections entre modules, avec lesquelles il nous a été possible de répondre à la question : quels sont les modules qui produisent ce qui est perçu ? De là, nous avons pu réaliser notre analyse de *Jupiter* en croisant l'écoute et les connaissances acquises sur la production.

Dans cet article nous présentons le routing de *Jupiter* et le problème qui se pose à l'analyste, puis nous décrivons les trois programmes informatiques réalisés qui permettent de faire face à ce problème. Enfin nous présentons l'usage que nous avons fait des résultats dans le cadre de notre analyse musicale.

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

<footnote n="1">¹ Pour une introduction sur *Jupiter* voir [4], [6] et [8].</footnote>

<footnote n="2">² Pour ses 40 ans en 2017, l'Ircam présente et diffuse les pièces de ce concert sur son site web (https://www.ircam.fr/article/detail/sons-dessous-dessous-28-retour-sur-le-10e-anniversaire/, 18 janvier 2018)</footnote>

<footnote n="3">³ Cette compréhension a abouti par exemple à une table qui décrit toutes les variables du patch (242). cf. datapipes.okfnlabs.org/csv/html/?url=https://raw.githubusercontent.com/Podatus/Jupiter/master/jupiterVars.csv, (visité le 30 mars 2018).</footnote>
## 2. MODULES ET ROUTING DE JUPITER

### 2.1. Le patch, les modules

Pour analyser Jupiter nous avons utilisé un patch Pure Data<fnref n="4" />, diffusé dans un article ambitieux qui a fait date, New Public-Domain Realizations of Standard Pieces for Instruments and Live Electronics de Miller Puckette [9]. Dans ce patch nous pouvons différencier plusieurs modules audio, dont les noms sont, pour la plupart, familiers. Il y a d'abord des modules de synthèse : Sampler, Additive, Chapo, Paf<fnref n="5" />; puis des modules de traitements : Harmonizer, Frequency Shifter, Reverb, Noise et un Spatialisateur. La table suivante donne un aperçu de ces modules avec différentes données que nous utilisons par la suite.

<table><caption>Table 1. Données sur les modules du routing<fnref n="6" /></caption><thead><tr><th>Module</th><th>Type</th><th>Group</th><th>Nb signaux</th><th>Abbréviation</th></tr></thead><tbody><tr><td>Flûte</td><td>synth</td><td></td><td>1</td><td>d</td></tr><tr><td>Sampler</td><td>synth</td><td></td><td>4</td><td>t</td></tr><tr><td>Additive</td><td>synth</td><td>osc</td><td>4</td><td>o</td></tr><tr><td>Chapo</td><td>synth</td><td>osc</td><td>4</td><td>o</td></tr><tr><td>Paf</td><td>synth</td><td>osc</td><td>1</td><td>o</td></tr><tr><td>Harmonizer</td><td>treat</td><td></td><td>1</td><td>h</td></tr><tr><td>FreqShift</td><td>treat</td><td></td><td>2</td><td>f</td></tr><tr><td>Reverb</td><td>treat</td><td></td><td>2</td><td>r</td></tr><tr><td>Noise</td><td>treat</td><td></td><td>1</td><td>n</td></tr><tr><td>Spat</td><td></td><td></td><td>4</td><td>4</td></tr></tbody></table>

### 2.2. Le routing

Jupiter est une pièce singulière notamment pour le routing : il est flexible et la composition se fait en partie par sa définition dans le temps de la pièce. Cette possibilité de configurer à loisir le routing est permise d'abord par le « suiveur de partition ». Centrale à Jupiter – et plus largement à la musique en temps-réel – il permet d'articuler des événements électroniques avec l'interprétation qu'effectue le flûtiste. De plus, la flexibilité du routing s'explique par son implémentation : les 5 modules de synthèse sont tous reliés aux 4 modules de traitement, et parallèlement ces derniers sont tous reliés entre eux ; enfin, tous ces modules sont reliés au Spat. La configuration du

routing passe alors par un ensemble de variables qui permet de doser la quantité de signal (en valeur MIDI) dans chacune de ces connexions. Cette flexibilité a un prix : une configuration totale du routing nécessite en théorie<fnref n="7" /> 41 variables<fnref n="8" />.

## 3. LE PROBLÈME DU ROUTING

### 3.1. Aperçu

Nous pouvons présenter le problème en imaginant la situation suivante : soit un musicologue qui souhaite analyser Jupiter à l'aide (notamment) du patch. Dans le travail à réaliser nous pouvons différencier deux étapes : une où il va effectuer des lectures du patch – de sorte à identifier et comprendre les 9 modules implémentés ; et une autre où il va se confronter à la manifestation sonore de la pièce. Le problème survient dans la seconde étape : confronté au sonore de la pièce il va avoir besoin de savoir quels sont les modules qui produisent le signal perçu ; quels sont ceux qui expliquent ce qui est écouté ? Or, comme nous allons le voir, il n'est pas possible de répondre directement à cette question.

### 3.2. Utilisation du routing

Le compositeur a utilisé le routing dans le temps de la pièce, « au fil des événements », et non de configuration type en configuration type. Par exemple le Frequency Shifter (FS par la suite) est souvent utilisé pour venir perturber un « tapis » maintenu par le Paf et/ou la Reverb (e.g. le début de la section IV) : sur un passage le compositeur va placer le FS sur la production de ces derniers modules puis quelques événements après cette connexion va être supprimée, puis, encore quelques événements après, il va par exemple activer l'envoi de la Reverb vers l'Harmonizer, puis de ce dernier vers le FS, etc. Avec cet exemple nous souhaitons montrer que le routing possède une écriture persistante : une connexion reste dans son état tant qu'elle n'est pas modifiée (ré-écrite). Ainsi, l'analyste qui souhaite savoir la configuration du routing à tel événement devra monter la vingtaine de variables<fnref n="9" /> du routing. Ceci reste envisageable dans les premières minutes, mais devient impossible sur la demi-heure de la pièce.

Le problème auquel est confronté l'analyste vient d'une part des 21 variables utilisées pour configurer le routing, et de l'autre de leur utilisation intensive ; la flexibilité du routing appelle en contre-partie une difficulté de représentation.

<footnote n="4">⁴ Ce patch est couramment nommé « la version de Miller Puckette » par la communauté. Soulignons que Miller Puckette comme Philippe Manoury nous ont assuré que ce patch a été utilisé en concert.</footnote>

<footnote n="5">⁵ Nous utilisons des majuscules afin de différencier ces modules des méthodes de synthèse qu'ils sous-tendent.</footnote>

<footnote n="6">⁶ Le lecteur spécialiste aura remarqué que nous n'intégrons pas le module de traitement nommé phasor. En effet celui-ci n'est pas relié au routing : il est appliqué tout au long de la pièce sur la flûte et diffusé dans la stéréophonie.</footnote>

<footnote n="7">⁷ En théorie, car tous ce que contient le patch n'est pas nécessairement utilisé.</footnote>

<footnote n="8">⁸ 5 modules de synthèse reliés aux 4 modules de traitements ; 4 modules de traitement reliés entre eux ; et les 9 modules reliés au Spat.</footnote>

<footnote n="9">⁹ Toutes les connexions entre modules ne sont pas utilisées par le compositeur, nous avons ainsi trouvé dans les *qlist* l'usage de 21 variables dédiées au routing.</footnote>
# 4. UNE SOLUTION

Puisque le patch et les *qlist* sont seules responsables de l'électronique, de ce qui est perçu, il doit être possible de rendre compte de ces embranchements entre modules. Une telle prise de conscience est par exemple présente chez Alain Bonardi, dans le cadre d'un travail de reconstruction de la pièce *En Echo* (1993). Le patch est exécuté, écouté, et les connexions entre modules sont représentées dans le patch, graphiquement, à l'aide d'un « diagramme fonctionnel » [2]. Cette solution convient, mais elle ne nous permet pas de connaître, hors temps, des connexions présentes à un événement donné ; elle n'amène pas un support qui rende compte du routing en dehors du temps de la pièce.

Nous présentons ci-après une solution voisine où le patch à été simulé uniquement à partir des *qlist* – *i.e.* sans computation audio – et d'un ensemble de règles. Cette solution est faite de trois étapes : la première relève les pré-états des modules ; la deuxième les connexions prescrites ; la dernière utilise les précédents résultats et en déduit les connexions effectives entre modules.

Précisons avant de commencer que nous avons travaillé avec une précision à l'échelle des événements, sans tenir compte des quelques occurrences de connexions qui se font avec des temps de lissage.

Aussi, les programmes que nous avons conçus se basent sur un typage des modules, ceux de synthèse et ceux de traitement. Afin de ne pas alourdir la suite de notre écrit nous utilisons les expressions « les *synth* » et « les *treat* » pour désigner réciproquement les modules de synthèse, qui produisent des signaux, et ceux de traitement, qui les modifient.

Enfin, pour plus de clarté, nous avons été amenés à différencier le routing *interne* de celui *externe* ; le premier fait référence aux connexions entre modules, le second aux connexions vers le système de diffusion – une stéréophonie classique au-devant de la scène et une quadriphonie qui entoure le public.

## 4.1. Les Pré-états des modules

Cette première étape permet de savoir si les modules sont actifs ou non. Mais il ne peut s'agir ici que d'un état premier (pré-état), puisque avant de pouvoir connaître l'état (final) il est nécessaire de connaître l'acheminement du signal à la diffusion<fnref n="10" />.

Pour les *synth*, cette étape consiste à savoir s'ils produisent du signal ; pour les *treat*, s'ils sont aptes à en produire.

Pour les *synth* et à l'exception du Paf, nous avons procédé à une détection manuelle à l'aide des *qlist*, de la partition et de l'écoute ; pour les *treat*, à une détection automatique avec un programme informatique.

### 4.1.1. Détection manuelle

Pour le Sampler nous pouvons aisément différencier deux utilisations. Une à partir d'écriture dans les *qlist* avec la variable *addsamp* et une autre à partir de lecture de fichiers (e.g. *ost6-start*) où les données sont lues et affectées aux modules de synthèse – à l'instar d'un lecteur de données MIDI. Pour la première utilisation nous avons lu les *qlist* et appliqué la règle suivante : si une des voies est active durant l'événement alors le module est actif, et inversement. Le Sampler est en effet particulier puisque le signal produit est nécessairement limité dans le temps. Pour la seconde utilisation nous avons eu recours à la partition et à l'écoute. La détection est aisée puisque cet usage du Sampler est très marqué, il correspond en effet aux *ostinatos*, éléments très saillants de la pièce.

Pour les modules Additive et Chapo nous avons aussi lu les *qlist*. Simplement, à la différence du Sampler ils sont inactifs quand toutes leurs voies possèdent une amplitude nulle.

### 4.1.2. Détection automatique

Pour le Paf et les *treat* nous avons réalisé un programme – *a_preStateOfModspde*<fnref n="11" /> – qui déduit automatiquement les états à partir des *qlist*. Cette déduction est faite à chaque événement, qu'il y ait ou non de nouvelles écritures. La figure ci-dessous illustre le fonctionnement du programme : il reçoit en entrée tous les fichiers *qlist*, puis, après application de règles, il construit une table – nommée *preStatesOfModstsv* – qui représente sous forme booléenne les états des modules, événement par événement.

<figure><img src="image_52.png" /><figcaption>**Figure 1.** Illustration du programme de détection des pré-états des modules.</figcaption></figure>

Tous les modules à traiter possèdent une structure de données commune (e.g. nom, type, état, variables). En utilisant la Programmation Orientée Objet (POO par suite) nous avons alors créé une classe, nommée Module, qui définit cette structure de données. Une seconde classe attachée à la précédente est aussi nécessaire. Nommée DictList elle a pour fonction de relier une variable à une liste de nombres ; par exemple la chaîne de caractère *fpos* à toutes les occurrences de cette variable.

<footnote n="10">¹⁰ Comme l'a montré Alain Bonardi [2] il est en effet possible que des embranchements n'aboutissent pas – comme une conséquence de la difficulté de représentation du routing.</footnote>

<footnote n="11">¹¹Nos programmes sont conçus avec le langage Processing. Ils sont disponibles avec les résultats à l'adresse suivante : github.com/Podatus/Jupiter (visité le 30 mars 2018).</footnote>
<figure><img src="image_53.png" /><figcaption>**Figure 2.** Schéma UML<fnref n="12" /> de la structuration du premier programme.</figcaption></figure>

Le programme s'initie en créant une instance de la classe Module par modules à analyser. Le *n* du précédent schéma précise que le nombre de variables attachés aux modules *n* est pas fixe, comme en témoigne la table ci-dessous.

<table><caption>**Table 2.** Données des modules utilisées pour les instances du premier programme.</caption><thead><tr><th>Module</th><th>Type</th><th>Variables</th></tr></thead><tbody><tr><td>paf</td><td>synth</td><td>amp1, amp2, amp3, amp4, amp5, amp6, amp7, amp8</td></tr><tr><td>reverb</td><td>treat</td><td>rout</td></tr><tr><td>harm</td><td>treat</td><td>hamp1, hamp2, ham3, ham4</td></tr><tr><td>freqshift</td><td>treat</td><td>fpos, fneg</td></tr></tbody></table>

Les états des modules sont alors déduits à partir de trois règles, que nous pouvons ainsi présenter : si durant un événement la variable de sortie d'un Module

* a eu au moins une occurrence supérieure à 0, alors le module est actif ;

* n'a eu que des occurrences égales à 0, alors le module est inactif ;

* n'a eu aucune occurrence, alors le module reste dans l'état précédent.

Dans cette simulation les difficultés rencontrées viennent des variables de substitutions, *i.e.* des variables de plus haut niveau qui affectent un ensemble de variables, par exemple *amptutti6* affecte l'amplitude des 6 premières voies du Paf, *amp1*, *amp2* ... *amp6*.

## 4.2. Extraire le routing

La deuxième étape extrait les données de routing, interne comme externe. Si la première étape permettait de répondre à la question « quels modules produisent (au niveau du patch) du signal ? », la deuxième permet de répondre à la suivante « quelles sont les connexions présentes entre modules ?».

Cette étape est réalisée automatiquement à l'aide d'un programme – *b_modsConnections.pde* – assez similaire au précédent. C'est en effet la même structuration en POO qui est utilisée, mais cette fois-ci avec une instanciation pour tous les modules, la flûte comprise, et bien évidemment avec toutes les variables de routing comme le présente la table ci-dessous.

<table><caption>**Table 3.** Données des modules utilisées pour créer les instances du deuxième programme.</caption><thead><tr><th>Module</th><th>Type</th><th>Variables</th></tr></thead><tbody><tr><td>flute</td><td>synth</td><td>dtor, dtoh, dtof, dton, dto4</td></tr><tr><td>sampler</td><td>treat</td><td>ttor, ttoh, ttof, tton, tto4, tto2</td></tr><tr><td>osc</td><td>treat</td><td>otor, otoh, otof, oton, oto4, oto2, noise1, noise2, noise3, noise4, noise5</td></tr><tr><td>reverb</td><td>treat</td><td>rtoh, rtof, rton, rto4, rto2</td></tr><tr><td>harm</td><td>treat</td><td>htor, htof,oton, hto4, hto2</td></tr><tr><td>freqshift</td><td>treat</td><td>ftor, ftoh, fton, fto4, fto2</td></tr><tr><td>noise</td><td>treat</td><td>ntor, ntoh, ntof, nto4, nto2</td></tr></tbody></table>

Pour chaque événement le programme extrait les données du routing puis déduit les connexions entre modules. Le routing est ensuite représenté à l'aide d'une table – *modsConnections.tsv* –, avec une ligne pour chaque événement et une colonne pour chacun des modules. Enfin, le routing est indiqué à partir des envois. Par exemple, si la Reverb est connectée à l'Harmonizer à tel événement le programme inscrit *rtoh* dans la colonne Reverb à l'événement correspondant.

Dans cette étape les difficultés rencontrées viennent du groupement de module « osc » – pour oscillateur – qui regroupe Paf, Additive et Chapo. Une difficulté supplémentaire se présente à cause de la connexion du Paf vers le Noise, qui se fait à la fois à l'échelle du groupement de module – la variable *oton* – et à l'échelle des canaux du Paf – les variables *noise1*, *noise2* ... *noise5*. Enfin, il y a une variable de substitution à considérer qui affecte et le Sampler et le groupement de module « osc », *ston* affecte *fton* et *oton*.

## 4.3. Déduire les états des modules et le routing

La dernière étape permet de répondre à la question initiale, « quels sont les modules actifs à tel événement et quels sont leurs connexions ? », soit de rendre compte de la production. La réponse est obtenue intégralement à l'aide d'un programme – *c_stateAndRouting.pde*. Il croise les résultats des précédentes étapes et déduit, à l'aide de règles, les connexions et les états des modules. C'est une étape conséquente puisqu'il nous a été nécessaire de concevoir un algorithme qui traverse le réseau du routing.

<footnote n="12">¹² Unified Modelling Language</footnote>
### 4.3.1. Fonctionnement

Le programme utilise de nouveau la POO avec une classe Module, qui définit la structure de données et les méthodes communes aux instances.

<figure><img src="image_54.png" /><figcaption>Figure 3. La classe Module du troisième programme.</figcaption></figure>

Les attributs *inputs* et *outputs* permettent de stocker les différentes connexions des modules ; les attributs *booléens* *dac* et *state* de stocker la connexion à la diffusion et l'état du module.

Le programme crée une instance pour les 8 modules (Flûte, Sampler, Osc, Reverb, Harm, FreqShift, Noise et Spat) puis croise, événement par événement, les résultats des précédentes étapes. Les modules actifs sont d'abord sélectionnés – la table *preSatesOfModstsv* – puis les connexions entre modules sont affectées aux attributs *inputs* et *outputs* des modules correspondants. Par exemple, la lecture de *rtoh* dans la table *modsConnections.tsv* à un événement donné ajoute le terme *harm* à l'attribut *outputs* de l'instance *reverb* et le terme *reverb* à l'attribut *input* de l'instance *harm*. De cette façon, il est possible d'avoir une représentation exhaustive du routing interne. Par exemple, dans la conception du programme il nous a été nécessaire d'avoir un retour sur l'état du routing ; nous avons opté pour la représentation suivante :

```
flute out(reverb)
noise in(osc,reverb) out(spat)
spat in(noise,osc,reverb)
osc out(noise,spat)
reverb in(flute) out(noise,spat)
```

### 4.3.2. Règles

Une fois les connexions établies deux règles ont été appliquées afin d'obtenir un routing cohérent :

* Si un module n'a aucune sortie, ni *dac* ni routing interne, alors il est inactif ;

* Si un module, hormis la Reverb<fnref n="13" />, est un *treat* et n'a aucune entrée, alors il est inactif<fnref n="14" />.

Ensuite, les états finaux des modules sont déduits – la méthode *deduceState* – et les connexions mortes sont retirées – la méthode *removeDeadConnections*.

### 4.3.3. Chaînes de routing et algorithme

La précédente représentation du routing est nettement trop lourde pour rendre compte du routing sur la demi-heure de la pièce. Afin de l'alléger nous avons pensé le routing à partir de chaînes, d'interconnexions entre modules. Une chaîne commence nécessairement par un *synth* et finit soit dans un *dac* soit dans le Spat. La transformation de la précédente représentation du routing à une nouvelle, avec ce principe de chaînes, a été réalisée par un algorithme. Ce dernier doit, tout en mémorisant leurs noms et leurs successions, traverser toutes les instances actives interconnectées jusqu'à arriver à une connexion au *dac* ou au Spat. La représentation finale que nous avons choisie est la suivante, avec en haut le numéro de la section et l'événement, puis les chaînes de routing, et enfin les modules reliés au *dac*.

```
10.12
flute>spat
sampler>reverb
sampler>harm>noise>spat
sampler>harm>reverb
dac : harm,reverb,sampler
```

Cette représentation est elle-même utilisée dans le programme pour comparer le routing d'un événement à l'autre afin de savoir s'il y a eu un changement ou non. Le fichier final – *routingChains.txt*<fnref n="15" /> – de notre solution contient donc cette représentation pour chaque changement de routing. Avec un saut de ligne avant les événements, il contient environ 1700 lignes.

### 4.3.4. Difficultés

La principale difficulté a été de concevoir l'algorithme. Celui-ci n'est pas évident puisqu'il doit être récursif : le chemin à parcourir d'instance en instance n'est pas connu à l'avance mais se dessine au fur et à mesure de la traversée des instances. Dans le précédent exemple une fois la chaîne *sampler>reverb* trouvée, il faut remonter au Sampler pour investir l'autre connexion qui va à l'Harmonizer, et ainsi de suite. Lorsque l'algorithme se trouve à une instance donnée, toutes les connexions sont donc à placer dans un tampon, et de même pour le chemin qui a mené à cette instance.

<footnote n="13">¹³ La Reverb possède en effet un mode infini avec lequel du signal est produit même s'il n'y a rien en entrée.</footnote>

<footnote n="14">¹⁴ La méthode *treatWithoutInputs*</footnote>

<footnote n="15">¹⁵ cf.
github.com/Podatus/Jupiter/blob/master/routing/c_statesAndRouting/routingChains.txt, (visité le 30 mars 2018).</footnote>
# 5. UTILISATION DES RÉSULTATS POUR L'ANALYSE MUSICALE

Nous présentons ci-après l'usage que nous avons fait des précédents résultats lors de l'analyse musicale. Ces résultats nous ont servi à deux reprises. D'abord lors des premiers contacts avec le sonore de la pièce, de sorte à avoir un aperçu global, et ensuite, plus substantiellement, de sorte à expliquer ce que nous percevons.

## 5.1. Les états des modules

La première utilisation concerne exclusivement les états des Modules. Dans différentes analyses écrites de *Jupiter* nous avons constaté une pratique récurrente, celle d'éclairer les 30 minutes de la pièce avec l'enchaînement des modules actifs. Une représentation classique en deux dimensions est ainsi souvent donnée : la durée est présente sur l'horizontale avec les 13 sections, et les modules sont placés verticalement. L'éclairage consiste à donner les modules qui sont actifs pour les différentes sections (e.g. Andrew May [8]). Évidemment, avec notre précédent fichier il est possible d'aller plus loin : nous avons d'une part une discrétisation temporelle plus fine, celle des événements, et d'autre part nous avons une indication des modules actifs qui est basée sur une simulation du patch, qui dépasse donc l'écoute.

Nous avons donc prolongé la précédente représentation avec nos résultats. Le temps est présent en abscisse selon la succession des événements et non des minutes, et nous avons ajouté les segmentations de la partition : dessous le numéro des événements sont présents les lettres des sous-sections puis, dessous, le numéro des sections. Représenter plus de 500 événements demande cependant une taille conséquente ; nous plaçons donc ci-après un extrait de cette représentation, et nous la diffusons en pleine largeur sur le Web<fnref n="16" />.

<figure><img src="image_55.png" /><figcaption>**Figure 4.** Extrait de la représentation des états des Modules.</figcaption></figure>

Avec la version intégrale nous remarquons de prime abord que les modules de traitement sont amplement utilisés. De plus, accompagnée d'une écoute cette représentation permet d'effectuer deux groupements de sections : la 6 et la 12, avec l'utilisation du Chapo, et un autre groupe plus vaste 1, 2, 4, 7 et 13 où l'on trouve les même modules.

Il faut cependant rester très prudent avec une telle représentation<fnref n="17" />. Il est en effet primordial de la relier à l'écoute et/ou à la partition, sans quoi il serait possible d'emprunter des chemins de compréhension déviants.

## 5.2. Le routing

Enfin notre analyse s'est fortement appuyée sur les chaînes de routing précédemment identifiées. Au fil de la lecture de ce fichier et de la pratique de notre analyse nous nous sommes aperçus que la précision obtenue était trop grande comparée à l'usage du routing qui a été fait dans la composition. C'est typique par exemple pour le Noise qui n'est pas un module « support de la composition », mais davantage un module de mixage : il vient brouiller un signal qui est déjà diffusé. Cela se retrouve aussi dans les nombreuses connexions des modules au *dac*. On s'aperçoit qu'il y a un *usage* récurrent des *treat* qui consiste moins à créer une nouvelle sonorité qu'a venir enrichir, brouiller, une déjà diffusée. Cet usage-là doit être dépassé par l'analyse musicale. Une analyse qui se baserait sur les connexions entre le Noise et la Reverb (en dehors du mode infini) et le FS resterait en effet lacunaire. Dans le même temps, et c'est fondamental, cet usage-là participe à l'empreinte sonore de *Jupiter*. Les ignorer serait une erreur, comme en atteste leur forte présence sur la durée de la pièce. Finalement, cet usage des *treat* s'éclaire bien avec une métaphore que le compositeur nous a transmise : « les modules de synthèse de l'époque sont comme des autoroutes, droites et monotones ; les modules de traitements permettent de faire face à cette uniformité de sorte que l'on ne s'ennuie pas dans l'écoute »<fnref n="18" />.

Le fichier texte avec les chaînes de routing nous a ainsi été utile avec une lecture experte, de sorte à dépasser cette trop grande quantité, en relevant dans les changements ceux qui sont importants de ceux qui ne le sont pas. Avec ce fichier, nous avons pu éclairer des sonorités très surprenantes, comme l'événement 14 de la section 12, qui s'expliquent, en plus de la configuration des modules, par le routing, comme le présente la figure ci-dessous.

<footnote n="16">16 DOI: 10.6084/m9.fishshare.5817459.v1</footnote>

<footnote n="17">17 Pour l'anecdote, on se souviendra que la première réaction de Philippe Manoury quand nous lui avions présenté cette représentation graphique fût « qu'est-ce que vous faite de cela ? »</footnote>

<footnote n="18">18 Métaphore retranscrite lors d'un entretien avec le compositeur à l'Ircam en novembre 2016.</footnote>
<figure><img src="image_56.png" /><figcaption>**Figure 5.** Exemple d'une configuration du routing. Événement 14, section 12.</figcaption></figure>

## 6. DISCUSSION

À l'issue de ce travail se pose la question de l'adaptabilité de notre démarche à d'autres pièces. Précisons d'abord que les programmes développés ne sont pour l'heure fonctionnels que sur la pièce *Jupiter*, ils ont en effet été construits avec toutes les idiosyncrasies du patch<fnref n="19" />, de sorte justement à les dépasser. Les pièces qui demanderaient le moins de remaniement des programmes sont bien évidemment celles du cycle *Sonus Ex Machina*, car composée par les mêmes personnes. Ensuite, en dehors d'une application rapide sur d'autres pièces, il nous semble qu'il y a dans ce travail une approche originale que nous pouvons éclairer ci-après mais qui mériterait d'être approfondie ultérieurement. Notre approche nous paraît singulière dans la mesure où nous utilisons les *qlist* dans le but d'éclairer la pièce dans sa durée, c'est-à-dire au-delà de la microstructure. Tous les *qlist* ont en effet été utilisés de sorte à éclairer – dans cet article – les embranchements des modules. Partir du postulat que toutes les informations relatives à l'électronique, sur la durée de la pièce, sont présentes dans le patch et les *qlist* est peut-être évident, en revanche, ce qui l'est moins, c'est d'aller vers cette densité et de l'exploiter dans une perspective d'analyse musicale : les *qlist* se situent à un bas niveau d'abstraction, 8000 lignes : utiliser cette quantité nécessite un pas conceptuel. Nous avons franchi celui-ci en deux temps : d'abord une forte compréhension de tous les modules et du fonctionnement du patch, ensuite une représentation de ces modules (POO dans notre cas) et du fonctionnement du patch dans des programmes informatiques. Notre approche nous paraît donc singulière puisqu'elle va exploiter, à l'aide de représentations informatiques sur mesures, les données bas niveau présentes dans les *qlist*, dans le but d'en extraire des informations de plus haut niveau, éclairantes pour l'analyse musicale sur la durée de la pièce.

## 7. CONCLUSION

Dans cet article nous avons traité du problème du routing qui survient dans l'analyse musicale de *Jupiter*.

Le problème tient dans le fait qu'il n'est pas possible pour l'analyste de connaître précisément les modules responsables de la production électronique à un passage donné. Nous avons expliqué la solution que nous avons réalisée dans le cadre de notre thèse [4]. Nous sommes arrivés à une représentation exhaustive et hors temps du routing, sans laquelle nous n'aurions pu développer notre analyse musicale. Les documents obtenus, confrontés à l'écoute, nous ont permis de relever une spécificité de la pièce : son empreinte sonore ne s'explique pas par un ou deux modules de traitement, mais par un réseau non linéaire de modules – dans le sens où des modules intermédiaires diffusent directement dans le *dac* et/ou le *Spat* –, qui évolue au fil des événements.

Enfin, la méthode que nous avons réalisée pour affronter le problème du routing nous paraît aussi originale pour l'analyse musicale. En effet avec une forte compréhension du patch nous avons pu simuler son fonctionnement, et cela en dehors de la computation audio. C'est une pratique originale puisque d'une part elle aboutit à un document qui est en dehors du temps de l'actualisation de la musique – ce qui autorise une saisie *in extenso* –, et d'autre part puisque nous avons utilisé l'outil informatique pour construire des représentations à partir d'un bas niveau d'abstraction (les *qlist*). Cette pratique pourrait aussi s'avérer féconde pour l'analyse d'autres pièces d'informatique musicale.

## 8. REMERCIEMENT

Je remercie Philippe Manoury pour les échanges que nous avons eus.

## 9. RÉFÉRENCES

[1] Bonardi, A. "Analyser et représenter la production du son dans les œuvres mixtes. Exemple du patch Max/MSP de *En Echo* de Philippe Manoury" Présentation orale dans le cadre du séminaire *Analyse par segmentation des musiques électroacoustiques*, Saint-Étienne, 2013.

[2] Bonardi, A. "Analyser l'orchestre électronique interactif dans les œuvres de Manoury", *Analyser la musique mixte*, Delatour, Sampzon, 2017. hal-01575296

[3] Clarke, M. "Jonathan Harvey's *Mortuos Plango, Vivo Voco*, Analytical methods of electroacoustic music*, dir. Mary Symony. Routledge, London, 2006.

[4] Di Scipio, A. "An Analysis of Jean-Claude Risset's Contours", Journal of New Music Research, vol.29, n°1, p 1-21, 2000.

[5] Dufeu, F. "Comment développer des outils généraux pour l'étude des instruments de musique

<footnote n="19">¹⁹ Pensons par exemple aux variables de substitution (e.g. *ston* qui affecte *tton* et *oton*) ou plus fortement aux connexions du Paf vers le Noïse qui se font à l'échelle des voies (*noise1*, *noise2* ...). Tout cela doit se retrouver dans les programmes</footnote>
numériques ? Un prototype en JavaScript pour
l'investigation de programmes Max", Revue
Francophone d'Informatique Musicale, n°3, 2013.
revues.mshparisnord.org/rfim/index.php?id=255
(visité le 30 mars 2018)

[6] Goody, J. *La raison graphique. La domestication de la pensée sauvage*, Édition de Minuit, Paris, 1979.

[7] Larrieu, M. "Analyse des musiques d'informatique : vers une intégration de l'artefact. Proposition théorique et application sur Jupiter (1987) de Philippe Manoury". Thèse, Université Paris-Est Marne-la-Vallée, 2018. tel-01757277.

[8] Lemouton, S. "Vingt ans de pratique de la Réalisation en Informatique Musicale". Mémoire de Master 2, Université Paris-Est Marne-la-Vallée, 2012.

[9] Manoury, P., Battier, M., Bonardi, A., Lemouton, S. *Les musiques électroniques de Philippe Manoury*, Ircam, Paris, 2003.

[10] Manoury, P. "Considérations (toujours actuelles) sur l'état de la musique en temps réel", l'Étincelle, n°3, Ircam, Paris, 2007.

[11] May, A. "Philippe Manoury's Jupiter", *Analytical methods of electroacoustic music*, dir. Mary Symony. Routledge, London, 2006.

[12] Puckette, M. "New Public-Domain Realizations of Standard Pieces for Instruments and Live Electronics", International Computer Music Conference, Havana, Cuba, 2001.

[13] Puckette, M. *The theory and technique of electronic music*, World Scientific Publishing Co Inc, Singapore, 2006.

[14] Risset, J.-C. "Problèmes d'analyse : quelques clés pour mes premières pièces numériques, *Little Boy et Mutations*", *Analyse en musique électroacoustique, Acte de l'académie Internationale de Musique Électroacoustique de Bourges*. Mnémosyme, Bourges, 2001.

[15] Will, U. "La baguette magique de l'ethnomusicologue: repenser la notation et l'analyse de la musique", *Cahiers de musique traditionnelles*, n° 12, 1999. journals.openedition.org/ethnomusicologie/671 (visité le 30 mars 2018).

[16] Zattra, L. "Génétiques de la computer music", *Genèses musicales*, dir. Nicolas Donin, A. Grésillon, J.-L. Lebrave. Presse universitaire de Paris-Sorbonne, Paris, 2015.
INFÉRENCE DE SEGMENTATION STRUCTURELLE
PAR COMPRESSION VIA DES RELATIONS MULTI-ÉCHELLES
DANS LES SÉQUENCES D'ACCORDS

Corentin Guichaoua
Université de Rennes 1
IRISA – Équipe-projet PANAMA

Frédéric Bimbot
CNRS
IRISA – Équipe-projet PANAMA

RÉSUMÉ

Une des approches possibles pour l'analyse automatique de structure musicale est d'aborder la question comme un problème de compression : une représentation efficace de la structure musicale d'un morceau serait ainsi une représentation qui permet de décrire précisément ce morceau en peu de termes.

La méthode présentée dans cet article exploite les ré-
seaux de relations à courte et moyenne échelle entre les
evénements musicaux afin d'obtenir des représentations
compactes de segments de séquences musicales symbo-
liques. Ces représentations compactes sont ensuite utili-
sées pour exprimer le morceau analysé comme une suite
de segments de faible complexité, d'après le postulat qu'une
segmentation découpant un morceau en un nombre limité
d'éléments simples est susceptible de s'aligner avec la seg-
mentation annotée manuellement.

Cette méthode est testée sur des séquences d'accords
annotées manuellement, correspondant à la base de don-
nées RWC-Pop, et est comparée à une autre méthode à
base de compression. Les segments obtenus correspondent
avec une F-mesure de l'ordre de 70% avec les segmenta-
tions de référence.

1. INTRODUCTION

La structure musicale est un concept crucial de l'ana-
lyse de la musique, comme en témoigne son utilisation
pour des applications variées, telles que la séparation chant-
voix [1], la transcription de parole [2] ou la composition
automatique [3]. En dépit de son importance, sa définition
reste encore très ambiguë [4].

Devant les multiples définitions possible de la structure
musicale et la nécessité de trouver un cadre permettant de
les regrouper, cet article aborde la question sous l'angle de
la théorie de l'information. Plus précisément, nous nous
intéressons aux notions de complexité de Kolmogorov et
d'entropie de Shannon pour rendre compte de la redon-
dance présente dans les segments musicaux et les com-
pressor. Selon cette optique, la structure musicale réside
dans les régularités utilisables pour exécuter cette com-
pression [5].

L'utilisation de données symboliques, comme une par-
tition ou une séquence d'accords au lieu d'un enregis-

trement, en interposant une couche d'abstraction, permet
de faire abstraction des régularités propres au signal au-
dio pour se concentrer sur les régularités musicales. On
se limitera ici à l'étude de séquences de triades (échan-
tillonnées à 1 accord par temps), mais les principes dé-
crits peuvent également être appliqués à d'autres types de
descriptions symboliques.

Les séquences musicales présentent des régularités plus poussées que ce qui apparaît en examinant simplement leur nature séquentielle. En particulier, on peut observer des dépendances entre les éléments qui sont situés à des positions métriques homologues. Afin de modéliser ces dépendances multi-échelles, nous introduisons un modèle s'appuyant sur des graphes hypercubiques, proche de celui présenté dans [6], développé de façon concomitante dans l'équipe PANAMA, mais axé sur la modélisation de différents type d'organisations au lieu d'une description détaillée. Nous proposons une méthode exploitant ces dépendances afin d'obtenir des représentations compressées de segments musicaux, que nous utilisons ensuite pour trouver une séquence de segments peu complexes.

Dans la section 2, nous introduisons les concepts de *patrons tensoriels* et *d'historique tensoriel*, qui formalisent différents réseaux de relations et les dépendances qui en résultent entre les éléments d'un segment. Chaque patron différent correspond ainsi à une hypothèse sur l'organisation du segment qui, selon son adéquation avec le segment, permet ou non de l'exprimer de façon compacte.

La section 3 décrit comment les réseaux de relations définis par les patrons tensoriels peuvent être utilisés pour tenter d'anticiper successivement chacun des éléments de la séquence.

En section 4, nous appliquons cette méthode de com-
pression des segments pour la segmentation structurelle,
en recherchant les séquences de segments résultant en une
complexité minimale.

Nous étudions en section 5 l'application de cette mé-
thode de segmentation sur des annotations de séquences
d'accords de musique pop, avant de conclure en section 6.

2. PATRONS TENSORIELS

Avant d'utiliser les relations multi-échelle entre les dif-
férents éléments d'une séquence musicale, il convient de

<figure><img src="image_57.png" /></figure>
définir l'architecture de ces relations. Pour cela, nous introduisons les *patrons tensoriels*, qui décrivent l'organisation des éléments à plusieurs échelles simultanément. Plutôt qu'un modèle universel de l'organisation d'un segment musical, il s'agit d'un catalogue (non-exhaustif) d'organisations simples, parmi lesquelles celle permettant au mieux de décrire la séquence sera sélectionnée (cf. sections suivantes).

L'organisation non-linéaire la plus simple est une organisation de 4 éléments en carré, où chaque élément dépend de ses voisins apparaissant antérieurement dans la séquence, comme illustré en figure 1a. Ces relations sont considérées comme *homologues* lorsque les arêtes associées sont parallèles. Cette organisation peut être généralisée à des séquences de $2^d$ éléments, organisés selon un hypercube de dimension *d* (par exemple en dimension 4 sur la figure 1b).

<figure><img src="image_58.png" /><figcaption>**Figure 1:** Exemples de patrons hypercubiques. Les styles de traits indiquent les classes de relations homologues.</figcaption></figure>

Cette extension, à elle seule, reste toutefois très insuffisante pour modéliser la variété des organisations rencontrées en pratique, même dans des genres considérés comme pauvres à cet égard comme la pop. En effet, on observe souvent des sections musicales dont la longueur en temps musicaux n'est pas une puissance de 2. Afin de pouvoir gérer une plus grande variété de séquences, nous étendons l'inventaire des patrons hypercubiques à l'aide de deux opérations de modification permettant d'augmenter ou de diminuer le nombre d'éléments admis par le patron. La première opération, dite d'insertion, agit sur une hyper-face<fnref n="1" /> de l'hypercube définissant le patron, en la dupliquant et en connectant ses éléments avec les éléments correspondants de la nouvelle copie. La seconde opération, dite d'omission, agit également sur une hyper-face, la retirant du patron. Un exemple de chaque cas est présenté en figure 2.

Pour éviter une multiplication excessive du nombre de patrons, on se limite à la manipulation d'hyper-faces dont un des sommets est le dernier élément de l'hypercube, et à une seule insertion et/ou une omission. Cette restriction permet d'identifier les modifications de façon unique par

<figure><img src="image_59.png" /><figcaption>**Figure 2:** Exemples de patrons avec omission, avec insertion et avec une combinaison des deux.</figcaption></figure>

la position du sommet opposé de l'hyper-face. Ainsi, en accord avec le principe d'utiliser des organisations simples, 3 nombres (au plus) suffisent à identifier les patrons : la dimension de l'hypercube, et les positions des modifications éventuelles.

Ces extensions supplémentaires, bien qu'elles ne permettent toujours pas de modéliser toutes les longueurs de séquences, offre un éventail bien plus diversifié d'organisations, qui suffisent à couvrir la majorité de cas rencontrés. La figure 3 montre des exemples de séquences avec des signatures impaires modélisées à l'aide de patrons déformés.

À partir de ces réseaux, on définit pour chaque élément son *historique tensoriel*, le sous-ensemble des relations et des éléments dont dépend cet élément, directement ou transitivement. Deux exemples d'historiques tensoriels sont présentés en figure 4. Ces historiques tensoriels sont pour chaque élément l'information qui est utilisée afin d'établir une anticipation, comme décrit dans la section suivante.

<footnote n="1">1. Une hyper-face est un hypercube inclus dans un hypercube de dimension supérieur</footnote>
<figure><img src="image_60.png" /><figcaption>(a) Séquence de structure ternaire modélisée à l'aide d'une omission
(b) Séquence de structure pentadique modélisée à l'aide d'une insertion</figcaption></figure>

<figure><img src="image_61.png" /><figcaption>**Figure 4:** En vert épais l'historique tensoriel de $x_3$, en pointillé l'historique de $x_{14}$. Les éléments d'origine des arcs font partie des historiques tensoriels</figcaption></figure>

### 3. ANTICIPATION SELON UN PATRON TENSORIEL

Une façon de mesurer l'adéquation d'un patron tensoriel à un segment est d'observer dans quelle mesure l'utilisation de ce patron permet d'anticiper chacun des éléments de la séquence correspondante en fonction des éléments passés. D'après les principes énoncés en introduction, un patron approprié permettra ainsi d'anticiper plus d'éléments qu'un patron inadapté. Cette mesure présente l'avantage de pouvoir être effectuée dans un cadre non-supervisé, sans entrée autre que la séquence à modéliser.

Ce procédé peut être exprimé selon un point de vue compressif : pour chaque élément de la séquence, 3 cas peuvent se présenter, qui déterminent la quantité d'information requise pour encoder l'élément :

1. L'élément observé correspond à l'élément anticipé : aucune information supplémentaire n'est nécessaire pour décrire cet élément.

2. L'élément observé ne correspond pas à l'élément anticipé : il est nécessaire de spécifier l'élément observé ou en quoi il diffère de l'élément anticipé (du même ordre dans le cas d'éléments simples).

3. Un élément anticipé n'a pas pu être produit (par exemple le premier élément de la séquence pour lequel aucune information n'est disponible) : il est

nécessaire de spécifier l'élément observé.

En effectuant la simplification que le bit utilisé pour distinguer le premier du deuxième cas est négligeable devant la spécification d'un élément, la longueur de la description de la séquence selon le patron tensoriel est proportionnelle au nombre d'éléments n'ayant pas été correctement anticipés.

Avant de décrire le processus par lequel le patron tensoriel est utilisé pour produire des anticipations d'éléments, nous décrivons le modèle que nous utilisons pour la représentation des relations entre les accords <fnref n="2" />.

#### 3.1. Relations entre les éléments

Le modèle de représentation des accords et de leurs relations que nous avons choisi d'utiliser consiste en deux simplifications principales.

La première simplification est une restriction du vocabulaire des accords aux 24 triades majeures et mineures <fnref n="3" />. Cette simplification est assez courante dans les approches symboliques et ne sera pas détaillée.

La deuxième simplification porte sur les relations entre les accords deux à deux : ces relations sont modélisées par les rotations envoyant un accord sur un autre sur le cercle des tierces présenté en figure 5. En plus de ses propriétés musicales, par son équivalence avec $Z/24Z$, cet espace de représentation des relations a les propriétés clés suivantes (que nous dirons quasi-affines <fnref n="4" />) :

- la composition est définie et respecte la relation de Chasles pour toutes les paires de relations;

- la composition est commutative et associative;

- chaque accord a une unique image par une transformation donnée.

#### 3.2. Cas du carré

Le cas le plus simple est celui de l'organisation en carré, qui correspond au modèle Système & Contraste introduit dans [7], illustré avec des formes en figure 6. L'arrangement des 4 éléments $x_0, x_1, x_2$ et $x_3$ de la séquence correspond à l'hypothèse d'une relation d'analogie entre ces éléments, où $x_3$ est à $x_2$ ce que $x_1$ est à $x_0$, soit, en utilisant une notation vectorielle $\overrightarrow{x_0x_1} = \overrightarrow{x_2x_3}$.

En pratique, cette analogie n'est pas toujours vérifiée, on note alors $\overrightarrow{\gamma_3}$ la différence entre l'élément observé $x_3$ et l'élément anticipé $\widehat{x_3}$ qui aurait vérifié l'analogie, que l'on nomme *contraste*.

Cette formulation permet de mettre en avant le rôle joué par chacun des éléments dans l'organisation de la sé-

<footnote n="2">2. À l'exception de la section expérimentale, cette description du modèle des accords est la seule partie de cet article qui est spécifique aux accords. À condition de respecter les propriétés clés qui y sont énoncées, tout modèle de représentation des propriétés de la séquence est compatible avec les principes développés.</footnote>

<footnote n="3">3. Cet espace et les relations peuvent être étendus avec un non-accord pour les temps où la notion d'accord ne s'applique pas. Cette solution est un artifice qui permet de traiter par extension les passages où il n'existe pas d'harmonie identifiable.</footnote>

<footnote n="4">4. Ces propriétés s'apparentent à celles d'un espace affine, à ceci près que la multiplication par un scalaire n'est pas toujours inversible.</footnote>
<figure><img src="image_62.png" /><figcaption>**Figure 5:** Le cercle des tierces utilisé pour représenter l'espace des accords. Chaque accord partage deux notes avec ses voisins et l'on passe d'un accord à son voisin horaire en décalant d'une tierce (majeure si l'accord de départ est majeur, mineure sinon) vers les aigüs.</figcaption></figure>

<figure><img src="image_63.png" /><figcaption>**Figure 6:** Visualisation des relations entre les éléments du modèle Système & Contraste sur un système d'éléments géométriques. Les relations portent sur le remplissage, la forme et le contour des éléments. L'élément $\overline{x_3}$ est un élément virtuel qui ne fait pas partie de la séquence observée.</figcaption></figure>

quence (analysée à l'aide du patron carré), et sa contribu-
tion à la quantité d'information nécessaire à l'encodage
de la séquence. Le premier élément ($x_0$), appelé *primer*,
permet d'ancrer la séquence et sert de point de référence.
Il est présenté sans information préalable et doit toujours
être encodé. Le deuxième et le troisième élément ($x_1$ et
$x_2$), appelés sous-primers, établissent les transformations
(ou relations) qui définissent le reste de la séquence. Un
cas simple se dégage pour chacun de ces éléments, ce-
lui où l'élément est identique au primer, pour lequel une
quantité d'information faible est requise. Enfin, le dernier
élément $x_3$, en correspondant ou non avec l'élément an-
ticipé (on dit qu'il est *concordant* ou *discordant* respecti-
vement), détermine si la séquence est *contrastive* ou non.
Dans le cas où il est concordant, très peu d'information
est requise pour l'encoder.

On peut noter que dans le cas d'objets présentant plu-
sieurs propriétés comme dans l'exemple des formes, l'en-
codage des transformations peut être plus économique en
information, même si aucune des transformations n'est tri-
viale. Ce n'est toutefois pas le cas avec notre représentat-
tion simplifiée des accords, ce qui limite l'intérêt du cas
carré pris en isolation.

3.3. Cas régulier en dimension 3

Une première observation dans le cas des patrons hy-
percubiques de dimension supérieure est que tous les élé-
ments à l'exception du dernier peuvent être ramenés à des
cas de dimension inférieure : par exemple, dans un patron
cubique (3-cubique), l'élément $x_6$ est le dernier élément
du carré formé par les éléments $x_0, x_2, x_4$ et $x_6$. Ainsi, en
procédant en dimension croissante, seule la détermination
de l'élément anticipé pour la dernière position doit être
adaptée.

Considérons d'abord le cas du cube : comme dans le cas carré, on peut considérer l'analogie définie par $\overline{x_0x_2} = \overline{x_1x_3} = \overline{x_4x_6} = \overline{x_5x_7}$, illustrée en figure 7. Cependant, contrairement au cas carré, plus d'une de ces relations a été observée dans l'historique tensoriel de $x_7$, et une contradiction peut être apparue si $x_3$ ou $x_6$ est discordant. S'ils sont concordants, on peut définir un élément anticipé pour $x_7$ d'après le parallélogramme formé par les éléments $x_0, x_2, x_5$ et $x_7$, de la même façon que pour une organisation carrée.

<figure><img src="image_64.png" /><figcaption>**Figure 7:** Mise en évidence d'une analogie sur un patron cubique, à partir de la séquence d'accords du pont (1'38 à 1'52) du morceau n°10 de RWC (Getting Over). La séquence est ici prise à 1 accord par mesure et peut être entièrement déduite des 3 seuls accords en gras, qui en constituent ainsi une représentation compressée.</figcaption></figure>

Par symétrie, on peut également considérer les analo-
gies utilisant les relations $\overline{x_0x_1}$ ou $\overline{x_0x_4}$. Ces analogies
supplémentaires sont contredites respectivement si $x_3$ ou
$x_5$ sont discordants et si $x_5$ ou $x_6$, et ne sont donc pas
equivalentes, contrairement au cas carré où les deux di-
rections étaient interchangeables.

Un autre type d'analogie que l'on peut effectuer est en
considérant les faces parallèles formées d'une part par $x_0$,
$x_1$, $x_2$ et $x_3$, et d'autre part par $x_4$, $x_5$, $x_6$ et $x_7$. Cette ana-
logie est toutefois équivalente à l'analogie selon la rela-
tion $\overline{x_0x_4}$. Ici encore, on retrouve par symétrie deux autres
analogies entre faces, équivalentes aux analogies selon les
arêtes.

On peut remarquer que si plus d'un élément parmi $x_3$, $x_5$ et $x_6$ est contrastif, aucune des analogies n'est vérifiée sur les éléments observés : dans ce cas, on ne peut pas construire d'élément anticipé de cette façon, et il est nécessaire d'encoder $x_7$ non trivalement. Une conséquence
de la nature quasi-affine de l'espace des relations est que les analogies non contredites aboutissent au même élément anticipé. On a alors un unique point de référence auquel comparer l'élément observé $x_7$ pour l'encoder trivialement s'il est concordant.

### 3.4. Cas en dimension supérieure

En dimension 4 et au delà, le même processus peut être appliqué en considérant les analogies définies par les hypercubes contenant le primer. Comme dans le cas du cube, ces constructions sont complémentaires 2 à 2 : pour la définition de l'élément projeté pour $x_i$, l'analogie définie par l'hypercube entre $x_0$ et $x_h$ est équivalente à l'analogie définie par l'hypercube orthogonal entre $x_0$ et $x_{i-h}$. Ces deux analogies, si elles ne comportent pas de contradiction, peuvent être réduites au parallélogramme formé par $x_0, x_h, x_{i-h}$ et $x_i$. Un exemple de paire d'hypercubes complémentaires et du parallélogramme qui leur est associé est présenté en figure 8.

<figure><img src="image_65.png" /><figcaption>**Figure 8:** Paire de carrés complémentaires et l'organisation en parallélogramme correspondante</figcaption></figure>

L'inventaire des conditions pour lesquelles l'analogie est contredite par les éléments observés peut sembler laborieux de prime abord, mais s'exprime relativement aisément en fonction de ces hypercubes complémentaires : l'analogie pour $x_i$ basée sur un hypercube entre $x_0$ et $x_h$ est contredite s'il existe au moins un élément discordant dans l'hypercube entre $x_0$ et $x_i$ qui n'est ni dans l'hypercube entre $x_0$ et $x_h$, ni dans son complémentaire (entre $x_0$ et $x_{i-h}$).

Là encore, les propriétés quasi-affines de l'espace de relations assurent que les analogies non-contredites aboutissent au même élément anticipé.

### 3.5. Influence des déformations

Jusqu'ici, nous avons décrit comment sont construit les éléments anticipés dans le cas des patrons basés sur des hypercubes non déformés. Afin d'utiliser tout l'éventail des patrons définis en section 2, nous étendons ces constructions aux patrons avec omission et/ou insertion.

L'extension aux patrons avec omission est presque triوانale : l'omission ne fait que retirer des éléments à anti-

ciper, et grâce à la contrainte sur les positions des hyperfaces supprimées, les éléments supprimés n'apparaissent que dans les historiques tensoriels d'autres éléments supprimés. La re-numérotation des éléments rompt toutefois la compatibilité des formules s'appuyant sur les index, mais cette difficulté est aisément contournée en appliquant ces calculs sur les index non modifiés.

L'extension aux patrons avec insertion présente également cette difficulté mineure, à laquelle s'ajoute le besoin de définition d'un élément projeté pour les éléments insérés. Une solution consiste à restreindre l'historique tensoriel des éléments insérés à l'hypercube formé par l'hyperface dupliquée et sa copie : ce cas se ramène alors localement à un cas hypercubique régulier.

## 4. APPLICATION À LA SEGMENTATION STRUCTURELLE

Dans la section précédente, nous avons décrit un processus permettant d'évaluer la complexité d'une séquence donnée selon un patron tensoriel donné. Cette complexité n'est pas nécessairement représentative de la complexité de la séquence, toutefois en répétant cette opération pour tous les patrons tensoriels compatibles et en sélectionnant celui permettant la plus forte compression, une approximation plus juste peut être obtenue, à condition que l'éventail des patrons soit suffisamment riche. Le nombre de patrons compatibles pour une longueur donnée ne dépassant pas l'ordre de quelques centaines (dans le pire cas) pour des longueurs correspondant à l'échelle des segments musicaux, une telle exploration exhaustive reste tractable. Afin de prendre en compte la régularité plus grande des patrons hypercubiques, une pénalité, réglée expérimentalement, est appliquée pour chaque type d'altération appliquée au patron.

Afin de passer de cette mesure de complexité d'un segment individuel à l'inférence d'une segmentation d'un morceau entier, nous calculons, pour chaque paire de position de départ et de fin formant un segment ne dépassant pas une taille plafond de 64 éléments<fnref n="5" /> la complexité de ce segment. Il en résulte un graphe dirigé représentant l'ensemble des segmentations possibles du morceau, chaque arc étant portant la complexité du segment correspondant. Ce graphe peut être parcouru avec un algorithme de recherche du plus court chemin afin d'obtenir une segmentation minimisant la somme des complexités de chaque segment.

## 5. EXPÉRIENCES

Nous évaluons cette méthode sur les chansons de musique pop de la base de données RWC-Pop, constituées de 100 chansons composées et interprétées dans le style des musiques du hit-parade aux États-Unis dans les années 80

<footnote n="5">5. Ce seuil est fixé a priori au double de l'échelle ciblée pour la segmentation, 32 éléments dans notre cas. Le choix de cette échelle cible implique que les patrons utilisés sont généralement de dimension 5, avec occasionnellement des patrons de dimension 3,4 ou 6.</footnote>
où $|X|$ est la taille de la séquence, $l_r$ est la taille cible des segments et $r_+$ et $r_-$ sont les coefficients de régularisation.

<table><caption>**Table 2:** F-mesure (sans tolérance, en pourcentage) selon les paramètres de régularisation. On utilise $p_+ = p_- = 2.25$, la paire de valeurs offrant les meilleurs résultats sans régularisation.</caption><thead><tr><th>r_</th><th>r_+</th><th>0</th><th>0.0001</th><th>0.025</th><th>0.05</th><th>0.075</th><th>0.1</th><th>0.125</th><th>0.15</th></tr></thead><tbody><tr><td>0</td><td>61.1</td><td>61.4</td><td>61.4</td><td>60.8</td><td>60.9</td><td>60.5</td><td>60.2</td><td>60.4</td><td>60.4</td></tr><tr><td>0.0001</td><td>62.8</td><td>62.8</td><td>62.5</td><td>61.9</td><td>61.7</td><td>61.2</td><td>61.3</td><td>61.1</td><td>61.1</td></tr><tr><td>0.025</td><td>62.2</td><td>62.2</td><td>62.4</td><td>62.4</td><td>62.6</td><td>62.7</td><td>61.7</td><td>61.7</td><td>61.7</td></tr><tr><td>0.05</td><td>65.5</td><td>65.5</td><td>65.3</td><td>65.5</td><td>66.2</td><td>66.1</td><td>65.9</td><td>64.8</td><td>64.8</td></tr><tr><td>0.075</td><td>66.2</td><td>66.2</td><td>66.7</td><td>67.0</td><td>66.9</td><td>66.7</td><td>66.6</td><td>66.3</td><td>66.3</td></tr><tr><td>0.1</td><td>67.8</td><td>67.9</td><td>67.0</td><td>66.9</td><td>66.7</td><td>66.7</td><td>66.8</td><td>66.5</td><td>66.5</td></tr><tr><td>0.125</td><td>67.8</td><td>67.9</td><td>67.1</td><td>66.5</td><td>66.4</td><td>66.1</td><td>66.4</td><td>66.3</td><td>66.3</td></tr><tr><td>0.15</td><td><b>68.0</b></td><td>67.8</td><td>67.5</td><td>67.5</td><td>66.5</td><td>66.1</td><td>65.9</td><td>66.0</td><td>65.9</td></tr><tr><td>0.175</td><td>67.4</td><td>67.4</td><td>67.6</td><td>67.2</td><td>66.8</td><td>66.5</td><td>65.9</td><td>65.7</td><td>65.7</td></tr><tr><td>0.2</td><td>65.9</td><td>65.9</td><td>66.1</td><td>66.5</td><td>66.6</td><td>65.8</td><td>65.3</td><td>65.0</td><td>65.0</td></tr></tbody></table>

La table 2 montre l'évolution de la F-mesure selon le réglage de ces paramètres. L'optimum est atteint pour une valeur de $r_+$ nulle, ce qui est cohérent avec le but de réduire la sur-segmentation. À l'exception d'un effet de seuil marqué entre les valeurs 0.025 et 0.05 pour $r_-$, l'influence de ces paramètres est encore modérée et lisse. À nouveau, des expériences préliminaires de sous-échantillonnage confirment les optimums obtenus.

## 5.5. Choix de la base et variabilité

Les expériences ci-dessus étaient rapportées pour la F-mesure exacte, sur la base MANUAL, pour laquelle les données d'entrée sont de bonne qualité. Les bases AUTO et CORRECTED permettent de tester le comportement de l'algorithme lorsque les données sont à différents niveaux de dégradation (sans aller toutefois jusqu'à des annotations complètement automatiques). La figure 10 montre une vue transversale des performances par morceau de l'algorithme, selon la base et la version de la F-mesure utilisée.

On observe que les différences entre la base MANUAL et la base CORRECTED sont assez modérées, mais qu'en revanche la base AUTO est nettement moins bien segmentée, en particulier dans le cas de la F-mesure exacte. Une autre propriété remarquable est que l'ajout d'une fenêtre de tolérance a une influence très faible sur les 2 meilleures bases, ce qui contraste avec ce que l'on peut généralement observer dans les campagnes MIREX sur la segmentation audio. Enfin, cette figure met en évidence la diversité de la qualité de la segmentation selon les morceaux : si presque la moitié de la base est correctement segmentée à 80% ou plus, 20% des morceaux ont moins de la moitié des frontières de segment correctement inférées.

## 5.6. Comparaison avec une autre approche

La table 3 rapporte les F-mesures obtenues pour les méthodes présentées dans cet article, comparées à une méthode de référence opérant sur le même type de données et utilisant des méthodes de compression de texte pour l'inférence de la structure [9, ch. 3-4]. Les méthodes à enco-

<figure><img src="image_66.png" /><figcaption>(a) F-mesure sans tolérance</figcaption></figure>

<figure><img src="image_67.png" /><figcaption>(b) F-mesure avec tolérance</figcaption></figure>

**Figure 10:** F-mesure sur chacun des 100 morceaux de RWC-Pop selon l'annotation utilisée pour l'encodage tensoriel par analogie avec régularisation. Pour plus de lisibilité, les morceaux ont été ré-ordonnés par F-mesure croissante selon chaque annotation

dage tensoriel obtiennent des scores de segmentation nettement plus élevés.

## 5.7. Détail d'une segmentation

Le morceau numéro 24 de la base MANUAL est un morceau pour lequel la F-mesure entre la segmentation inférée est légèrement au dessus de la moyenne (F=0.71). La figure 11 montre la segmentation de référence et la segmentation obtenue par l'algorithme d'inférence.

On peut voir que les segmentations diffèrent à certains endroits :

- La frontière entre le deuxième segment et le troisième segment (0'19 à 0'41 dans l'audio) est placée 16 temps (un demi-segment) plus tard dans la segmentation inférée. En effet, sur la séquence d'accords, la première moitié du 3e segment forme un système non contrastif avec le deuxième segment (il s'agit d'une répétition à l'identique). L'indice principal qui permet de distinguer une frontière à cet endroit est le retour du chant dans l'instrumentation, mais cet indice n'est pas présent dans la séquence d'accords. On retrouve également la même
tonique par exemple) semble être une piste ardue mais fructueuse.

— La réduction d'un morceau à une séquence d'accords est une simplification extrêmement brutale. Avec les modèles de relation appropriés, la méthode peut être appliquée à des mélodies, des rythmes, des activités d'instruments, etc. Individuellement, chacune de ces dimensions musicales est une simplification aussi brutale de la musique, mais leur utilisation jointe serait certainement bénéfique.

On peut enfin noter que l'information contenue dans la représentation utilisée par cette méthode dépasse la simple segmentation et inclut à la fois des estimations de la structure interne des segments et desquels de leurs éléments apportent des informations nouvelles.

## 7. REFERENCES

[1] Antoine Liutkus, Zafar Rafii, Roland Badeau, Bryan Pardo, and Gaël Richard. Adaptive Filtering for Music/Voice Separation Exploiting the Repeating Musical Structure. In *IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP)*, pages 53–56. IEEE, 2012.

[2] Matt McVicar and Daniel P.W. Ellis. Leveraging Repetition for Improved Automatic Lyric Transcription in Popular Music. In *IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP)*, pages 3117–3121, 2014.

[3] François Pachet, Alexandre Papadopoulos, and Pierre Roy. Sampling Variations of Sequences for Structured Music Generation. In *Proceedings of the 18th International Society for Music Information Retrieval Conference (ISMIR)*, Suzhou, China, 2017.

[4] Jordan B.L. Smith. *Explaining Listener Differences in the Perception of Musical Structure*. PhD thesis, Queen Mary, University of London, UK, 2014.

[5] David Meredith. Analysis By Compression : Automatic Generation of Compact Geometric Encodings of Musical Objects. In *The Music Encoding Conference*, 2013.

[6] Corentin Louboutin and Frédéric Bimbot. Modeling the Multiscale Structure of Chord Sequences using Polytopic Graphs. In *Proceedings of the 18th International Society for Music Information Retrieval Conference (ISMIR)*, Suzhou, China, oct 2017.

[7] Frédéric Bimbot, Emmanuel Deruty, Gabriel Sargent, and Emmanuel Vincent. Semiotic Structure Labeling of Music Pieces : Concepts, Methods and Annotation Conventions. In *Proceedings of the 13th International Society for Music Information Retrieval Conference (ISMIR)*, Porto, Portugal, 2012.

[8] Masataka Goto, Hiroki Hashiguchi, Takuichi Nishimura, and Ryuichi Oka. RWC Music Database : Popular, Classical and Jazz Music Databases. In *Proceedings of the 3rd International Society for Music Information Retrieval Conference (ISMIR)*, volume 2, pages 287–288, 2002.

[9] Corentin Guichaoua. *Compression models and complexity criteria for the description and the inference of music structure*. Theses, Université Rennes 1, 2017.

[10] Taemin Cho. Manually Annotated Chord Data Set of US Pop Songs and Popular Music Collection of RWC Music Database, 2011.

[11] Masataka Goto. AIST Annotation for RWC Music Database. In *Proceedings of the 7th International Society for Music Information Retrieval Conference (ISMIR)*, pages 359–360, 2006.

[12] Frédéric Bimbot, Gabriel Sargent, Emmanuel Deruty, Corentin Guichaoua, and Emmanuel Vincent. Semiotic Description of Music Structure : An Introduction to the Quaero/Metiss Structural Annotations. In *Audio Engineering Society Conference : 53rd International Conference : Semantic Audio*, London, United Kingdom, jan 2014.

[13] Cheng-i Wang and J. Mysore Gautham. Re-Visiting the Music Segmentation Problem With Crowdsourcing. In *Proceedings of the 18th International Society for Music Information Retrieval Conference (ISMIR)*, pages 738–744, Suzhou, China, 2017.
# EXPLORATION DE DÉPENDANCES STRUCTURELLES MÉLODIQUES PAR RÉSEAUX DE NEURONES RÉCURRENTS

Nathan Libermann

Univ Rennes 1

nathan.libermann@inria.fr

Frédéric Bimbot

IRISA/CNRS

frederic.bimbot@irisa.fr

Emmanuel Vincent

INRIA

emmanuel.vincent@inria.fr

## RÉSUMÉ

Dans le cadre de la génération automatique de mélodie structurée, nous explorons la question des dépendances entre les notes d'une mélodie en utilisant des outils d'apprentissage profond. Plus précisément, nous utilisons le modèle d'apprentissage séquentiel GRU, que nous définons dans différents scénarios d'apprentissage afin de mieux comprendre les architectures optimales dans ce contexte. Nous souhaitons par ce moyen explorer différentes hypothèses relatives à la non-invariance temporelle des dépendances entre les notes au sein d'un segment structurel (motif, phrase, section). Nous définissons trois types d'architectures récurrentes correspondant à différentes schémas d'exploitation de l'historique musical dont nous étudions les capacités d'encodage et de généralisation. Ces expériences sont conduites sur la base de données Lakh MIDI Dataset et plus particulièrement sur un sous-ensemble de 8308 segments mélodiques monophoniques composés de 16 mesures. Les résultats indiquent une distribution non-uniforme des capacités de modélisation et de prédiction des réseaux récurrents testés, suggérant l'utilité d'un modèle non-ergodique pour la génération de segments mélodiques.

## 1. INTRODUCTION

La génération automatique de mélodie est une problématique régulièrement abordée en informatique musicale mais qui reste incomplètement résolue. Récemment revenues au premier plan, les méthodes par réseaux de neurones apparaissent potentiellement capables de modéliser des mécanismes de génération de mélodie par apprentissage à partir d'exemples.

Chen et al [4] furent parmis les premiers auteurs à publier sur ce sujet. L'un des principaux problèmes qu'ils relèvent est le manque de structure globale dans les mélo-dies générées. D'autres auteurs comme Franklin [7], Eck et Schmidhuber [6] ont alors cherché à résoudre ce problème en utilisant des réseaux récurrent LSTM [9] sur un corpus de musique blues ou jazz. Ces travaux ont permis d'améliorer la qualité perçue de la musique générée mais les résultats continuent à présenter une insuffisance de structure. Boulanger-Lewandowski et al. [3] ont tenté de combiner le modèle LSTM avec des modèles géné-ratifs, notamment le RBM [4]. Dans Huang et Wu [10], les auteurs s'intéressent à la représentation des notes dans

un espace vectoriel (embedding). Jaques et al [11] proposent de restreindre un modèle LSTM préalablement à pris grâce à l'apprentissage par renforcement de règles de musicologie prédéfinies. L'équipe Magenta<fnref n="1" /> propose un modèle d'attention inspiré de Bahdanau et al [1]. A notre connaissance, il n'existe pas aujourd'hui de modèle capable d'apprendre à générer des mélodies présentant une structure pleinement satisfaisante à l'échelle de plusieurs mesures consécutives.

Le travail présenté dans cet article est une étude exploratoire qui s'inscrit dans ce cadre de la génération automatique de mélodie structurée, et qui fait appel à des outils d'apprentissage profond. Plus particulièrement nous considérons le modèle séquentiel GRU (Gated Recurrent Units) [5], que nous étudions dans différents scénarios d'apprentissage afin de mieux comprendre les potentialités de cette approche pour la modélisation de mélodies. Nous souhaitons notamment cerner l'importance d'une hypothèse de non-ergodicité (non-invariance dans le temps) de la structure musicale, en mettant en évidence les limites des architectures récurrentes à base de GRU et étudier les possibilités de les adapter à la génération de motifs mélodiques. On suppose en effet qu'il existe une planification dans la construction d'un segment mélodique qui ne se contente pas de se référer aux k précédents éléments pour construire le suivant. Au contraire, nous faisons l'hypothèse qu'un segment mélodique forme un tout et qu'au fil du segment les divers éléments se conditionnent de façon non-adjacente pour former le schéma mélodique global.

Ainsi, dans l'esprit des travaux récents sur les modèles tensoriels/polytopiques de segments musicaux [8] [12], nous émettons l'hypothèse que dans le cadre de mélodies simples constituées de motifs présentant des relations d'analogie, les dépendances structurelles dans la musique ne suivent pas un procédé purement séquentiel, mais plutôt des dépendances multi-échelles. Selon cette approche, un élément musical dépend de façon privilégiée des autres éléments qui se situent dans des positions métriques homologues dans le segment plutôt que dans le voisinage immédiat. Autrement dit, les positions métriques des notes jouent un rôle dans la construction structurelle de la musique et les architectures neuronales doivent en tenir compte.

<footnote n="1">1. https://magenta.tensorflow.org/2016/07/15/lookback-rnn-attention-rnn</footnote>
<figure><img src="image_68.png" /><figcaption>Figure 1. Gated Recurrent Units</figcaption></figure>

Nous définissons donc trois modèles récurrents à base de GRU. Un modèle à historique glissant, qui correspond à une façon "standard" de construire et d'entrainer un modèle récurrent. Un modèle à historique croissant, qui correspond à une façon "dynamique" d'apprendre un modèle récurrent. Et enfin, un modèle à historique parallèle, avec des poids distincts selon les positions à prédire.

La comparaison des différents schémas d'apprentissage proposé selon leur capacité d'encodage de l'information musicale et de leur performance de prédiction permet d'étudier la pertinence et les limites de l'hypothèse de non-ergodicité dans les séquences mélodiques.

# 2. PROTOCOLE EXPÉRIMENTAL

## 2.1. Cellule de mémoire GRU et couche de prédiction

Pour définir les architectures étudiées, nous utilisons comme unité de base le réseau de neurones récurrent GRU (Gated Recurrent Unit, voir Figure 1) qui fonctionne comme suit. A chaque instant $t$ la cellule GRU reçoit en entrée, sous forme de vecteurs, l'observation courante $x_t$ et une variable interne $h_{t-1}$ qui tient lieu de mémoire des observations précédentes. A partir de ces deux entrées, la cellule GRU produit une remise à jour de $h$, laquelle est ensuite utilisée dans une cellule GRU semblable, prenant $h_t$ et l'observation $x_{t+1}$ en entrée,... et ainsi de suite. Dans nos expériences, $x_t$ est un vecteur binaire de dimensions $n = 88$ correspondant à un ensemble discret de notes, chaque dimension représentant une note, ce vecteur n'a qu'un seul symbole 1 (one-hot).

La cellule GRU se décompose en 6 sous-ensembles de poids de propagation d'historique ($U_h, U_r, U_z, W_h, W_r, W_z$) qui se combinent avec les entrées $h_{t-1}$ et $x_t$ pour former $h_t$ selon les équations suivantes :

$$z_t = \sigma_g(W_z x_t + U_z h_{t-1} + b_z) \quad (1)$$

$$r_t = \sigma_g(W_r x_t + U_r h_{t-1} + b_r) \quad (2)$$

$$h_t = (1 - z_t) \circ h_{t-1} + z_t \circ \sigma_h(W_h x_t + U_h(r_t \circ h_{t-1}) + b_h) \quad (3)$$

<figure><img src="image_69.png" /><figcaption>Figure 2. Architecture à historique glissant</figcaption></figure>

où ◦ désigne le produit matriciel de Hadamard, $\sigma_g$ une fonction sigmoïde et $\sigma_g$ une tangente hyperbolique.

Nous avons aussi besoin pour définir nos architectures d'une couche de prédiction qui à partir d'une mémoire $h_t$ fournit une distribution de probabilités $\_x_{t+1}$ de la note suivante $x_{t+1}$. Pour ce faire, nous utilisons une couche entièrement connectée entre $h_t$ et $\_x_{t+1}$, constituée d'une matrice de poids de prédiction $W_p$ et d'un vecteur de biais $b_p$, ce qui fournit en sortie une distribution de probabilité à posteriori sur l'ensemble des notes :

$$\_x_{t+1} = W_p h_t + b_p \quad (4)$$

L'apprentissage est réalisé par rétropropagation du gradient à travers le temps [16].

## 2.2. Spécification des architectures

Dans ce travail nous considérons des segments mélodiques correspondant à des unités structurelles de type phrase ou section musicale. Dans cette optique, nous modélisons des séquences de $N = 64$ notes qui sont obtenues en échantillonnant des mélodies qui s'étendent sur 16 measures.

Trois architectures à base de GRUs sont étudiées :

- L'architecture à historique glissant correspond à une façon standard de construire un réseau récurrent. On choisit une fenêtre d'historique de taille fixe $k$. Pour prédire la note $\_x_{t+1}$, on alimente la couche de prédiction $W_p$ avec l'historique $h_t$, qui, dans ce cas, est initialisé aléatoirement puis propagé depuis $h_{t-k}$ jusqu'à $h_t$ (voir Figure 2). La fenêtre d'historique $[t-k, t]$ étant fixe, on ne peut calculer les prédictions $\_x_{t+1}$ qu'à partir de l'instant $k+1$. Les poids des couches de propagation d'historique sont partagés (c'est-à-dire indépendants de $t$) et il en est de même des poids des couches de prédiction. Ainsi, cette architecture repose sur une hypothèse d'invariance dans le temps des éléments musicaux.

- L'architecture à historique croissant correspond à une façon plus dynamique de construire un modèle récurrent. Ici on procède de la même façon que pour l'architecture du modèle à historique glissant, mais on considère une fenêtre d'historique qui couvre l'intégralité de l'intervalle $[1, t]$ et qui par conséquent croît au fur et à mesure que l'on progresse dans le temps (voir Figure 3). Comme dans
<figure><img src="image_70.png" /><figcaption>**Figure 3.** Architecture à historique croissant</figcaption></figure>

l'architecture précédente, les poids de la couche de propagation d'historique sont communs pour les différentes positions de notes à prédire et il en est de même pour les poids de la couche de prédiction. Mais dans cette variante, il devient possible de prédire les notes dans toutes les positions temporelles, à partir d'un historique qui va croissant. On note toutefois que cette architecture repose aussi sur une hypothèse d'invariance dans le temps du fait du partage des poids.

— Enfin, l'architecture à historique *parallèle* repose sur le même principe que l'architecture à historique croissant, à ceci près que les poids des couches de propagation et de prédiction sont indépendants pour chaque position à prédire $x_{t+1}$. On peut ainsi voir cette configuration comme $N-1$ réseaux à historique croissant, indépendants les uns des autres et correspondant à chaque position à prédire $x_{t+1}$. L'indépendance de ces réseaux en fonction de la position est censée permettre à cette architecture de prendre en compte la non-invariance dans le temps et de tenir compte, si nécessaire, de dépendances complexes.

## 2.3. Données

Pour ce travail d'exploration, nous utilisons les données du Lakh MIDI Dataset [14], qui contient 176581 fichiers MIDI multipistes sans appréciation de genres. Etant donné que nous nous intéressons uniquement aux pistes mélodiques monophoniques, nous en avons sélectionné environ 70000 qui possédaient cette propriété dans le corpus originel. De ce sous-ensemble, nous avons extrait 8308 blocs structurels de 16 mesures sous forme de fichier MIDI. Ne disposant pas de segmentation automatisée assez fiable, nous sélectionnons uniquement les 16 premières mesures de mélodies monophoniques de type 4/4.

Afin de permettre au modèle de pouvoir mieux extraire les relations relatives entre les notes, nous avons représenté ces mélodies en référence à la première note de la séquence (arbitrairement fixée à Do), de sorte à être indépendant de la tonalité initiale. Nous obtenons donc 8308 séquences mélodiques de 16 mesures.

Pour simplifier la représentation traitée, on considère dans un premier temps une discrétisation de l'information mélodique dans ces segments. Nous avons procédé à un découpage des mesures en 4 portions égales et relevé à chaque fois la note active sur ces positions. Si un silence

<table><caption>**Table 1.** Protocoles d'apprentissage et de test pour mesurer les capacités de compression et de généralisation des architectures</caption><thead><tr><th>Train</th><th>Test</th><th>Test</th></tr></thead><tbody><tr><td>A</td><td>A</td><td>B</td></tr><tr><td>B</td><td>B</td><td>A</td></tr></tbody></table>

apparaît sur l'un des temps considérés, nous prolongeons la valeur de la note précédente ce qui évite d'avoir à gérer des absences de notes.

Le résultat de ce processus de réduction conduit à des séquences "mélodiques" de 16 mesures correspondent toutes à des successions de 64 notes. Chaque note est représentée par un vecteur de dimension 88 (correspondant aux 88 notes d'un clavier de piano). Lorsqu'une note est active, la dimension associée à cette note dans le vecteur est mise à 1 et toutes les autres à 0.

## 2.4. Protocole

Le corpus composé de 8308 séquences est divisé en deux groupes A et B comprenant chacun 4154 séquences. Nous définissons quatre scénarios pour chaque architecture voir Table 1 :

— Apprentissage sur le groupe A, test sur le groupe A

— Apprentissage sur le groupe A, test sur le groupe B

— Apprentissage sur le groupe B, test sur le groupe A

— Apprentissage sur le groupe B, test sur le groupe B

Lors du test, nous relevons pour chaque position de note, l'erreur moyenne sur l'ensemble des exemples de test, ceci dans le cadre des 3 architectures décrites dans la section 2.2.

Les mesures effectuées en utilisant le même ensemble de test que celui utilisé pour l'apprentissage permettent de caractériser les capacités de compression de l'information mélodique par les différentes architectures, en fonction de la position de la note dans le segment musical. Celles qui croisent les ensembles d'apprentissage et de test rendent compte la capacité de généralisation des architectures à des données nouvelles.

## 2.5. Critère d'évaluation

Pour chaque instant $t$, nous calculons l'erreur entre le vecteur de sortie $x_t$ et la note réelle $x_t$ par la fonction d'erreur quadratique moyenne (MSE). On rappelle que $x$ est un vecteur de dimension $n = 88$ correspondant à une distribution de probabilités et $x$ un vecteur one-hot de même dimension, correspondant à la note effectivement active.

$$MSE = \frac{1}{n} \sum_{i=1}^{n} (x_i - x_i)^2 \quad (5)$$

C'est l'évolution de cette erreur que nous examinons pour chaque position de note et dans chaque scénario, afin d'observer la façon dont les différentes architectures encodent les dépendances structurelles. Nous analysons à
la fois les motifs engendrés par la variation de l’erreur
moyenne entre les différentes positions ainsi que le critère
de compression / prédiction.

2.6. Détails complémentaires de mise en oeuvre

Pour ces expériences nous utilisons la bibliothèque
d'apprentissage profond Pytorch 2. L'historique est un
vecteur de dimension 100. Chaque exemple est présenté
40 fois au cours de l'apprentissage (40 epochs). L'optimi-
seur utilisé est Adagrad.

3. RÉSULTAT

Les figures 4 et 5 illustrent les résultats du protocole
expérimental décrit dans la section précédente. La figure
4 correspond aux différentes architectures apprises à partir
du corpus A et la figure 5 aux architectures apprises sur le
corpus B.

Pour chacune de ces figures, les résultats de généralisa-
tion des architectures sont représentés sur les graphiques
Ag, Bg, Cg et les résultats de compression sur les gra-
phiques Ao, Bo et Co.

— graphique A : architecture à historique parallèle

— graphique B : architecture à historique croissant

— graphique C : architecture à historique glissant

En premier lieu, on constate une similarité de compor-
tement entre courbes homologues sur la figure 4 et la fi-
gure 5. Ceci permet de penser que les tendances observées
sont relativement peu influencées par les spécificités des
deux demi-corpus.

On remarque ensuite que pour les architectures à his-
torique glissant et croissant, les valeurs des capacités de
généralisation (Bg et Cg) présentent un niveau d'erreur
à peine plus élévé que les valeurs des capacités de com-
pression (Bo et Co). A l'inverse, les capacités de com-
pression et de généralisation de l'architecture parallèle se
comportent très différemment l'une de l'autre. En effet,
l'architecture parallèle possède beaucoup plus de para-
mètres libres ce qui crée une capacité bien plus forte du
réseau à comprimer les données d'apprentissage mais en-
 traîne un phénomène d'over-fitting (surapprentissage) qui
altère la capacité de généralisation sur de nouvelle don-
nées. Ce phénomène est bien moins saillant sur les deux
autres architectures.

Un examen plus précis des motifs observés sur les
courbes d'erreur apporte également des observations in-
téressantes.

Les courbes pour les historiques glissant et croissant présentent une pseudo-periodicité marquée à l'échelle de 8 notes et des oscillations secondaires aux échelles 4 et 2, suggérant fortement une "synchronisation" des capacités de modélisation des architectures correspondantes sur des cycles de 2 mesures.

Les courbes Ao (que ce soit pour la figure 4 ou la fi-
gure 5) présentent pour leur part un comportement plus
contrasté : tout d'abord une décroissance très nette sur le

premier quart du segment puis des variations plus erra-
tiques sur la partie centrale (2ème et 3ème quart) et enfin
une remontée globale de l'erreur sur le dernier quart. On
peut opérer un rapprochement entre ces observations ex-
périmentales et différentes considérations musicologiques
sur la structure des segments musicaux : notamment que
l'on constate souvent la réalisation de formules musi-
cales conventionnelles en fin de segment, donc finalement
moins prédictibles en fonction du contexte, puisqu'elle
sont plus ou moins prédéterminées d'avance indépendem-
ment de celui-ci.

Par ailleurs, selon le modèle cognitif d'Implication-
Réalisation de Narmour [13] (et son extension récente
[2]), les fins de segments structurels constituent fréquem-
ment des dénis d'implication par rapport aux progres-
sion musicales établies dans les portions antérieures, ce
qui peut également constituer une hypothèse expliquant le
comportement observé sur les courbes Ao. Toutefois ce
comportement étant moins net sur les courbes Ag, des ex-
périences complémentaires sont requises pour mieux as-
seoir ces hypothèses.

4. CONCLUSIONS

Dans ce travail d'exploration, nous avons considéré
trois architectures de réseaux de neurones récurrents et
nous avons analysé leur comportement en terme d'erreur
de modélisation de schémas mélodiques simplifiés.

Ces expériences nous ont permis d'observer que la
prise en compte de la non-invariance dans le temps de la
structure musicale dans une architecture de réseau de neu-
rones récurrent permet de rendre compte de façon plus fine
de la structure globale des mélodies apprises par le réseau.

Dans le cadre de nos expériences actuelles, cette
conclusion demeure partielle, du fait d'un volume de don-
nées d'apprentissage limité qui entraîne une capacité in-
suffisante de généralisation du réseau appris.

Toutefois, cette première exploration de l'hypothèse de
non-invariance dans le temps de la structure musicale par
des réseaux de neurones récurrents nous conforte dans
l'idée de poursuivre nos recherches dans cette voie.

Plusieurs pistes sont prévues pour compléter ces tra-
vaux à court terme, permettant ainsi d'enrichir ces pre-
mières investigations par des expériences supplémentaires
et les résultats correspondants.

5. REMERCIEMENT

Ce travail a reçu le support de l'Agence Nationale
de la Recherche dans le cadre du projet DYCI2 Dyna-
miques Créatives de l'Interaction Improvisée (ANR-14-
CE24-0002-01) et de la Région Bretagne.

<footnote n="2">2. http://www.pytorch.org</footnote>
<figure><img src="image_71.png" /><figcaption>Figure 4. A. Erreur de prédiction moyenne pour chaque position.</figcaption></figure>

<figure><img src="image_72.png" /><figcaption>Figure 5. B. Erreur de prédiction moyenne pour chaque position.</figcaption></figure>
Références

[1] Bahdanau, D. Cho, K. Bengio, Y. "Neural machine translation by jointly learning to align and translate", *arXiv preprint arXiv:1409.0473*, 2016.

[2] Bimbot, F. Deruty, E. Sargent, G. Vincent, E. "System & contrast : a polymorphous model of the inner organization of structural segments within music pieces", *Music Perception, University of California Press*, California, USA, 2016.

[3] Boulanger-Lewandowski, N. Bengio, Y. Vincent, P. "Modeling temporal dependencies in high-dimensional sequences : application to polyphonic music generation and transcription", *arXiv preprint arXiv:1206.6392*, 2012.

[4] Chen, J., Miikkulainen, R. "Creating melodies with evolving recurrent neural networks", *Proceedings of the 2001 International Joint Conference on Neural Networks. IEEE*, Washington, USA, 2001.

[5] Cho, K. Van Merriënboer, B. Gulcehre, C. Bahdanau, D. Bougares, F. Schwenk, H. Bengio, Y. "Learning phrase representations using RNN encoder-decoder for statistical machine translation", *Conference on Empirical Methods in Natural Language Processing*, Qatar, 2014.

[6] Eck, D. Schmidhuber, J. "Finding temporal structure in music : blues improvisation with LSTM recurrent networks", *Proceedings of the 12th IEEE Workshop on Neural Networks for Signal Processing*, 2002.

[7] Franklin, J. "Jazz melody generation from recurrent network learning of several human melodies", *Proceedings of the Eighteenth International Florida Artificial Intelligence Research Society Conference*, Florida, USA, 2005.

[8] Guichaoua, C. "Modèles de compression et critères de complexité pour la description et l'inférence de structure musicale", *Thèse supervisée par Bimbot*, F., France, 2017.

[9] Hochreiter, S. Schmidhuber, J. "Long short-term memory", *Neural computation 9 (8), 1735-1780*, Massachusetts, USA, 1997.

[10] Huang, A. Wu, R. "Deep learning for music", *arXiv preprint arXiv:1606.04930*, 2016.

[11] Jaques, N. Gu, S. Turner, R. Eck D. "Generating music by fine-tuning recurrent neural networks with reinforcement learning", *Deep Reinforcement Learning Workshop, NIPS*, California, USA, 2017.

[12] Louboutin, C. Bimbot, F. "Description of chord progressions by minimal transport graphs using the system & sontrast model", *Proceedings of the 42nd International Computer Music Conference*, Netherlands, 2016.

[13] Narmour, E. "The analysis and cognition of basic melodic structures : the implication-realization model", *Univ. of Chicago Press*, Illinois, USA, 1990.

[14] Raffel, C. "Learning-based methods for comparing sequences, with applications to audio-to-MIDI alignment and matching", *PhD Thesis*, Colombia, USA, 2016.

[15] Smolensky, P. "Information processing in dynamical systems : foundations of harmony theory", *MIT Press Cambridge*, Massachusetts, USA, 1986.

[16] Werbos, P. "Backpropagation through time : what it does and how to do it", *Proceedings of the IEEE volume 78, 1990.*
# ÉVALUATION DE LA CORRECTION RYTHMIQUE DES PARTITIONS NUMÉRISÉES

Francesco Foscarin

CEDRIC, CNAM, Paris
francesco.foscarin@cnam.fr

Raphaël Fournier-S'niehotta

CEDRIC, CNAM, Paris
fournier@cnam.fr

Florent Jacquemard

Inria, Paris
florent.jacquemard@inria.fr

Philippe Rigaux

CEDRIC, CNAM, Paris
philippe.rigaux@cnam.fr

## Résumé

Nous proposons une représentation des éléments de gravure musicale ayant trait au rythme – figures de notes, tuplets, ligatures, etc. – sous la forme d'arbres. Cette modélisation permet de lever les ambiguités et redondances contenues dans les différents encodages de partitions numériques, qui sont des sources d'incohérences majeures.

Le modèle est développé théoriquement, puis nous présentons son intégration dans des procédures de vérification d'encodages. Il est également montré que l'on peut l'utiliser pour des tâches de génération de partitions.

## 1. INTRODUCTION

Aujourd'hui, produire des partitions musicales numérisées de bonne qualité demande un effort important. En effet, il faut pour cela inspecter à l'œil le rendu graphique après numérisation pour y dénicher les erreurs, ce qui s'avère difficile en raison de la complexité sémiologique de la notation musicale.

Dans le cadre de l'édition collaborative, ce problème est particulièrement important, puisque chaque contributeur est susceptible d'utiliser son propre logiciel de gravure. Les encodages de documents musicaux comme MusicXML [6] ou MEI [13, 10] sont largement utilisés comme formats d'échange, ainsi que pour le stockage dans des bases de partitions numériques dont le contenu peut être inspecté, modifié et indexé. Ces encodages XML sont très permissifs et n'effectuent pas de vérification de la correction, de la cohérence ou de la complétude d'une partition. Leur grande flexibilité est bien adaptée à la prise en compte des évolutions et variations de la notation musicale, mais en contre-partie, laisse aux humains une partie délicate et couteuse de la production de partitions.

Nous proposons dans cet article une modélisation d'éléments de gravure, en vue d'assister les créateurs de partitions dans des tâches de vérification des données encodées. Nous nous limitons à la partie ryth-

mique de la notation. Les problématiques auxquelles nous apportons une réponse sont détaillées dans la section 2. Nous présentons ensuite notre modèle dans la section 3, des projets en cours autour de leur application à l'analyse de partitions (section 4) ainsi que des perspectives d'applications dans le cadre de tâches impliquant la génération de partitions numériques (section 5). Nous développons en particulier les contributions suivantes :

- un formalisme de modélisation des éléments rythmiques de notation musicale, reposant sur deux structures sous-jacentes complémentaires : les arbres de *ligature* et les arbres de *tuple* (pour les groupements de notes tels que les triolets);

- un développement de ce formalisme pour *valider* des partitions existantes, c'est-à-dire en éliminer les ambiguités et redondances présentes dans l'encodage XML;

- une proposition de génération de partitions dans un format XML, à partir de ces structures d'arbres;

- l'intégration de cette modélisation dans une plate-forme en ligne proposant d'ores et déjà de l'analyse automatisée de la qualité de partitions musicales.

## 2. ÉLÉMENTS DE NOTATION RYTHMIQUE

Les encodages MusicXML et MEI permettent de décrire dans un même document à la fois des informations relatives au contenu musical d'une pièce, indépendamment de la manière dont ce contenu est rendu sur une partition imprimée, et des informations relatives à l'apparence graphique de ce contenu.

Par exemple en MusicXML la *durée* de chaque événement est décrite dans un élément XML `<duration>`, qui contient une valeur exprimée en fraction de noire (*quarter-length*), ou plus précisément en nombre de divisions élémentaires de la noire. Le nombre maximal de divisions d'une noire est par ailleurs spécifié en début de voix (avec l'élément `<divisions>`), suivant l'approche du standard MIDI. Par exemple, pour un
nombre de divisions de la noire de 120, dans une mesure à 4/4, une durée de 120 correspond à une ♩, 60 à une ♩, 30 à une ♩, 40 à une ♩ de triolet, etc.

Par ailleurs, le *type* de chaque note est également spécifié dans un élément `<type>`, qui prendra par exemple la valeur **quarter** pour ♩, **eighth** pour ♩, **16th** pour ♩, etc. Cette valeur peut être déduite de la durée spécifiée comme ci-dessus (en prenant en compte le nombre de divisions de la noire), mais elle est aussi écrite explicitement dans le document, pour décrire la figure de note qui sera imprimée dans la partition. Ainsi, pour l'exemple du paragraphe précédent, le même type de note ♩ correspond aux deux durées 60 et 40.

La correspondance entre durée et type de note dépend aussi du contexte de la note, et plus précisément du groupe dans lequel elle figure. Par exemple, les trois premières noires de la première mesure de la figure 1 ont une durée de $\frac{2}{3}$ de noire, car elles forment un triolet de noires.

Dans la suite de cet article, nous utiliserons le terme *tuple*, issu du jargon informatique, pour désigner les groupes de notes correspondant à une valeur rythmique quelconque (noire, blanche croche), tels que les triolets notés avec le chiffre 3, ou plus généralement d'autres divisions composées d'un ensemble impair de notes [5].

Tous les tuples de notes définissent des durées musicales suivant une logique de division d'un intervalle temporel en parts égales. La notation d'un tuple par $n:m$ (`<time-modification>`), en MusicXML) signifiant une division en $n$ parts dans le même temps que $m$, précise à la fois la longueur de l'intervalle divisé ($m$ valeurs) et le nombre $n$ de divisions du tuple. Cependant, du point de vue de la gravure, suivant le contexte et la signature rythmique en vigueur, les entiers $m$ et $n$ devront figurer explicitement ou non dans une partition. Ainsi, en figure 1, tous les 3 signifient 3 : 2, le 2 étant omis.

Les tuples de notes peuvent être imbriqués suivant un système hiérarchique de divisions. Les limites d'un tuple sont explicitées par des crochets ou des *ligatures* (*beams*). Les ligatures ne sont pas formellement nécessaires pour la définition des durées de notes en notation musicale (les figures de notes et indications de tuples étant a priori suffisantes), leur usage est essentiel pour faciliter la lecture d'une partition, en particulier la compréhension de la métrique. Par exemple, dans la figure 1, les tuples divisant des durées d'un temps à la fin des mesures 1 et 3 sont ligaturés. En MusicXML, les début et fin de tuples et de ligatures (ainsi que les continuations de ligatures ou les ligatures partielles) doivent être indiqués explicitement à chaque note, par des éléments `<tuplet>` et `<beam>`, dont la valeur (pour le second) ou une valeur d'attribut (pour le premier) indique s'il s'agit d'un début, d'une fin, d'une continuation, etc. Cependant, les imbrications de tuples ou ligatures (tels que ceux de

<figure><img src="image_73.png" /><figcaption>**Figure 1 :** Tuples imbriqués avec ou sans ligatures. Dans cet article, le terme *ligature* (*beams*) se réfère aux barres utilisées pour regrouper des croches, à ne pas confondre avec les liaisons.</figcaption></figure>

la figure 1) ne sont pas représentés par des imbrications d'éléments XML. Ainsi, un document XML valide pourra contenir des éléments marquant les début et fin de tuple/ligature qui ne sont pas bien apariés (en général, le chargement d'un tel document dans un outil comme Finale va échouer). Cela peut induire des incohérences et complique l'implémentation de conventions.

En outre, la relation entre les durées et les types de notes peut aussi être modifiée par l'ajout de *liaisons* (`<tie>`) et de *points*.

Les interdépendances décrites ci-dessus induisent des redondances pour les données présentes dans les encodages de partitions, en particulier en ce qui concerne les aspects rythmiques. Il existe alors des risques d'incohérences dans les encodages, par exemple si les durées (de l'élément `<duration>`) ne correspondent pas aux figures de notes spécifiées (élément `<type>`). D'autres risques d'incohérences structurelles sont liés aux éventuels problèmes d'appariement mentionnés ci-dessus, par exemple avec la spécification d'un tuple ouvert et non fermé.

Une manière d'éviter de telles incohérences pourrait passer par l'expression de *contraintes d'intégrité* (dans un formalisme adéquat) et leur vérification au chargement d'un document. Les schémas XML utilisés actuellement pour les partitions numériques n'incluent pas de telles contraintes. Un document valide d'un point de vue syntaxique (*i.e.* valide par rapport au schéma XML considéré) pourra donc contenir des erreurs, le rendant inutilisable.

Modifier les encodages existants pour ajouter des contraintes d'intégrité ne semble pas une solution réaliste. Premièrement, en raison de la multiplicité des formats considérés comme standards. Deuxièmement, parce qu'en plus des règles strictes d'intégrité (par exemple pour les durées), un certain nombre de règles d'usage, comme la notation des tuples et des ligatures (*cf.* figure 8), relèvent plus de conventions, et les corder de façon définitive dans un schéma serait trop restrictif. De plus, les règles pourront varier suivant le style musical considéré – on peut citer l'exemple des valeurs ajoutées en musique contemporaine.

Pour vérifier qu'une règle ou une convention est satisfaite dans une partition donnée, ou en tenir compte dans des tâches générant une partition, nous choisissons de l'exprimer sous forme de règles simples, portées par un formalisme non ambigu et indépendant des encodages, présenté dans la section suivante.
<figure><img src="image_74.png" /><figcaption>**Figure 2** : Le modèle proposé et son intérêt pour la production de partitions. La flèche 1 correspond aux processus décrits dans la section 4 de cet article, la flèche 2 à ceux de la section 5.</figcaption></figure>

### 3. MODÈLE ABSTRAIT DE GRAVURE

Afin de répondre aux problèmes présentés ci-dessus, nous proposons un modèle abstrait d'éléments de notation rythmique, orienté vers les informations graphiques relatives à la gravure. La figure 2 illustre l'intérêt de notre modélisation pour la production de partitions.

Suivant des travaux antérieurs [9, 1], nous choisissons des représentations de la notation rythmique dans des structures d'arbres. En effet, un tel codage est naturel pour le rythme dans la mesure où il reflète le principe de division hiérarchique des durées en musique [11]. Une autre motivation pour le choix de cette structure de données standard est de permettre d'exprimer simplement des règles de notation à satisfaire et d'en automatiser efficacement la vérification.

Nous avons pris soin d'éviter la redondance d'information dans les modèles proposés. Ainsi, les informations non représentées explicitement, telles que les durées de notes, peuvent être calculées à partir des informations présentes dans le modèle.

Nous avons implémenté des procédures de traduction depuis des encodages XML de partitions vers des arbres et dans la direction inverse, de manière à exploiter ce modèle d'une part dans des tâches de vérification de contraintes d'intégrité appliquées à des partitions XML existantes, et d'autre part pour la génération de partitions XML correctes.

Nous considérons deux types d'arbres dans les trauctions, correspondant à deux aspects : les arbres de ligature d'une part, les arbres de tuple d'autre part. Nous les présentons ci-dessous.

#### 3.1. Arbres de ligature

À chaque mesure de chaque voix d'une partition nous associons un arbre représentant à la fois les figures de notes et les ligatures entre notes.

**Définition.** Dans un arbre, s'il existe une arête $\langle v, v' \rangle$, on dit que le sommet $v'$ est le successeur de $v$. Un sommet qui n'est le successeur d'aucun autre est appelé *racine*. Il n'existe qu'une racine par arbre considéré. Un sommet sans successeur est appelé *feuille*. Les sommets qui ne sont pas des feuilles sont appelés *internes*.

Chaque feuille d'un arbre de ligature est étiquetée par un symbole représentant les informations suivantes :

<figure><img src="image_75.png" /><figcaption>**Figure 3** : Différentes gravures d'un même rythme (en haut), les arbres de ligature (milieu) et les arbres de tuple associés (en bas).</figcaption></figure>

- une figure de tête de note, parmi $|\bigcirc|$, $\circ$, $\cdot$, et $\div$. Ces figures sont notées respectivement $N_{\frac{1}{2}}$, $N_1$, $N_2$, $N_4$, l'indice indiquant une durée en fraction de ronde (suivant l'usage dans certains encodages dont MusicXML). On pourrait ajouter des symboles plus longs que $|\bigcirc|$ avec $N_{\frac{1}{4}}$, etc. En revanche, les durées plus courtes que $\div$ (représentées en notation musicale par des crochets – ou ligatures, et non des têtes de notes particulières) sont codées dans la structure de l'arbre comme nous le verrons plus bas.

- optionnellement, un ou plusieurs points, chaque point augmentant la durée de la moitié de sa valeur (pour le premier point) ou de la valeur du point précédent (pour les suivants).

- optionnellement, une liaison (tie), notée par $-'$ au début du symbole, indiquant que la durée du symbole s'ajoute à celle du symbole précédent dans l'arbre (suivant un parcours des feuilles en profondeur d'abord).

On utilise également des symboles de silences construits autour de $R_{\frac{1}{2}}$, $R_1$, $R_2$, $R_4$ suivant le même principe. On trouve différents exemples de symboles de feuilles dans les arbres de ligature de la figure 3.

Les nœuds internes des arbres de ligature sont sans étiquette. Nous les représentons avec un · dans la figure 3.

Les arêtes d'un arbre de ligature peuvent être de deux types. Les arêtes pleines se propagent vers les feuilles : si $\langle v, v' \rangle$ est une arête pleine, toute arête sous $v'$ est pleine. Chaque arête pleine représente un crochet dans le cas de notes isolées, ou une ligature dans le cas de notes regroupées. Plus précisément, pour une feuille étiquetée par $N_4$ (figure de note $\div$), le nombre de crochets (ou ligatures) est le nombre d'arêtes pleines sur le chemin entre cette feuille et la racine. Donc une feuille $N_4$ avec deux arêtes pleines jusqu'à la racine représente une durée de $\div$. C'est
<figure><img src="image_76.png" /><figcaption>Figure 4 : Arbres de ligature.</figcaption></figure>

<figure><img src="image_77.png" /><figcaption>Figure 5 : Arbres de ligature (examples de [7]).</figcaption></figure>

Le cas par exemple de la première note, isolée, dans l'exemple en haut à droite de la figure 4 et des trois dernières notes de cette mesure (qui sont groupées par une ligature).

Le principe est le même pour les silences, comme on peut le voir dans la même mesure de la figure 4, et la mesure en bas à droite de la même figure.

Les arêtes du second type sont représentées en pointillés, et n'ont pas la signification des premières. Elle sont simplement utilisées pour ajouter des événements qui ne sont pas liés par des ligatures (c'est le cas en particulier des silences), dans un arbre où les événements sont lus dans un parcours en profondeur d'abord.

Les arêtes des arbres de ligature apportent des informations quand à la gravure des figures de rythmes, ainsi que décrit formellement dans le paragraphe ci-dessous. En revanche, les durées des notes représentées ne peuvent être calculées à partir des arbres de ligature seuls. L'utilisation conjointe des arbres de ligature et des arbres de tuple décrits au paragraphe 3.2 est nécessaire pour déduire les informations sémantiques de durées.

**Propriétés.** Appelons *profondeur pleine* d'un sommet d'un arbre de ligature le nombre d'arêtes pleines sur le chemin entre ce sommet et la racine.

Nous avons vu que dans le cas d'une feuille, la profondeur pleine indique le nombre de crochets ou de ligatures pour l'élément correspondant.

Le plus petit ancêtre commun de deux sommets $n_1$ et $n_2$ d'un arbre de ligature est noté $lca(n_1, n_2)$, et

<figure><img src="image_78.png" /><figcaption>Figure 6 : Arbres de ligature et arbres de tuples pour les mesures de la figure 1.</figcaption></figure>

$plca(n_1, n_2)$ est le plus petit ancêtre commun de $n_1$ et $n_2$ en ne passant que par des arêtes pleines. Plus formellement, $plca(n_1, n_2) = lca(n_1, n_2)$ si le chemin entre $n_1$ et $lca(n_1, n_2)$ ainsi que le chemin entre $n_2$ et $lca(n_1, n_2)$ ne contiennent que des arêtes pleines, et $plca(n_1, n_2)$ n'est pas défini sinon.

La propriété suivante des arbres de ligature est utilisée dans les applications présentées ci-dessous :
Le nombre de ligatures entre deux feuilles $\ell_1, \ell_2$ est la profondeur pleine de $plca(\ell_1, \ell_2)$ plus 1, si $plca(\ell_1, \ell_2)$ est défini, et 0 sinon.

On peut par exemple vérifier cette propriété sur la figure 5. Le nombre de ligatures entre chaque paire de notes successives de la première mesure est 2 (car la profondeur pleine de leur $plca$ est 1). Dans le cas de la deuxième (resp. troisième) mesure de la figure 5, le nombre de ligatures entre la première et deuxième note, ainsi qu'entre la troisième et quatrième note est 2 (resp. 3), mais le nombre de ligatures entre la deuxième et troisième note n'est que de 1 (resp. 2). Nous verrons en section 4.2 que cela correspond à des conventions de notation des ligatures.

## 3.2. Arbres de tuple

Les arbres de tuple représentent les éléments de notation des tuples, plus précisément les emplacements de chiffres et crochets définissant explicitement dans une partition la nature des tuples. Les figures 3 et 6 présentent des exemples d'arbres de tuple.

**Définition.** Chaque nœud interne d'un arbre de tuple est étiquetés ou bien par une paire d'entiers $n : m$, $n, m \ge 2$, signifiant $n$ éléments à la place de $m$, ou bien par un seul entier $n$ si $m$ peut être omis, ou bien pas étiqueté (représentés avec un · dans les figures). Les feuilles de ces arbres sont sans étiquette.

**Propriétés.** La sémantique d'un arbre de tuple est la suivante. Un arbre de tuple et son arbre de ligature associé ont toujours le même nombre de feuilles, correspondants au nombre de figures de notes représentées. Lorsqu'un nœud interne est étiqueté par $n$
ou *n* : *m*, la suite des éléments correspondant aux feuilles sous le nœud interne se voit affectée (dans la notation rythmique) la même étiquette (*n* ou *n* : *m*). L'étiquette est notée ou bien au-dessus de la ligature définie par l'arbre de ligature, ou bien au dessus d'un crochet ajouté dans le cas où l'arbre de ligature ne définit pas de ligature entre les éléments concernés.

Par exemple, dans le cas de la première mesure figure 6, la suite des trois premières notes est étiquetée par 3 (avec un crochet), la suite des trois dernières notes est étiquetée aussi par 3 (sans crochet car ces trois notes sont ligaturées comme défini par l'arbre de ligature), et les deux notes du milieu n'ont pas d'étiquette de tuple.

### 3.3. Calcul des durées et complémentarité

Notons que, pas plus qu'un arbre de ligature, un arbre de tuple seul ne permet pas de déduire les informations sémantiques sur les durées de notes. L'utilisation conjointe d'un arbre de ligature et d'un arbre de tuple est nécessaire pour cela (cf. paragraph 4.2). En se sens, les deux types d'arbres sont complémentaires.

L'introduction de ces deux types d'arbres complémentaires s'est avéré nécessaire car il existe des cas où il n'est pas possible de coder simplement dans un même arbre les ligatures et les informations sur les notations de tuples. Considérons par exemple la mesure (c) de la figure 3. Les deux dernières feuilles correspondent à des éléments appartenant au même triplet (triolet de doubles). Mais dans l'arbre de ligature, les deux dernières feuilles ne sont pas à des positions frères. Par conséquent il n'est pas possible d'ajouter l'étiquette 3 de triolet à un nœud interne de l'arbre de ligature : le nœud parent de l'avant-dernière feuille ne concernerait que cette feuille, et la racine concernerait l'ensemble de la figure (un 3 à la racine correspondrait à un triolet de croches). Le rôle de l'arbre de tuple est ici donc d'offrir un nœud interne parent de ces deux dernière feuilles pour introduire la notation 3.

Les durées de notes peuvent être calculées à partir des étiquettes des arbres de ligature et tuple, et de leur structure : nous avons vu que ces deux types d'arbres fournissent les informations nécessaires pour la gravure de rythmes (figures de notes, points, liaisons, ligatures et tuplets). Les durées peuvent donc être déterminées à partir des rythmes gravés suivant les règles du solfège.

Plus précisément, l'arbre de ligature permet de déduire pour chaque feuille une durée temporaire, suivant l'étiquette de cette feuille et sa profondeur pleine dans l'arbre (qui indique rappelons-nous, le nombre le nombre de crochets ou de ligatures). Par exemple, pour le cas (b) de la figure 3, la durée temporaire de la première note est $\frac{1}{8}$ (de ronde), déduit de l'étiquette $N_4$ (correspondant à $\frac{1}{4}$ de ronde) et la profondeur pleine 1 (correspondant à une ligature, donc une division par 2 de $\frac{1}{4}$). C'est aussi le cas de la dernière

note. La durée temporaires des deuxième et troisième feuilles est $\frac{1}{16}$. Puis cette durée temporaire est ajustée suivant les informations contenues dans l'arbre de tuple : si une feuille est sous un nœud étiquetté *n* : *m* (avec $m = 2$ dans le cas où le second entier est manquant), on applique le coefficient $\frac{m}{\eta_1}$. Dans l'exemple ci-dessus, on obtient une durée de $\frac{1}{12} = \frac{1}{8} \times \frac{2}{3}$ pour la note correspondant à la première et la dernière feuille, et $\frac{1}{24}$ pour les deuxième et troisième notes.

Dans le cas (c) de la même figure, la durée de la première note est $\frac{1}{2}$ (ici le coefficient d'ajustement est 1), la durée de la seconde note est $\frac{1}{24} = \frac{1}{16} \times \frac{2}{3}$, et la durée de la dernière note est $\frac{1}{12} = \frac{1}{8} \times \frac{2}{3}$.

### 3.4. Autres représentations

L'environnement d'assistance à la composition OpenMusic [3] utilise une structure appelée arbres de rythme (OMRT) pour la représentation des données musicales temporelles symboliques. Les OMRT suivent le principe de la définition de durées symboliques par divisions récursives d'intervalles temporels, et sont donc proches conceptuellement de la notation rythmique traditionnelle. Cela les rend très utiles dans un contexte d'aide à la création et de manipulation algorithmique de structure rythmiques complexes. Leur usage dans un contexte de gravure des rythmes a aussi été étudié dans [1].

Les arbres de ligature et de tuple présentés ici diffèrent des OMRT dans la mesure où ils mettent l'accent sur la représentation graphique de la notation, et non sa définition logique (i.e. sa sémantique).

En section 5, nous suggérons des applications où les arbres de ligature et tuple sont utilisés comme un intermédiaire entre les OMRT (ou des arbres de rythmes similaires) et la notation finale dans un contexte d'aide à la gravure.

## 4. APPLICATIONS À L'ÉVALUATION DE PARTITIONS NUMÉRISÉES

Nous présentons dans cette section la validation de partitions numérisées à l'aide de notre modélisation sous forme d'arbres, ce qui correspond à la flèche 1 de la figure 2.

### 4.1. Importer des fichiers XML

Nous avons écrit des procédures d'extraction d'arbres de ligature et arbres de tuple à partir de fichiers MusicXML et MEI.

La construction des arbres se fait séparément (en deux passes) à partir des informations dans le fichier XML sur les structures de ligatures et de tuples, e.g. dans le cas de MusicXML à partir des éléments respectivement de la forme <beam> et <tuple>.

Nous passons pour cela par la boite à outils MuSIC21 [4], qui assure la lecture et l'analyse (parsing)
du fichier XML et la conversion sous forme de séquences d'événements. Ces événements contiennent en particulier des informations sur les début et fin de chaque ligature, tuple, etc. Des fonctions Python ont été écrites pour parcourir ces séquences d'événements de gauche-à-droite et construire les arbres de ligature et de tuple à l'aide d'une pile.

## 4.2. Évaluation de la qualité des données

Dans le cadre du projet GIOQOSo portant sur l'étude de l'évaluation de la qualité des données dans les partitions numériques, nous avons proposé un ou-til qui réunit dans une interface unifiée différentes procédures d'évaluation qualitative de partitions mu-sicales<fnref n="1" />, voir l'illustration sur la figure 7.

Ces évaluations s'appliquent à toute partition dans un format XML (MusicXML ou MEI) accessible par une URL. Nous donnons ci-dessous quelques exemples de propriétés sur les données relatives à la notation rythmique, vérifiées grâce à la construction d'arbres de la section 3.

**Vérification des durées.** Le calcul présentée au par-agraph 3.3 est utile pour la vérification de l'inté-grité des données contenues dans une partition numé-rique, plus précisément pour vérifier que chaque du-rée symbolique enregistrée (en *quarter-length*, XML <duration>, cf. paragraphsec:elements) correspond bien à la durée définie par les types de notes, les nombres de crochets ou ligatures, voire les tuples dans lesquelles ces notes sont incluses (cf. paragraph 3.3).

Une incohérence entre durée enregistrée et sa re-présentation graphique peut être considérée comme une erreur critique sur une partition, particulièrement si cette valeur de durée est utilisée dans un traitement de la partition.

Une autre procédure de GIOQOSo vérifie que cha-que mesure a la durée totale attendue, en faisant la somme des valeurs de durées des éléments contenus dans la mesure. La cohérence entre valeurs et repré-sentations des durées est donc importante dans ce cadre.

**Notation de tuple.** En fonction du contexte (signa-ture rythmique), l'étiquetage des tuples (par un en-tier ou une paire d'entier) doit être écrit explicitement ou pas, suivant des règles précises. Il peut être véri-fié directement sur les arbres de tuple, par des tests sur les étiquettes, (cf. description au paragraphe 3.2), que les notations de tuples écrites devaient bien être explicites, et que ces notations sont correctes.

**Conventions sur les ligatures.** Certaines règles de bonne pratique pour l'écriture des ligatures, moins critiques que les problèmes d'intégrité présentés plus haut, sont néanmoins d'une grande importance en ce qui concerne la lisibilité des partitions. Les groupe-ments de notes définis par les ligatures permettent

en effet de donner au lecteur des informations vi-suelles immédiates sur les appuis métriques. Ces grou-pements doivent donc être cohérents avec la métrique.

Par exemple, il est convenu (voir [7] page 155) que certaines positions de la mesure (temps forts) ne doivent pas être croisées par une ligature car elles cor-respondent à des temps forts de la mesure (comme le troisième temps d'une mesure à 4/4).

Une telle propriété peut être vérifiée à l'aide de l'es-timation des durées (paragraphe 3.3) et de la notion de nombre de ligatures entre notes, que nous avons présentée au paragraphe 3.1. Dans ce cas, le nombre de ligatures entre les deux feuilles situées de part et d'autre d'un temps fort à ne pas croiser devra être 0.

Il est également admis que les grands groupes de notes courtes (sous la double-croche, donc notés avec de multiples ligatures) sont plus faciles à lire lors-qu'ils sont divisés en sous-groupes dont la durée dé-pend de la métrique. D'après [7], le principe à suivre est que le nombre de ligatures séparant deux sous-groupes doit être égal à la durée des groupes qu'elles séparent. Cette recommandation est illustrée en fi-gure 8 et peut aussi être vérifiée grâce à la propriété des arbres de ligature mentionnée au paragraphe 3.1.

Un problème détecté concernant les règles ci-des-sus peut être signalé comme recommandation, il n'est pas du même niveau de criticité que les éventuelles in-cohérences sur les durées vues plus haut. Les fonction-nalités présentées plus haut sont été intégrées dans la bibliothèque Neuma, dans le cadre du projet GIO-QOSo.

## 4.3. Comparaison de partitions

La question d'une opération de recherche de diffé-rences dans des partitions numériques a été étudiée dans le cadre de l'édition collaborative en ligne de partitions [2]. Constatant d'une part que la comparai-son manuelle est particulièrement fastidieuse, et que lancer la commande Unix diff sur les fichiers (texte) XML contenant les partitions ne donne pas de résul-tat exploitable, [2] propose d'appliquer sur des repré-sentations hiérarchiques de partitions des algorithmes de calcul de distance d'édition sur les arbres [15, 12].

La représentation de la notation rythmique propo-sée ici pourrait être utilisée pour détecter des diffé-rences visuelles 2 entre partitions à un fin niveau de granularité, par simple comparaison (isomorphisme) d'arbres. Une représentation fidèle dans les arbres d'éléments graphiques de notation rythmique est a-vantageuse dans ce cadre, car elle assure une corres-pondance entre le résultat de la comparaison d'arbres et d'une comparaison visuelle de partitions. En d'au-tres termes, cette représentation des données ryth-miques pourrait aider à l'automatisation de la tâche

<footnote n="2">2. Notons que des notations sémantiquement équivalentes en terme de durées peuvent être différentes visuellement, cf. figure 3.</footnote>

<footnote n="1">1. http://neuma.huma-num.fr/quality</footnote>
<figure><img src="image_79.png" /><figcaption>**Figure 7** : Une capture d'écran de l'interface de GioQoSo, intégré à la plateforme Neuma. Des problèmes de notation rythmique sont indiqués par des points verts.</figcaption></figure>

<figure><img src="image_80.png" /><figcaption>**Figure 8** : Divisions dans les ligatures et arbres de ligatures correspondant. D'après [7] : "*le nombre de ligatures séparant deux sous-groupes doit être proportionnel à la durée des groupes qu'elles séparent*".</figcaption></figure>

laborieuse de comparaison de différentes versions de partitions.

En prévision d'un tel usage, et afin de proposer un retour précis à l'utilisateur sur les différences observées, les identifiants des éléments XML sont stockés dans les sommets des arbres de ligature et tuples (ce qui est possible avec MEI), dans la procédure d'extraction décrite dans la section 4.1.

## 5. APPLICATIONS EN MODÈLE GÉNÉRATIF (PERSPECTIVES)

Il est possible par un parcours d'arbres de ligature et de tuple d'extraire les éléments XML (`<beam>` et `<tuple>`) produisant les notations correspondantes. Nous discutons informellement dans cette section de plusieurs usages possibles (actuellement en cours de développement) des modèles présentés ci-dessus en modèle génératif, dans le cadre d'applications produisant des partitions numériques, ce qui correspond à

la flèche 2 de la figure 2.

L'avantage de l'utilisation de représentations intermédiaires sous forme d'arbres comme ci-dessus est de pouvoir s'appuyer sur des procédures bien établies, par exemple de *parsing* ou de *transformations* d'arbres, qui s'intègrent aisément dans un processus complet de production de partitions.

**Procédure générique.** Plus précisément, considérons le scénario suivant dans lequel les arbres de ligature et de tuples apparaissent comme représentation intermédiaire.

On suppose qu'à un certain stade de production d'une partition, nous disposons d'une suite d'événements musicaux dont les durées sont exprimées en fraction de noire (*quarter-length*). Cette séquence de durées peut être prise en entrée par une procédure de *parsing* suivant une *grammaire formelle* décrivant différents choix possibles de subdivisions successives des durées. Une telle procédure est présentée dans [8]. Les arbres de syntaxes produits sont appelés *arbres devisions* car ils décrivent les divisions choisies. Ils sont très similaires aux arbres de rythmes OpenMusic [1].

La figure 9 présente trois arbres de divisions possibles pour la suite de durées initiale $\frac{1}{2} \frac{1}{6} \frac{1}{3}$. Dans le premier des 3 arbres, on a une division initiale du temps en 3 parties égales. Le premier fils, feuille étiquetée par •, correspond à une note de durée $\frac{1}{3}$. Le deuxième fils est à nouveau divisé en deux parties égales de durée $\frac{1}{6}$. Le premier de ses deux petits-fils est étiqueté par •, et correspond à une note de durée $\frac{1}{6}$ (deuxième événement en entrée). Enfin, le troisième fils est étiché de la flèche 2 de la figure 2.
<figure><img src="image_81.png" /><figcaption>**Figure 9** : Trois arbres de divisions possibles pour la suite de durées $\frac{1}{2} \frac{1}{6} \frac{1}{3}$.</figcaption></figure>

queté par • et correspond donc à une note de durée $\frac{1}{3}$ (troisième événement en entrée).

Le premier arbre de division de la figure 9 correspond aux arbres de ligature et de tuple des cas (a) et (b) de la figure 3, à partir desquels sera généré le code XML donnant les notations (correspondantes). Le deuxième arbre de division de la figure 9 correspond aux cas (c) et (d) de la figure 3, et le troisième arbre au cas (e).

**Gravure.** Des langages textuels comme Lilypond ou Guido permettent d'écrire de manière symbolique des suites d'événements musicaux avec des durées. La procédure décrite sommairement ci-dessus pourrait donc être utile dans le cadre d'une conversion de code dans ces formats textuels vers des partitions XML.

Des informations sur les tuples peuvent être contenues dans le code Lilypond ou Guido, qui devront être prise en compte pour la création des arbres de division. Une approche pour traiter ces contraintes est de les utiliser pour modifier la grammaire formelle utilisée dans le parsing.

**Transcription.** La procédure générique ci-dessus, qui utilise les arbres de ligature et tuples, pourra aussi être utilisée comme sous-tâche en aval d'une procédure de transcription par étapes.

Supposons que les premières étapes de transcription permettent d'obtenir des suites d'événements aux durées arbitraires (e.g. provenant d'un enregistrement MIDI de performance, ou de descripteurs extraits d'un enregistrement audio). Une étape de quantification rythmique retournera une suite d'événements aux durées quantifiées (en quarter-length comme ci-dessus) ou bien directement des structures semblables aux arbres de divisions ci-dessus dans le cas d'une procédure comme [14]. Nous pouvons alors procéder comme ci-dessus pour la production d'une partitions XML à partir de ces données.

## 6. CONCLUSION

Nous avons proposé et développé un modèle abstrait capable de représenter l'information relative au rythme d'une partition musicale. Il repose sur une structure de données unique, les arbres (au sens de la théorie des graphes), utilisée pour produire des arbres de ligature et des arbres de tuple, à partir d'encodages XML de partitions. Ce modèle a été mis à profit pour valider ces encodages, au cœur de la plateforme Neuma. Nous avons également discuté les possibilités

(en cours de développement) de génération de notation à partir d'arbres existants, pour des tâches liées au rendu pour langages musicaux textuels ou la transcription.

Cette première avancée ouvre des perspectives intéressantes de travail et de collaboration avec la communauté musicologique. Tout d'abord, il serait sans doute utile de proposer une visualisation des arbres créés, dans Neuma mais aussi peut-être par l'intermédiaire d'un outil externe. Cela favoriserait l'adoption de ce modèle, pour les analystes comme pour les développeurs d'encodages.

Des extensions théoriques de ce travail de modélisation sont envisageables, pour valider par exemple d'autres aspects d'une partition que le seul rythme (accords, texte...). Le modèle pourrait également être étendu pour représenter l'ensemble d'une partition, avec des conteneurs pour voix, portées et systèmes.

Enfin, nous poursuivons l'objectif d'élaborer un outil de comparaison de partitions, dans lequel s'inscrit l'effort de modélisation présenté ici. Cela nécessitera d'une part l'élaboration d'algorithmes de comparaisons d'arbres appropriés et d'autre part le développement d'un retour visuel sur les partitions.

## 7. RÉFÉRENCES

[1] C. Agon, K. Haddad, and G. Assayag. Representation and rendering of rhythm structures. In *Proceedings Second International Conference on WEB Delivering of Music (CW'02)*, pages 109–113, 2002. IEEE Computer Society.

[2] C. Antila, J. Treviño, and G. Weaver. A hierarchical diff algorithm for collaborative music document editing. In *Third International Conference on Technologies for Music Notation and Representation (TENOR)*, 2017.

[3] J. Bresson, C. Agon, and G. Assayag. Openmusic: visual programming environment for music composition, analysis and research. In *Proceedings of the 19th ACM international conference on Multimedia*, pages 743–746. ACM, 2011.

[4] M. S. Cuthbert and C. Ariza. Music21: A Toolkit for Computer-Aided Musicology and Symbolic Music Data. pages 637–642, 2010.

[5] A. L. Danhauser. *Théorie de la musique*. H. Le moine, 1872.

[6] M. Good. *MusicXML for Notation and Analysis*, pages 113–124. W. B. Hewlett and E. Selfridge-Field, MIT Press, 2001.

[7] E. Gould. *Behind Bars*. Faber Music, 2011.

[8] F. Jacquemard, A. Ycart, and M. Sakai. Generating equivalent rhythmic notations based on rhythm tree languages. In *TENOR* 2017.

[9] M. Laurson. *Patchwork*: A visual programming language and some musical applications. Technical report, Sibelius Academy, Helsinki, 1996.
[10] Music Encoding Initiative. http://music-encoding.org, 2015.

[11] P. Nauert. A theory of complexity to constrain the approximation of arbitrary sequences of timepoints. *Perspectives of New Music*, 32(2):226–263, 1994.

[12] M. Pawlik and N. Augsten. Tree edit distance : Robust and memory-efficient. *Information Systems*, 56:157–173, 2016.

[13] P. Rolland. The Music Encoding Initiative (MEI). In *Proc. Intl. Conf. on Musical Applications Using XML*, pages 55–59, 2002.

[14] A. Ycart, F. Jacquemard, J. Bresson, and S. Staworko. A Supervised Approach for Rhythm Transcription Based on Tree Series Enumeration. In *Proceedings of the 42nd International Computer Music Conference (ICMC)*, 2016.

[15] K. Zhang and D. Shasha. Simple fast algorithms for the editing distance between trees and related problems. *SIAM journal on computing*, 18(6):1245–1262, 1989.
# THE STRUCTURAL FUNCTION OF MUSICAL TEXTURE:
TOWARDS A COMPUTER-ASSISTED ANALYSIS OF ORCHESTRATION

Didier Guigue

Mus³–Musicologia, Sonologia
& Computação – University of Campinas
didierguigue@gmail.com

Charles de Paiva Santana

Núcleo Interdisciplinar de Comunicação
Sonora – University of Campinas
charles@nics.unicamp.br

## ABSTRACT

Musical form and orchestration are closely related dimensions of the musical discourse. Despite the proposition of several practical tools for assisted-orchestration in the past few years, scarcely any computational methods for analyzing the role of orchestration in shaping musical form and its perception have been put forward. As an answer to that, in this presentation, we discuss a couple of *Open-Music* functions we designed for estimating the textural complexity of a piece's successive formal segments and sections. The calculations behind the functions originate in an appropriation of the mathematical theory of integer partitions and Wallace Berry's ideas on musical texture. In the current stage, our estimation of textural complexity is carried out upon the composer's prescriptions found on the musical score. Nevertheless, the work we present here is part of an overall model that ultimately aims to analyze form and orchestration combining symbolical and signal data, that is, joining the musical score and its performance recordings.

## 1. INTRODUCTION

From the end of the 19th century onwards, western classical composers began to adopt increasingly sophisticated, systematic strategies of orchestration<fnref n="1" />. As part of that trend, they were apt to actively correlate the orchestration technique with the crucial effort of structuring musical segments into a coherent whole, that is, the musical form. Eventually, different approaches for analyzing the orchestration technique of various composers and periods would emerge. For instance, Walter Piston, in his 1955 classic book on orchestration, stresses, although briefly, the relevance of such an undertaking:

> The objective in analysis of orchestration is to discover how the orchestra is used as a medium to present musical thought. [...] It is a means of studying how instruments are combined to achieve a balance of sonority, unity and variety of tone color, clarity, brilliance,

> expressiveness, and other musical values. Ultimately, the analytical process shows the differences in orchestral style between various composers and periods. [11, p. 397].

Afterward, the literature witnessed several developments concerning the analysis of orchestration; from the empirical, meticulous classifications of Charles Koechlin [10], through the pioneering sound-color theory of the 1978 book *Sound Design* [5], to the liberating and encompassing work of *Instrumentation in der Musik des 20. Jahrhunderts: Akustik-Instrument* [8].

Nowadays, in the era of computer-assisted composition and computational musicology, several practical tools for assisted-orchestration have been proposed. Even so, scarcely any computational methods for analyzing the role of orchestration in shaping and perceiving musical form haven been put forward. As an answer to that, we have been developing a methodological model for investigating such structural functions of orchestration using quantitative and qualitative methods supported by symbolical (musical score) and signal (audio files) data.

In this presentation, we are going to introduce the overall model followed by the implementation of one of its main stages, namely *the qualitative evaluation of musical texture using symbolical data*. More specifically, we would like to share the following contributions:

* A formalism allowing the correspondence between the segmentation of a musical score and audio files of its performance (section 2).

* An adaptation of the theory of integer partitions, together with an interpretation of Wallace Berry's ideas on texture, for evaluating texture complexity as a function of orchestration (section 3).

* A demonstration of the above concepts, involving symbolical data, implemented and running on the Openmusic[4] environment (section 4).

The Openmusic functions are available as part of the SOAL library. The presentation is concluded with a discussion on future developments and perspectives of the overall model.

<footnote n="1">¹ By orchestration, we mean the technique used to combine a large number of sonic resources.</footnote>
## 2. THE OVERALL MODEL: FROM THE SYMBOLICAL TO THE MATERIALITY OF THE PERFORMANCE

In our model, the orchestration is regarded as a two-dimensional phenomenon. The first dimension is the normative level of the written code, that is, the composer's prescriptions as they appear on the musical score. The second one is the practical, acoustic level of its performance. In other words, it concerns the actual result of those abstract prescriptions which, in turn, can be examined through audio files (via signal processing).

By acknowledging both dimensions, we intend to keep away potential biases and to cover orchestral styles less reliant on the normative level.

The segmentation of the musical piece into instrumentally distinctive, successive segments, in both dimensions, is pivotal to the overall model. That means that musical score and audio file(s) are sectioned into corresponding subsections. The segmentation, however, is not carried out concurrently in both mediums. It is achieved by firstly examining the musical score and cataloging every individual component of the orchestral sonic palette. It means recognizing not only the instruments required to play the composition but also every mode of execution specified on the score, including extended techniques, as *pizzicato*, *flutter-tonguing*, *col legno*, *sul ponticello*, etc. We designate this catalog as being the *Index of Sonic Resources* (SRI), and it takes the form of a textual list.

By tracking every change in the combination of components of the index, we can segment the musical score into successive individual blocks. We call each of those blocks a *Local Sonic Setup* or LSS for short.

It is only after the determination of the musical score's LSS's that the respective audio file(s) of its performance(s) are fittingly sectioned. We identify each of these audio file segments as a *Local Audio Unit* or LAU for short<fnref n="2" />.

LSSs and LAUs can be examined using quantitative or qualitative methods. LAU's analysis can be addressed by several audio feature's extraction algorithms.

An LSS can be examined, quantitatively, by counting the number of sonic resources it employs. For this purpose, we conceived a measurement that we call as the *Weighted Number of sonic Resources* or WNR for short <fnref n="3" />. Finally, an LSS can be examined, qualitatively, by a function we call as *Relative Voicing Complexity* (RVC) which we shall describe in this presentation. The analysis of LSS's and LAU's can be synthesized to obtain a measure of the orchestration's relative complexity. Figure 1 shows a flowchart outlining the overall model.

## 3. THE QUALITATIVE EVALUATION OF MUSICAL TEXTURE

### 3.1. Partitional Analysis

We believe that the organization of sound resources into compound autonomous flows, that is, the orchestral texture, directly influences the dynamics of musical form. The texture is a dimension that characterizes a composer's style and reflects her particular way of negotiating with each instrument uniqueness and their role in stratified sound masses.

In *Structural Functions in Music* [3], Wallace Berry proposes a representation of musical texture based on the interdependency of the sound resources employed in a given musical structure. According to him, the musical texture consists of “real-components” – a part, or voice, that comprises one or more coordinated instruments – which are individualized in the polyphonic totality. Additionally, the sum of the sound resources used in a musical structure would also determine the musical texture.

This reasoning, as well as the numerical representation that it proposes, intersects with some fields of discrete mathematics, especially what is called as the theory of integer partitions[1, 2]. Its origins date back to Euler's work in 1748, and it was adapted to music theory by the Brazilian musicologist Gentil-Nunes [7, 6]. For instance, consider the number 5. It has 18 partitions, that is, 18 ways in which it can be represented as the sum of other integers. It means that if a composer wants to employ up to five sonic resources on a given musical passage, he or she can choose to lay them out into one of 18 combinations of groups and individual parts. Those combinations include all the partitions of the sub-groups as well, as the combinations of four, three and two simultaneous sound resources plus one resource alone. The partitions for a group of up to five sonic resources and its numerical representation are shown in table 1.

<table><caption>**Table 1:** All possible partitions of a *Local Sonic Setup* containing 5 (the sum) sound resources.</caption><tr><td>(5)</td><td>(4 1)</td><td>(3 2)</td><td>(3 1 1)</td><td>(2 2 1)</td><td>(2 1 1 1)</td><td>(1 1 1 1 1)</td></tr><tr><td>(4)</td><td>(3 1)</td><td>(2 2)</td><td>(2 1 1)</td><td>(1 1 1 1)</td><td></td><td></td></tr><tr><td>(3)</td><td>(2 1)</td><td>(1 1 1)</td><td></td><td></td><td></td><td></td></tr><tr><td>(2)</td><td>(1 1)</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>(1)</td><td></td><td></td><td></td><td></td><td></td><td></td></tr></table>

In our model, the partitions of a given group of sonic resources are represented by a list of integers enclosed in parenthesis. In this representation, the most extended list represents the most dispersed, viz. the most complex texture. For instance, consider the list (1 1 1 1 1). It is five elements in length and describes a texture of five sonic resources playing independent parts. This configuration is more complex than, let's say, the configuration represented by the list (2 1 1) whose length is 3 and refer to a texture composed by two resources playing coordinated parts and other two playing independent parts. Each element of such lists represents what is called a real component. The sim-

<footnote n="2">² We have been using AudioSculpt's *Positive Spectral Differencing* to achieve very satisfactory segmentations, which are then fine-tuned to match LSSs.</footnote>

<footnote n="3">³ WNR workings should be detailed in a future paper.</footnote>
<figure><img src="image_82.png" /><figcaption>**Figure 1:** The overall model of our proposal for the computer-assisted analysis of orchestration. In this communication, we introduce the concept of an *Index of Sound Resources* which takes into consideration not only instruments but also their different modes of execution allowing the segmentation of the musical score into *Local Sonic Setups* (LSS). Each of these sonic configurations is analyzed by a qualitative method in terms of heterogeneity of the musical texture.</figcaption></figure>

plest case for a texture of any number of sonic resources is the singleton list (1) that represents a texture comprised of one single solo instrument. Thus, we say that the complexity of texture is a function of its rate of dispersion and the magnitude of its real components.

To calculate the rates of interdependence and independence, denominated bellow as the agglomeration and dispersion rates, respectively, of a given *Local Sonic Setup*, firstly we need to count every combination, or rather every possible relation of any two elements of the LSS. We can do it by referring to the general formula for finding the number of combinations of *p* objects from a set of *n* objects, known as *n* choose *p*,

$$C(n, p) = \frac{n!}{p!(n-p)!} = \frac{n(n-1)(n-2)\dots(n-p+1)}{p!} \quad (1)$$

For instance, in a setup composed of 4 sonic resources playing agglomerated parts, let's say a woodwind quartet, represented by the singleton list (4), there is a total of 6 unique pairs as $C(4, 2) = 6$, that is,

(F1 Ob) (F1 Cl) (F1 Fg) (Ob Cl) (Ob Fg) (Cl Fg).

On the other hand, in an LSS of four soloists playing independent parts, that is (1 1 1 1), when we consider any of its real-components or instruments, we find a total of zero unique pairs as $C(1, 2) = 0$.

We will refer to the total number of unique pairs of any resource or real component of a given setup as $T_2$ or simply $T$. By reworking the equation given at 1, we will define it as a function in the following way:

$$T_2: \mathbb{N}^* \to \mathbb{N} \\ n \mapsto \frac{n(n-1)}{2}. \quad (2)$$

The successive total unique pairs $T_2(n)$ when $n$ is mapped to the first eight positive integers, that is 1, 2...8 is equal to 0, 1, 3, 6, 10, 15, 21, 28.

It follows that, in order to calculate the rate of interdependence, or agglomeration, of a given LSS, we need
to sum the $T_2$ value of each of its components. For instance, the rate of agglomeration of the setup represented by the list (2 1 1) is given by $(T_2(2) + T_2(1) + T_2(1))$ which results in 1. It is formally defined by the following summation function

$$ \mathcal{A}: \mathbb{N}^r \to \mathbb{N} \\ (a_0 \dots a_{r-1}) \mapsto \sum_{i=0}^{r-1} T_2(a_i), \qquad (3) $$

where the list $(a_0 \dots a_{r-1})$ represents an LSS, $a_i$ each of its elements, that is, its real-components, and $r$ the length of the LSS.

We denote the dispersion rate of a given LSS as the difference between $T_2$ value of its sum by its agglomeration rate:

$$ \mathcal{D}: \mathbb{N}^r \to \mathbb{N} \\ (a_0 \dots a_{r-1}) \mapsto T_2(\rho) - \mathcal{A}(a_0 \dots a_{r-1}), \qquad (4) $$

where $\rho$ is the sum, the number of sonic resources of the LSS, that is, $\sum_{i=0}^{r-1} a_i$.

Both functions can be used to form a pair of indices from which graphs can be built and used to visualize the textural dynamics through time. In addition, the rates of dispersion and agglomeration can be combined and then visualized in one single dimension, symbolizing the global tendency of textural qualities, denoted by

$$ \mathcal{I}(a_0 \dots a_{r-1}) = (\mathcal{D} - \mathcal{A})(a_0 \dots a_{r-1}). \qquad (5) $$

In figure 2, the top chart shows the dispersion and agglomeration rates for a section (bars 56–73) of Anton Webern's *Variations for Orchestra, Op. 30*, while the bottom chart displays the overall trend in texture complexity (eq. 5).

## 3.2. Relative Voicing Complexity

To correspond the texture of an LSS with the piece's global sonic design, we propose to calculate “scaled” values for $\mathcal{I}$, where the lower boundary, 0, stands for the less complex texture and the upper limit, 1, the most complex. For now, the solution we are working with is to divide the $\mathcal{I}$ value by the $T_2$ value of the greatest LSS sum$^4$, i.e. the number of sound resources of the most dense LSS of the work, symbolized below by $\rho_{max}$. We denote the ensuing quotient as the *Relative Voicing Complexity* or RVC for short,

$$ \text{RVC}(a_0 \dots a_{r-1}) = \frac{\mathcal{I}(a_0 \dots a_{r-1})}{T_2(\rho_{\max})}. \qquad (6) $$

The RVC value is scaled through the application of $(\cdot) - \min \lambda / \max \lambda$, where $\lambda$ stands for $(a_0 \dots a_{r-1})$.

<figure><img src="image_83.png" /><figcaption>**Figure 2:** Top: agglomeration and dispersion rates for the bars 56 to 73 of Anton Webern's *Variations for Orchestra, Op. 30*. Bottom: Difference between dispersion and agglomeration rates for the same excerpt.</figcaption></figure>

## 3.3. Criteria for the evaluation of dispersion rates

When we identify the local sonic setups, the most common criterion to designate a sound resource as part of a given real-component is the rhythmic coordination between resources. Such criterion follows Wallace Berry's correlation between rhythmic heterogeneity and textural complexity. But we preferred to leave to the choice of the musicologist the parameter or parameters he considers most appropriate, (generally according to the context and the work). We also give the possibility of placing them in hierarchical order by assigning them a more or less significant weight which would correspond to the impact that the parameter has on the dispersion.

This way, in our preliminary analysis of *Variations Op. 30*, besides rhythmic heterogeneity, we considered as a second heterogeneity parameter the tone-color heterogeneity, which is the textural organization into different flows of tonally homogeneous groups, like when we say *strings against brass*. In this particular analysis, tone-color heterogeneity was considered higher in the hierarchy and therefore weighted the calculation of an LSS's dispersion rate towards greater complexity.

There are other parameters that we have experimentally included in our analysis. They include heterophony, heterogeneity of articulation, the heterogeneity of intensity.

Each criterion is mapped to a different positive integer, following the order 1 = strongest to n = weakest. The

<footnote>$^4$Alternatively, the number of total resources used in the musical work, that is, the number of elements of the score's SRI, can be used.</footnote>
RVC value can then be weighted by (·) [(c<sub>max</sub> − c)s + 1], where c stands for the criterion of dispersion and c<sub>max</sub> for the number of criteria. The weighting is further controlled by a percentage, s.

In case of non-dispersion (when all the resources of a setup are aggregated) (no criteria apply), an arbitrary integer, greater than the one corresponding to the total number of criteria adopted, is inserted so that the algorithm understands that the setup has no dispersion.

### 3.4. Structural organization of orchestration's and texture's analytical data

Following the examination of the musical score, the information regarding the orchestration and textural complexity is organized in the form of a multidimensional table. In this format, the temporal succession of LSS's is represented horizontally and labeled, seen on the header row, by their starting points in the form *bar.beat*.

The table's header column refers to the piece's index of sonic resources. Each cell of the table indicates whether the specified sonic resource is employed in the respective LSS. The integer number which fills a cell designates how many simultaneous sounds were allocated for the specified active sound resource.

Other information about the successive LSS's is conveyed in additional rows at the bottom of the table. These include the total number of resources used in the LSS, the weighted number of sound resources, the rates of agglomeration, dispersion, their sum, and so forth. Further supplementary rows may be used to convey additional evaluations given by other functions of the SOAL library. The multidimensional table may be processed with the assistance of spreadsheet software.

## 4. OPENMUSIC IMPLEMENTATION

SOAL, the *Sonic Object Analysis Library* [9], is an Open-Music external library that we continuously develop at the *Musicologia, Sonologia & Computação* group, the Mus3⁵. It is conceived to be useful for a range of analytical purposes and supports a top-down approach.

SOAL's central concept is the *Compound Sonic Unit* or CSU. We define it as the combination and interaction of musical primary and secondary components: the former refers to collections of pitches and the latter to aspects as intensities, ranges, registers, densities and so forth. We also recognize as secondary components statistical measurements such as distributions, deviations, and entropy, among others.

SOAL is modular; new ad-hoc functions and components can be easily incorporated into the library. SOAL allows the inference of musical structures by comparing the relative sonic qualities of a sequence of CSU's and ultimately symbolizing them by a *vector of relative complexity*.

<table><caption>**Table 2:** Structured data from orchestration and textural analysis of Anton Webern's *Variations for Orchestra, Op. 30. Header column* refers to the SRI of the work, while the *header row* indicates the bar numbers.</caption><thead><tr><th></th><th>56</th><th>58</th><th>59</th><th>60</th><th>62</th><th>63</th><th>65</th></tr></thead><tbody><tr><td>Fl</td><td>1</td><td></td><td></td><td></td><td></td><td>1</td><td>1</td></tr><tr><td>Fl flatterzung</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Ob</td><td>1</td><td></td><td></td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Cl[Bb]</td><td>1</td><td></td><td></td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Bcl</td><td></td><td></td><td></td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Hn[F]</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Hn[F] sord.</td><td>1</td><td>1</td><td></td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Tpt[C]</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Tpt[C] sord.</td><td>1</td><td>1</td><td></td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Tbn</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Tbn sord.</td><td>1</td><td>1</td><td></td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Tba</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Tba sord.</td><td></td><td></td><td></td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><td>Cel</td><td></td><td></td><td></td><td></td><td>4</td><td></td><td></td></tr><tr><td>Hp</td><td></td><td>4</td><td></td><td></td><td>4</td><td></td><td></td></tr><tr><td>Hp harm.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Timp</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Timp trill</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Vn 1 solo arco</td><td></td><td>1</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Vn 1 solo pizz.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Vn 1 solo pizz. sord.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Vn 1 div. pizz.</td><td></td><td></td><td></td><td></td><td></td><td>1</td><td></td></tr><tr><td>Vn 1 tutti arco</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Vn 1 tutti sord.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Vn 1 tutti harm.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Vn 1 tutti pizz.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Vn 1 tutti pizz. sord.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>[etc.]</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Db pizz.</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Total resources</td><td>9</td><td>5</td><td>3</td><td>8</td><td>2</td><td>16</td><td>8</td></tr><tr><td>WNR</td><td>.67</td><td>.49</td><td>.34</td><td>.64</td><td>.21</td><td>.85</td><td>.64</td></tr><tr><td>Agglomeration</td><td>9</td><td>3</td><td>3</td><td>12</td><td>0</td><td>24</td><td>12</td></tr><tr><td>Dispersion</td><td>27</td><td>7</td><td>0</td><td>16</td><td>1</td><td>96</td><td>16</td></tr><tr><td>Difference</td><td>18</td><td>4</td><td>-3</td><td>4</td><td>1</td><td>72</td><td>4</td></tr><tr><td>Setup Complexity</td><td>.9</td><td>.52</td><td>.33</td><td>.69</td><td>.21</td><td>1</td><td>.69</td></tr></tbody></table>

The analysis of the *Relative Voicing Complexity* is, thus, one more option in the collection of functions for top-down music analysis. Indeed, an LSS is a CSU described by its sonic or instrumental configuration.

As with every other OpenMusic library, SOAL's functions are organized by purpose in different folders. SOAL's folder partitional analysis includes the function *soal-texture-complexity* which proposes an assisted-analysis of musical texture according to the premises exposed earlier in this presentation.

Figure 3 shows an OpenMusic patch as typically programmed for use with *soal-texture-complexity*. The list connected to the leftmost input of the function refers to the sequence of LSS's in the form ((partition) (criterion)). The list of bar numbers is inserted in the 5th input (from left to right). Other arguments include the list of total sound resources per LSS and the total number of dispersion criteria (cf. section 3.3).

The figure also highlights some of the function's outputs

<footnote n="5">⁵ The library can be downloaded at http://git.nics.unicamp.br/mus3-OM/soal4/tags</footnote>
<figure><img src="image_84.png" /><figcaption>**Figure 3:** OpenMusic patch with the soal-texture-complexity function prototype in use to analyze bars 56–82 of Anton Webern’s *Variations for Orchestra, Op. 30*.</figcaption></figure>

such as:

1. the weighted number of resources, WNR, $\frac{\log \rho}{\log \rho_{\max}}$;

2. the number of real components, *r*;

3. the list of agglomeration rates, eq. 3;

4. the list of dispersion rates, eq. 4;

5. the list of differences between dispersion and agglomeration rates, eq. 5;

6. the relative setup complexity<fnref n="6" />, WNR($RVC_w + 1$);

7. The LSSs list, labeled by bar number, sorted from the most complex to the less complex.

Figure 4 shows an example of the kind of results our approach can produce. It depicts the analysis made on an excerpt from Beethoven’s *5th symphony*, more precisely, the last bars of the 3rd movement together with the *attacca* which opens the finale. Even though not surprising, the analysis indicates that the finale’s opening tutti - the place where all the expanded orchestra’s resources are ultimately activated - correspond to the less complex texture of the excerpt, as practically all instruments play in homophony. The homophony explains why the last bar of the chart is so flat (cf. bar 242), even though the music reaches, at that moment, its most thrilling point, one could say.

## 5. CONCLUSIONS

Our experimental model for computer-assisted analysis proposes a formal strategy for evaluating the role of orchestration in musical structure and perception. It works by

<figure><img src="image_85.png" /><figcaption>**Figure 4:** A sample of a scaled and weighted RVC analysis: Beethoven, *5th Symphony*, third movement, bars 237-371 plus first bars of *Finale*.</figcaption></figure>

looking at the symbolic level of the score’s prescriptions and the “perceptual level” of the performed music. At the symbolic level, the musical texture is considered as a qualitative aspect of orchestration, whereas the number of sonic resources involved in each local setup is the qualitative aspect. The analysis we put forward makes use of an application of the theory of partitions. We described how to collect and format (section 3.4) data from the score, its mathematical background (section 3.1), how the implemented function works (section 4), and the kind of results it may return (figures 2, 4 and table 2).

Nevertheless, there is still a great deal of research to do for the completion of the project as exposed in figure 1. For instance, the audio branch of our model (right side of figure 1) is at a very incipient stage: choosing, importing, developing and implementing appropriate descriptors is not a trivial task and demand further extensive research and

<footnote n="6">⁶ The RVC weight onto WNR can be adjusted by the user</footnote>
experiments. Furthermore, the impact of an LSS' duration upon the overall musical perception should be properly addressed in the next stages of our work.

Some aspects of orchestration are omitted in our model, such as the impact of polyphonic resources (e.g., a piano) playing agglomerated sounds (e.g., chords) in an overall dispersed texture. We are inclined to think such behavior works against the global sensation of dispersion, but we have no data, at the moment, that could help us to quantify to which extent this occurs.

In a more technical note, soal-texture-complexity should be able to incorporate a (semi)-automated tool for analyzing and structuring data as presented in table 2. Pattern recognition of texture or instrumental configurations in a single work, in a composer's whole oeuvre, or for some historical period, could bring a relevant complementary analysis. Such devices would significantly reduce the fasτidious manual labor involved in the process. In fine, soal-texture-complexity, and the library as a whole should be implemented as stand-alone software in future works.

In any case, based on our first experimental results, we are quite confident that this approach consists of a helpful contribution in the field of computer-assisted music analysis.

## 6. REFERENCES

[1] Andrews, G. *The theory of partitions*. Cambridge University Press, 1984.

[2] Andrews, G. & Eriksson, K. *Integer Partitions*. Cambridge University Press, 2004.

[3] Berry, W. *Structural functions in music*. Dover, New York, 1987.

[4] Bresson, J, Agon, C., Assayag, G. "OpenMusic: visual programming environment for music composition, analysis and research." In *Proceedings of the 19th ACM international conference on Multimedia*, pp. 743-746. Scottsdale, USA, 2011.

[5] Cogan, R. & Escot, P. *Sonic Design: The Nature Of Sound And Music*. Prentice-Hall, New Jersey, 1976.

[6] Gentil-Nunes, P. *Análise particional: uma mediação entre composição musical e a teoria das partições*. PhD thesis. Universidade Federal do Estado do Rio de Janeiro, 2009.

[7] Gentil-Nunes, P. & Carvalho, A. "Densidade e linearidade na configuração de texturas musicais". *Proceedings of IV Colóquio de Pesquisa do Programa de Pós-Graduação da Escola de Música da UFRJ*. Rio de Janeiro: UFRJ, 2003.

[8] Gieseler, W., Lombardi, L., Weyer, R. D. *Instrumentation in der Musik des 20. Jahrhunderts*. Moeck Verlag, Celle, 1985.

[9] Guigue, D. *Sonic Object Analysis Library – OpenMusic Tools For Analyzing Musical Objects Structure*. 2016. http://www.ccta.ufpb.br/Mus3.

[10] Koechlin, C. *Traité de l'Orchestration*. Max Eschig, Paris, 1954.

[11] Piston, W. *Orchestration*. Norton, New York, 1969 [1955].