# ENSEIGNER LE PATCHING DE MANIÈRE COLLECTIVE AVEC LE LOGICIEL COLLABORATIF KIWI

Philippe Galleron

CICM - EA1572 Musidanse
Université Paris 8

philippe.galleron@gmail.com

Eric Maestri

CICM - EA1572 Musidanse
Université Paris 8

eric.maestri@gmail.com

Jean Millot

CICM - EA1572
Musidanse

Université Paris 8

jean.millot7@gmail.com

Alain Bonardi

CICM - EA1572
Musidanse

Université Paris 8

alain.bonardi@gmail.com

Eliott Paris

CICM - EA1572
Musidanse

Université Paris 8

eliott.paris@gmail.com

## RÉSUMÉ

Les pratiques musicales collaboratives fondées sur le traitement temps réel du son à des fins de composition musicale constituent un nouvel enjeu en matière de pédagogie musicale. Notre équipe du CICM <fnref n="1" /> s'est engagée dans une recherche-action dans le cadre du projet ANR <fnref n="2" /> Musicoll <fnref n="3" /> pour essayer de mieux comprendre les enjeux des pratiques collaboratives dans le *patching* <fnref n="4" />. Cette réflexion a été menée autour du développement d'un logiciel de *patching* collaboratif appelé *Kiwi*. Ce logiciel est le produit de la réflexion sur la pratique du *patching* et est refaçonné par les retours d'expérience dans le cadre de la pratique artistique et pédagogique. Cet article resitue brièvement les phases de développement du projet et apporte un éclairage sur les acteurs de l'équipe de recherche et leur façon de collaborer. Il traite ensuite plus spécifiquement de l'orientation pédagogique retenue dans la conception du cours de *patching* avec le logiciel collaboratif *Kiwi*. Nous soulignons les aspects pédagogiques innovants et la possible reconfiguration de l'enseignement du *patching* avec les possibilités d'interactions de ce nouveau logiciel. Notre réflexion porte sur l'utilisation de cet environnement numérique dans le contexte d'un cours universitaire de Licence 2 (L2) donné en présentiel dans la mineure CAO <fnref n="5" /> au sein du département Musique de l'Université Paris 8. Nous abordons les stratégies d'enseignement, les scénarios de pré-implémentation conçus par les auteurs du cours et leur mise en œuvre pendant le second semestre de l'année universitaire 2017-2018. Nous traiterons du *design* pédagogique pour refondre le cours de *patching*, l'impact attendu sur l'apprentissage et les scénarios pédagogiques mis en œuvre. Enfin nous aborderons l'analyse d'un cas réel

constitué par une séance de test effectuée en décembre 2017 avec des étudiants de L3. Cette séance a permis d'éprouver la stabilité du logiciel en conditions réelles durant un cours et nous a permis de « patcher » de manière collaborative avec la classe.

# 1. INTRODUCTION

## 1.1. La raison de l'article

Cet article est un compte-rendu d'étape du processus d'implémentation dans un cours universitaire du nouveau logiciel de *patching* collaboratif nommé *Kiwi*. Il est rédigé selon une manière collaborative par les membres de l'équipe du CICM à l'image des méthodes de travail en cours au laboratoire.

Il s'est écoulé un demi-semestre entre la première version de cet article en décembre 2017 qui était une pré-implémentation du logiciel en classe et avril 2018 où nous en sommes à la 6e séance d'enseignement du *patching* avec *Kiwi*.

L'équipe se définissant volontiers elle-même comme une communauté de pratique (au sens de Wenger [12]) de la composition musicale constituée d'enseignants-chercheurs et de leurs étudiants. L'ensemble des membres de l'équipe sont des « patcheurs » utilisant les logiciels Max et/ou Pure Data et des compositeurs maîtrisant l'informatique musicale en temps réel. Quatre des auteurs ont enseigné ou enseignent l'introduction au *patching* sur ces logiciels.

Le professeur du cours, le responsable pédagogique, le *designer* pédagogique et les développeurs de *Kiwi* font un suivi hebdomadaire de l'enseignement du cours de *patching* sur *Kiwi*. Les séances débutent par un retour

<footnote n="1">¹ Centre de Recherche en Informatique et Création Musicale</footnote>

<footnote n="2">² L'Agence Nationale de la Recherche</footnote>

<footnote n="3">³ Musicoll : MUSique COLlaborative temps réel et nomade, projet ANR (2016-2018) associant le CICM et l'entreprise OHMFORCE.</footnote>

<footnote n="4">⁴ Programmation graphique musicale</footnote>

<footnote n="5">⁵ Composition Assistée par Ordinateur.</footnote>
d'expérience mis en commun. Ces retours alimentent les évolutions du logiciel qui à leur tour influent sur la pédagogie (Figure 1).

<figure><img src="image_86.png" /><figcaption>**Figure 1** : Cycle du développement technico-pédagogique du projet Musicoll.</figcaption></figure>

## 1.2. Le *patching* collaboratif avec Kiwi

Kiwi est un logiciel de *patching* numérique dans la lignée de *Max* et *Pure Data*. Les spécifications techniques de ce logiciel du point du vue du développement ayant été publiées aux JIM 2017 [5], nous renvoyons le lecteur à ce texte.

Les programmes *Max* et *Pure Data* sont largement utilisés de nos jours et constituent une référence dans la pratique de la musique mixte ainsi que par ailleurs pour la pédagogie de l'informatique musicale. Cependant, ils ne sont pas conçus dans une optique de partage créatif et pédagogique. A l'opposé, le logiciel *Kiwi* que nous avons conçu au CICM dans le cadre du projet ANR Musicoll (2015-2018) développe cette pratique en permettant l'interaction entre les programmeurs sur le même *patch*.

L'élaboration du logiciel *Kiwi* est une réponse à un double constat, le premier porte sur les limites de la modalité unique d'enseignement du *patching* et le second est relatif à la pratique du *patching* qui est jusqu'à présent plutôt individuelle et solitaire derrière son propre ordinateur. C'est précisément sur cette tension entre un enseignement musical collectif et une pratique solitaire que le développement de ce logiciel vient agir.

L'enseignement des logiciels de *patching* est habituellement caractérisé par une approche frontale dans laquelle la relation entre l'enseignant et la classe est de type vertical : l'enseignant transmet son savoir et sa propre manière d'utiliser les logiciels, d'une manière hiérarchique descendante. D'ailleurs, l'expérience acquise dans l'enseignement en interne à Paris 8 des

environnements de *patching* confirme cette perspective. En effet, la phase d'analyse <fnref n="6" /> du cours existant a mis en évidence que lors des cours de *patching*, les professeurs, chacun avec leurs propres conceptions et leurs critères, restent fidèles à ce modèle de transmission du savoir [3]. Cette stratégie d'enseignement exploite les caractères des environnements existants, qui favorisent ce type de transmission à cause de leur structure, laquelle ne permet pas des modalités collaboratives. En effet, si la pratique de l'enseignement du *patching* à Paris 8 se fait en classe de manière collective, la pratique du *patching* ne l'est pas à proprement parler.

Par analogie, si nous devions le comparer à une pratique collective instrumentale, le geste de programmation n'est pas directement apparent, le son produit non plus car l'interaction visuelle et sonore n'est pas immédiate. Il faut donc un processus relativement long entre la programmation sur sa machine et l'obtention des premiers résultats sonores que l'on peut partager avec les autres. D'autre part, partager l'architecture d'un *patch* demande soit de transmettre le fichier d'une machine à l'autre, ce qui demande un temps d'analyse à celui qui le découvre *a posteriori*, soit de partager un visuel sur un écran, ce qui permet d'explorer dynamiquement les ressources du *patch* mais n'en donne qu'un aperçu. De fait, l'interaction tant visuelle que sonore est fortement différée ; on comprend aisément alors que ce type de pratique musicale ne se prête que peu au collectif.

Or, ce manque d'interactions dans les échanges se ressent également dans l'enseignement du *patching* et a des conséquences sur l'apprentissage. En effet, dans les sciences de l'éducation, les approches socio-constructivistes inspirées des travaux de Lev Vygostky [11] montrent l'importance des interactions dans le processus d'apprentissage qu'elles soient symétriques (entre étudiants) ou asymétriques c'est-à-dire de participant avancé à moins avancé (par exemple entre professeur et étudiants). C'est pourquoi le développement d'un logiciel collaboratif dans ce domaine apporte des changements dans la pratique car elle peut se réaliser collectivement. Les délais de partage sont réduits et offrent des opportunités nouvelles en termes d'enseignement, notamment une approche de la transmission plus horizontale qui nous conduit assez naturellement à une approche collaborative. Notre approche peut faire penser au domaine du *Computer supported collaborative learning* (CSCL) qui « est une branche des sciences de l'éducation qui s'intéresse à l'étude de la façon dont les gens peuvent apprendre ensemble avec l'aide des ordinateurs » <fnref n="7" /> [8].

Par ailleurs notre équipe concilie des méthodes et points de vue pédagogiques complexes comme on le retrouve dans les CSCL qui considèrent des conceptions opposées de l'enseignement [8] comme [notre traduction] :

<footnote n="6">⁶ Selon les phases du modèle d'instructional development ADDIE (analysis, design, development, implementation, evaluation).</footnote>

<footnote n="7">⁷ « branch of the learning sciences concerned with studying how people can learn together with the help of computers ».</footnote>
- la métaphore de l'acquisition « dans laquelle l'apprentissage consiste en l'acquisition de connaissances stockées dans l'esprit »<fnref n="8" />

- la métaphore de la participation « dans laquelle l'apprentissage consiste en une participation croissante aux communautés de pratique »<fnref n="9" />

- la métaphore de la création des connaissances qui « sont créées [...] grâce à la collaboration »<fnref n="10" />.

Enfin notre méthodologie de recherche comme dans les CSCL combine des approches « de conception expérimentale, descriptive et itérative »<fnref n="11" /> [8].

Toutefois nous devons bien signifier que *Kiwi* n'est pas à ce stade pensé comme un dispositif d'apprentissage en ligne, ni pour faciliter l'apprentissage de la musique à l'aide d'un ordinateur. Il est enseigné et pratiqué en présentiel. Il participe à l'apprentissage de l'audionumérique tout en apprenant le *patching* à des fins de création musicale. Pour cela il est conçu pour développer un enseignement et une pratique musicale collaborative.

Dans cet article, nous discuterons comment au CICM nous élaborons des stratégies d'enseignement de la programmation musicale suite à l'introduction du logiciel musical collaboratif Kiwi dans l'offre de formation en informatique et création musicale au sein du Département de musique de l'Université Paris 8. Nous traiterons particulièrement du design pédagogique et de l'impact de ce nouveau moyen technologique sur la refonte du cours « Introduction au patching avec Max et Pure Data ». Pour aborder ces sujets, le texte suivant s'articule en quatre parties. Premièrement, il présente de manière succincte le projet de réalisation du logiciel de patching collaboratif Kiwi mené dans le cadre du projet Musicoll (§ 2) ; deuxièmement, il discute le design pédagogique dans sa phase de pré-implémentation (§ 3-4) ; troisièmement, il propose un scénario-type ainsi que le déroulement d'une séance de cours (§ 5-6) ; enfin, les auteurs font un retour d'expérience d'une séance de test logiciel dans laquelle ils ont pu réaliser des patches en collaboratif pour la première fois avec les étudiants et évaluer la robustesse de Kiwi en situation réelle (§ 7).

## 2. LE PROJET MUSICOLL : KIWI

L'idée du développement d'un projet de recherche sur la programmation collaborative découle de l'observation des environnements de traitement du signal en temps réel existants, du constat de leurs limites en termes d'interactions collaboratives entre utilisateurs-programmeurs et de la pratique de Max et Pure Data dans

le cadre de l'enseignement musical à l'Université Paris 8. A partir de l'analyse du cadre de ces pratiques, les chercheurs de l'équipe-projet Musicoll ont conçu un nouveau logiciel de patching<fnref n="12" /> appelé Kiwi. Ces chercheurs souhaitent :

- développer un environnement numérique audio collaboratif pour le traitement du signal en temps réel;

- étudier son utilisation par les musiciens-compositeurs ;

- renouveler l'enseignement des logiciels en temps réel en refondant le cours de Max et Pure Data dans le cadre de la mineure « Composition Assistée par Ordinateur » en Licence 2 au Département Musique de l'Université Paris 8.

Kiwi propose un environnement similaire à celui des programmes existants. La figure 1 exemplifie cet environnement dans laquelle, à la manière de Max et Pure Data, dans laquelle des modules, qu'on appelle « objets », sont connectés <fnref n="13" />. [adc~] donne accès au signal d'entrée audio, [delaysimple~] correspond à un retard avec réinjection du même signal, tandis que [dac~] est la sortie audio ; [*~] permet de contrôler l'amplitude du signal et les objets [*] mettent à l'échelle les valeurs des curseurs pour régler les paramètres de retard et réinjection correspondants (Figure 1). A la différence, dans Kiwi un tel patch peut être modifié par tous les utilisateurs y ayant accès.

<figure><img src="image_87.png" /><figcaption>Figure 2. Patch Kiwi appliquant un retard avec réinjection et un gain sur un signal audio.</figcaption></figure>

<footnote n="8">⁸ « in which learning consists of individuals acquiring knowledge stored in their minds ».</footnote>

<footnote n="9">⁹ « in which learning consists of increasing participation in communities of practice ».</footnote>

<footnote n="10">¹⁰ « in which new knowledge objects or social practices are created [...] through collaboration ».</footnote>

<footnote n="11">¹¹ « Research methodology in CSCL is largely trichotomized between experimental, descriptive and iterative design approaches. Although sometimes combined within a single research project, the methodologies are even then typically kept separate in companion studies or separate</footnote>

<footnote>analyses of a single study. Different researchers sometimes wear different hats on the same project, representing different research interests and methodologies ».</footnote>

<footnote n="12">¹² Le terme *patching* décrit l'action de programmation de traitements sonores dans des environnements graphiques comme *Kiwi* ; de manière très simplifiée il s'agit de connecter des boîtes représentant des traitements avec des câbles virtuels.</footnote>

<footnote n="13">¹³ Par convention les objets sont écrits entre crochets ; le « ~ » signifie un objet qui traite un signal audionumérique par opposition à ceux qui traitent les données de contrôle.</footnote>
### 3. CONCEPTUALISER L'ENSEIGNEMENT DU PATCHING COLLECTIF AU MOYEN D'UN NOUVEAU DESIGN PEDAGOGIQUE

L'un des principaux objectifs du projet Musicoll est de repenser et renouveler l'enseignement de l'interaction musicale en temps réel au service de la composition. Les enseignants et leurs étudiants sont associés dans la conception de nouvelles stratégies pour apprendre à « patcher » de manière collaborative.

L'esprit qui guide la conception pédagogique de ce cours se fonde sur l'acquis d'expérience suivant : la qualité et la rapidité de l'apprentissage semble être favorisée par le partage des travaux et des outils logiciels par la communauté des étudiants. En effet, nous pensons que les interactions dans la classe qui peuvent être symétriques – comme par exemple la co-résolution entre pairs – ou asymétriques – comme par exemple professeur-étudiants et expert-novices – « interviennent intrinsèquement dans la mise en œuvre des activités cognitives résolutoires et dans [la] genèse des processus intra-individuels de développement des compétences » [7]. La conception pédagogique que nous proposons est en cohérence avec ce propos. Il s'agit d'une approche de type socio-constructiviste considérant dans notre cadre d'enseignement que les interactions sociales autour de cette pratique musicale génèrent des conflits cognitifs qui sont une source d'apprentissage. Pour tirer parti de ce nouveau logiciel aux possibilités d'interactions sociales étendues, nous avons pour cela choisi de re-designer le cours visant tout d'abord à redéfinir ses objectifs, les outils et les scénarios pédagogiques pour l'enseignement de la programmation musicale temps réel.

## 4. PORTAGE DES OBJECTIFS PÉDAGOGIQUES DANS UN NOUVEL ENVIRONNEMENT

### 4.1. Anticipation des changements occasionnés

Un des objectifs que nous nous sommes fixés dans cette refonte est de renforcer au sein du cours le savoir-apprendre et le savoir-travailler de manière collaborative afin de montrer aux étudiants une manière alternative d'apprendre, de travailler et de créer. Une telle approche de l'apprentissage numérique collaboratif offre une contribution concrète à la transformation des pratiques pédagogiques [9]. Ces compétences sont considérées comme essentielles pour l'avenir du travail et de l'enseignement, comme le souligne l'organisation Partnership for 21st Century Learning (P21) [6]. Par ailleurs, l'actualité de cette approche est en phase avec des projets de création récents. Grâce aux développements des technologies numériques de partage des données, les pratiques musicales et artistiques évoluent fortement dans le sens du collaboratif en questionnant le statut traditionnel du compositeur,

comme nous avons pu le constater directement [1]<fnref n="14" />. Grâce à des ajustements collaboratifs dans leur façon de « patcher », les étudiants devraient apprendre à définir des règles de partage et aussi de workflow commun tout en construisant leur environnement de programmation audionumérique et leur espace de travail pour l'intégrer de manière cohérente à leur propre pratique musicale.

A travers le design pédagogique de ce nouveau cours, nous essayons d'anticiper l'impact que pourrait avoir Kiwi sur le professeur et sa stratégie d'enseignement du patching. D'autre part, avant la véritable mise en place qui a eu lieu à partir du deuxième semestre de l'année universitaire 2017-18, nous essayons d'entrevoir les effets sur les étudiants de cette nouvelle forme d'interaction visuelle informelle entre les membres du groupe des étudiants qui n'existait pas dans le cours jusqu'à présent. En effet, l'enseignement du patching dans l'ancien cours était généralement composé de deux étapes. Tout d'abord, chaque étudiant préparait son patch en local sur son ordinateur puis le partageait sous la forme d'un fichier pouvant être dupliqué et ouvert sur d'autres machines. Chaque duplicata du patch étant une version indépendante dont les modifications ultérieures étaient propres à chaque étudiant. Cette collaboration asynchrone impliquait une phase solitaire de réalisation, puis des phases de partage et de retour d'expérience multiples.

Le logiciel Kiwi introduit au sein du cours permet quant à lui une collaboration synchrone et collective en programmation musicale. Cette pratique synchrone est fondée sur un document unique partagé et hébergé par un serveur, localement ou sur internet, accessible et éditable par chaque utilisateur du réseau sans aucune autorisation des autres utilisateurs. Les étudiants sont par conséquent invités dans cette nouvelle situation à assumer pleinement une position de connaissance partagée. Ils sont de fait dans une petite communauté musicale au sein de laquelle ils communiquent des stratégies de partage d'objets numériques et renforcent ainsi l'apprentissage réciproque dans et à travers leur utilisation. Par conséquent, la migration d'un mode de programmation musicale essentiellement solitaire à un autre collectif, dès la création du patch, implique des changements qui ont des répercussions sur la pédagogie de la création musicale. La question est alors d'enseigner et de se « former à et par la collaboration numérique » [2].

Dans le tableau (Tableau 1), nous soulignons les transpositions qui vont s'opérer entre notre expérience pédagogique de l'ancien cours et la projection que nous en avions. Puisqu'il s'agit d'une refonte de l'ancien cours de Max et Pure Data, les professeurs chargés de ce cours s'appuient sur leur savoir-faire existant en matière d'enseignement du patching afin de le faire évoluer. Nous souhaitons donc que les étudiants relient le patching aux questions de composition musicale et en outre développent de manière accrue leurs compétences

<footnote n="14">¹⁴ L'un des auteurs du présent article, Eric Maestri, a pu expérimenter un projet de composition collective avec le collectif de compositeurs</footnote>

<footnote>italiens /nu/thing, dont une grande partie s'est déroulée à distance grâce à ces outils.</footnote>
en termes de collaboration : le partage implique des normes de politesse dans la construction du document, des contacts fréquents, de la motivation personnelle et de l'auto-apprentissage.

<table><caption>**Tableau 1** : Modification de l'environnement d'apprentissage des participants du cours de *patching*.</caption><thead><tr><td>Programmer avec Max ou Pd</td><td>Programmer avec Kiwi</td></tr></thead><tbody><tr><td>Espace de travail numérique individuel</td><td>Espace de travail numérique partagé</td></tr><tr><td>Partage asynchrone (par exemple par mail ou sur un cloud)</td><td>Partage synchrone sur le même document de travail</td></tr><tr><td>Mode collaboratif en présentiel</td><td>Mode collaboratif en présentiel dans la classe et/ou en ligne</td></tr><tr><td>Un espace de travail visible uniquement à proximité du poste de travail</td><td>Un espace de travail visible à distance</td></tr><tr><td>Travail sur le même patch limité à 3-4 étudiants (derrière le même ordinateur)</td><td>Travail sur le même patch (théoriquement) illimité</td></tr></tbody></table>

## 4.2. Évaluation du dispositif

### 4.2.1. Évaluation des étudiants

Pour évaluer les étudiants, nous procédons à trois évaluations individuelles et sommatives par questionnaires sur le *Moodle* du cours. La première précède le cours et nous permet d'évaluer le niveau de connaissances des étudiants en audionumérique. La seconde à mi-semestre et la troisième à la fin du semestre portent sur le fonctionnement des objets de *Kiwi* et leurs connexions.

Par ailleurs nous mettons en place un travail artistique qui nous permet d'évaluer chaque groupe. Il s'agit d'un format de type « concert » dans lequel les groupes doivent présenter une petite pièce musicale mettant en œuvre un ou plusieurs procédés appris dans *Kiwi* (traitements, synthèse et transmission de données de contrôle). Les étudiants devront exprimer à l'oral ce qui est en œuvre dans leur patch. Ils devront à l'issue de cette démonstration fournir à la communauté leur patch accompagné d'un document explicitant sa prise en main et leur intention artistique et technique.

### 4.2.2. Évaluation de l'impact de l'environnement collaboratif sur le cours

Concernant l'évaluation scientifique des effets de l'introduction du collaboratif dans le cours de *patching* nous procédons en deux étapes :

- des enregistrements vidéo de la classe en activité et du professeur faisant un retour sur chaque séance.

- des entretiens filmés appelés d'« autoconfrontation »<fnref n="15" /> et de « remise en situation par les traces matérielles »<fnref n="16" />.

Nous nous inspirons de la méthodologie de recherche empirique dite « du cours d'action » [10]. C'est une manière de favoriser l'expression des acteurs sur leur sujet et ainsi enrichir l'analyse de leur activité. Nous pourrons par exemple déceler chez les participants des modifications de leur savoir-être ou préciser leur implication dans l'activité de groupe. Pour réunir des traces de leur activité les étudiants ayant donné leur accord sont filmés ; des captures vidéo de leur écran durant le cours sont collectées.

### 4.2.3. L'influence du design et de ses limites

Le design pédagogique tel que nous le pratiquons dans le projet Musicoll procède par allers-retours entre projection et réalisation. Les propositions d'innovations pédagogiques lors de la refonte d'un cours tant sur les méthodes que sur les contenus doivent être validées par l'ensemble des acteurs.

A la fin du semestre nous allons d'une part comparer ce qui était prescrit avec ce qui a été réalisé, d'autres part mesurer ce qui a été transmis. Pour cela nous procéderons

<footnote n="15">¹⁵ Concrètement le participant est filmé en commentant les vidéos de lui-même en pleine activité.</footnote>

<footnote n="16">¹⁶ Le participant est amené à s'exprimer à partir des documents de travail qu'il a générés (p. ex. *patchs*, pièces).</footnote>
à l'analyse par la *Method for Analysing and Structuring Knowledge* (MASK)<fnref n="17" /> du cours préparé par le professeur, ce qui nous permettra de dégager les *savoirs*, *savoir-faire* et *savoir-être* en jeu dans la mise en activité des étudiants.

Puis nous comparerons cette somme de connaissances supposées avec les résultats des évaluations des étudiants et l'analyse des entretiens d'autoconfrontation.

Enfin nous comparons ces résultats avec ceux obtenus l'année précédente dans le cours « Introduction à la programmation avec Max et Pure Data ».

Ces données d'analyse nous permettrons à terme de dresser une évaluation qualitative sur les compétences développées par les étudiants en terme *patching* et de collaboration.

## 5. RÉSULTAT DE L'ANALYSE DU CONTEXTE D'ENSEIGNEMENT : UN PREMIER SCÉNARIO-TYPE

Les cours de *patching* du second semestre 2018 sont conçus comme des séances d'apprentissage en présentiel, même si, à court terme, nous envisageons un modèle d'apprentissage mixte, combinant l'apprentissage en présentiel et à distance sur la plateforme pédagogique Moodle de l'Université Paris 8. Le scénario exposé ici est essentiellement pour un cours en présentiel, mais nous incitons les étudiants à ce que ces situations d'apprentissage avec *Kiwi* prennent appui sur leur propre pratique de création musicale en dehors du cours. Ce travail de fond sera valorisé en classe et constituera l'un des supports de cours utilisé par le professeur.

C'est pourquoi nous suggérons donc aux étudiants de pratiquer *Kiwi* afin de :

- programmer régulièrement des traitements à distance sur un *patch* partagé connecté au serveur internet de l'application (ce travail doit se faire au minimum en binôme),

- de faire appel en cas de blocage sur le *patch* à l'aide d'un tiers (l'enseignant ou un étudiant plus avancé) pour déboguer leur *patch*,

- de documentariser <fnref n="18" /> [4] leur *patch*, c'est-à-dire d'y ajouter des métadonnées, par exemple écrire un chapeau sur l'objet de leur *patch* ou constituer un petit document d'aide à sa prise en main.

## 6. DÉROULEMENT D'UNE SESSION-TYPE DE TRAVAIL COLLABORATIF SUR UN PATCH ORIGINAL PRODUIT PAR UN ÉTUDIANT

La session commence avec la correction des devoirs des étudiants. A partir d'un travail réalisé par un groupe d'étudiants (par exemple une pièce pour instrument électronique avec traitements en temps réel dans *Kiwi*), le professeur propose une activité collaborative autour d'un problème technique ou musical, identifié comme

pertinent dans le *patch* présenté, par exemple l'utilisation d'un *delay* ou d'une enveloppe d'amplitude. Ensuite, le professeur invite le groupe d'étudiants à produire un *patch* en collaboration. Les bénéfices attendus sont les suivants :

- une autonomie accrue des étudiants dans la réalisation de leur *patch*,

- l'intégration des principes de la musique par ordinateur et la capacité de construire un discours autour de leur propre problématique musicale,

- être capable d'exprimer son approche musicale et compositionnelle avec un vocabulaire pertinent et spécifique au *patching* collaboratif,

- l'émergence, par cette situation collective, de l'émulation favorable également à l'apprentissage individuel.

Nous projetons un déroulement de la séance de la manière suivante :

1. Une introduction de la problématique du cours par l'enseignant depuis son bureau sur le tableau, en situation frontale vis-à-vis des étudiants. L'enseignant explique les bénéfices qu'il attend du cours et exprime explicitement qu'il est attentif à la formulation des idées sous-jacentes au *patch*.

2. Les étudiants procèdent à une présentation en groupe de leurs travaux de *patching*. Chaque groupe partage ses progrès, ses difficultés et ses projections pour améliorer son *patch*. Les autres étudiants peuvent les rejoindre sur leur document *Kiwi* pour suivre visuellement leurs explications. Ce moment est suivi d'échanges verbaux et d'interactions sur le logiciel entre les étudiants.

3. A partir de ce *patch* original présenté par leurs pairs, chaque groupe connecté au réseau *Kiwi* crée une copie du document partagé original (par exemple le groupe 1 crée le document 1 et le groupe 2, le document 2 *etc.*) et les étudiants s'approprient ainsi le *patch* du groupe à partir de leur propre ordinateur. L'enseignant lui se déplace de groupe en groupe et participe aux échanges verbaux et soutient la réflexion des élèves.

4. Chaque groupe propose une solution possible pour développer le *patch* et il s'ensuit un moment de discussion sur cette solution. Cela conduit à une co-assignation des tâches par groupe et au sein de chaque groupe.

5. Chaque groupe joue ses *patches* pour les expliquer. Pour cela le groupe présente son *patch* de manière orale et visuelle (via *Kiwi*) avec les autres groupes pour discuter de leur processus de *patching* et réaliser une auto-évaluation de celui-ci. Les solutions valides sont alors fusionnées dans le *patch* d'origine et/ou constitueront, pour la classe, un répertoire de pratique pouvant être mobilisé immédiatement au besoin à partir du serveur.

<footnote n="17">¹⁷ La méthode MASK est une méthode de capitalisation, d'analyse et de structuration des connaissances.</footnote>

<footnote n="18">¹⁸ Documentariser selon Manuel Zacklad consiste à doter les documents « d'attributs spécifiques permettant de faciliter (i) leur gestion parmi</footnote>

<footnote>d'autres supports, (ii) leur manipulation physique, condition d'une navigation sémantique à l'intérieur du contenu sémiotique et enfin, (iii) l'orientation des récepteurs » [13].</footnote>
# 7. RAPPORT DU TEST DE TERRAIN EFFECTUÉ ET COMMENTAIRES

Ces perspectives de conception du cours et ces scénarios-types ont pu être partiellement mis à l'épreuve lors d'une séance de test en classe préparée en décembre 2017. Cette séance, prévue selon un protocole qui permettait de tester le logiciel avec un nombre élevé de connexions (jusqu'à 21 étudiants), a permis aux auteurs de se projeter dans une situation de cours réelle et de pouvoir apprécier la portée de leur conception pédagogique ainsi que de remarquer des aspects nouveaux qui seront intégrés lors de sa mise en œuvre effective. Dans une atmosphère de découverte, tant pour les étudiants que pour les professeurs, nous avons pu envisager des pistes d'interactions entre les membres de la classe et les enseignants. Les pédagogues et les développeurs ont alors conçu cette séance en trois étapes pour tenter de mettre à l'épreuve trois types de connexions de données sur un serveur local, distant et mobile. À partir de cette base ils ont pu valider la tenue du logiciel, des connexions de réseau, du serveur et interagir avec la classe en utilisant Kiwi pour la réalisation de trois patches. L'objectif principal de cette séance était clairement orienté vers un test technique car la séance était intitulée « crash test Kiwi ». D'autre part tester la prise en main de Kiwi par les étudiants n'a pas été proprement évoqué lors de cette séance et les critères n'ont pas été définis en équipe. Ce test technique consistait donc à évaluer :

1. la montée en charge de Kiwi,

2. le comportement de Kiwi sur les différentes configurations matérielles (systèmes d'exploitation des étudiants et type de machine),

3. les accès au réseau disponibles en séance (réseaux universitaires et connexions mobiles),

4. le travail sur Kiwi à partir d'un serveur distant puis à partir d'un serveur local déployé sur l'ordinateur d'un des encadrants du crash test.

Cependant tacitement chaque membre de l'équipe avait sa grille d'évaluation personnelle selon qu'il était le professeur du cours, le pédagogue et designer de ce nouveau cours ou l'ingénieur de recherche et développeur de Kiwi.

## 7.1. Point de vue du designer pédagogique

L'expérience de pédagogue nous a convaincus que les conditions de travail d'une classe sont déterminantes d'un point de vue pédagogique et influent par conséquent l'apprentissage. A travers ce test technique le designer pédagogique s'est ainsi intéressé à l'analyse des supports du cours et de l'environnement de travail que nous mesurons selon les ressources matérielles à disposition et leur distribution entre les acteurs. Au-delà de ces considérations propres aux ressources matérielles nous étions particulièrement attentifs au confort des étudiants au sein de ce dispositif de cours et à travers l'utilisation du logiciel Kiwi.

### 7.1.1. Conception et réalisation de la séance

Nous avons cherché à déterminer si la salle de classe et les étudiants disposaient bien de l'équipement nécessaire pour développer l'axe collaboratif renforcé que nous nous sommes fixé dans la refonte du cours. Dans le cadre de cette séance de test il fallait donc évaluer :

1. la mise en réseau ou non des ordinateurs et la présence de disques durs partagés et de serveurs,

2. les systèmes d'exploitation des machines des étudiants (et leur mises à jour et autorisations),

3. les supports de diffusion de l'information (tableau, enceintes, projecteurs) pour diffuser le patch Kiwi et les clefs USB pour installer Kiwi sur les machines,

4. le mobilier de classe et sa modularité pour créer des îlots ou des pôles de travail (chaises et tables),

5. la connectivité des salles en termes de prises électriques, de connexions internet par Ethernet, de niveau et de stabilité du réseau wi-fi, de qualité de réception du réseau téléphonique et connexions internet mobiles, etc.,

6. le nombre d'ordinateurs et de connexions internet.

En séance, nous avons déroulé un protocole de test et nous avons réalisé à chaque étape un sondage à main levée auprès des étudiants après chaque mise en situation concrète de travail sur Kiwi et recueilli leurs commentaires oraux.

### 7.2.2. Évaluation de l'environnement technique d'apprentissage de la classe

Une fois réalisé ce premier inventaire sur les ressources existantes et utiles au travail collaboratif, nous avons interrogé les étudiants propriétaires de ce matériel sur leur disposition à le partager. En effet partager ce matériel (leur connexion internet mobile, par exemple) est lié assez naturellement avec la question de la maintenance. L'aspect collaboratif numérique implique en effet un matériel toujours en mesure de fonctionner pour assurer le travail qui en dépend. Il n'est pas envisageable d'avoir un problème de connexion à internet persistant ou récurrent que cela vienne du réseau ou des machines. Il faut que ce problème intervienne le moins possible et qu'il soit très rapidement résolu : un internet haut-débit wi-fi stable est donc nécessaire pour un usage intensif des ressources en ligne et il faut en l'occurrence avoir un serveur robuste. Si l'un ou l'autre faisait défaut il nous faudrait des solutions de secours notamment en s'appuyant sur le matériel des étudiants (connexion internet mobile, par exemple, ou constitution d'un serveur local sur leur machine). C'est pourquoi, par ailleurs, nous avons testé le serveur commun de Kiwi sur un internet distant et sur un réseau local.

Pour évaluer le confort des étudiants nous avons observé :
- leur comportement quand les premiers sons sont sortis de leur machine,

- les premiers commentaires écrits et oraux qu'ils ont partagés sur leur *patch* commun,

- la fluidité de leur geste sur l'interface graphique,

- leurs difficultés éventuelles d'installation et de connexion.

### 7.2.3. Bilan

L'analyse des supports et de l'environnement de travail en situation a mis en relief la question de la maintenance des connexions internet. Nous suggérons d'attribuer des responsabilités et d'en distribuer la compétence entre le service informatique de l'Université, les professeurs de la spécialité, les étudiants eux-mêmes à titre individuel ou de constituer des groupes d'étudiants compétents pour maintenir le serveur en cas de *crash* et supplanter une éventuelle défaillance de la connexion internet.

Par ailleurs, dans la mesure où nous souhaitons que les étudiants puissent travailler en groupe en dehors du lieu où se déroule le cours, notre test portant sur les connexions mobiles des étudiants et des professeurs en situation de cours a été éclairant. Ce test a montré qu'un téléphone mobile peut supporter environ 4 étudiants connectés sur le serveur. En revanche, le taux de *crash* est supérieur et la qualité des interactions visuelles est moins bonne qu'en utilisant les réseaux universitaires Eduroam ou Eduspot.

Les questions d'équipement en machine et en connexion internet étant encore fortement dépendantes des lieux, nous envisageons à terme de cartographier les espaces de travail des étudiants pour pratiquer le *patching* collaboratif hors-classe (salles informatiques, studios, bibliothèque universitaire, etc.) et nous nous demanderons s'ils sont adaptés à l'évolution du cours. Il sera intéressant de s'interroger également sur la mobilité de ce dispositif technique. Par exemple, déterminer si les apprenants peuvent être mobiles et se déplacer entre deux connexions pour pratiquer le *patching* collaboratif dans différents lieux ou s'ils sont au contraire contraints d'utiliser un certain type de matériel dans un lieu spécifique.

## 7.2. Point de vue de l'enseignant

### 7.2.1. Conception et réalisation de la séance

En ouverture de séance le professeur a rappelé la nature expérimentale du cours et demandé aux étudiants leur participation active en tant que testeurs d'un nouveau logiciel. Il a également proposé aux étudiants de concevoir cette séance comme une expérimentation rigoureuse faisant partie d'un programme de recherche sur la pédagogie de la programmation musicale. Cette introduction a permis aux participants de comprendre l'importance de leur implication dans ce retour d'expérience. Après avoir installé le programme et suivi le protocole de test du logiciel, le professeur a demandé

aux étudiants de commencer à réaliser des *patches* collectifs. En premier le professeur a demandé à la classe de créer des objets *Kiwi* sur le *patcher*. Les participants ont pu apprécier les similitudes et les différences de la modalité de programmation *Kiwi* vis-à-vis de leur précédente expérience de *patching* avec Max et Pure Data. Les étudiants, divisés en groupes, ont été invités à réaliser un premier *patch* avec des objets simples permettant d'additionner des signaux. Les objets employés [osc~, [+~], [*~], [ slider ] et [dac~] ont pu être créés par tous les groupes et connectés de manière habituelle. Le professeur a pu constater l'exactitude des *patches* réalisés et interagir avec les étudiants.

Une fois tenue pour acquise la stabilité du logiciel et comprise la modalité de fonctionnement du cours collaboratif, le professeur a proposé aux étudiants de réaliser un *patch* plus complexe avec un nombre d'objets plus élevé. Il s'agissait de réaliser ensemble un *patch* qui permette de créer une modulation d'amplitude en utilisant des objets comme [line~] et [number]. Le professeur a également abordé l'implémentation d'une ligne à retard avec l'objet [delaysimple~]. La modulation de fréquence implémentée en fin de séance a permis d'introduire l'objet [sig~] et de créer des connexions et des contrôles sonores plus fins. De cette manière, les étudiants ont pu revisiter leur façon de programmer en expérimentant une interface alternative, qui ouvre des perspectives nouvelles.

### 7.2.2. Évaluation technique et pédagogique

Le professeur a pu constater les différences apportées par l'utilisation de *Kiwi*. La classe est en effet obligée de co-participer à la réalisation du *patch* à cause de la structure même du logiciel. Elle implique une connexion multiple au même *patch* : les étudiants partagent véritablement le même espace de rédaction du *patcher*. Ceci les oblige à développer des nouvelles compétences de travail collaboratif, comme par exemple des normes de politesse et des manières de communiquer et d'interagir détournées, comme par exemple l'utilisation de l'objet [comment] en tant que *chat*. Une telle interaction introduit une dimension ludique qui favorise les échanges et la bonne atmosphère au sein de la classe. Ces retombées et les comportements des étudiants n'ont cependant pas surpris les pédagogues car ils étaient pris en compte et prévus lors du *design* du cours.

### 7.2.3. Bilan

Le scénario prévu se révèle efficace pour prendre en main le logiciel. Le professeur a pu remarquer une participation plus efficace. En même temps, l'interaction avec la classe a fait en sorte que des innovations du nouveau scénario prévu aux points 3) et 4) émergent, notamment au niveau de la visualisation, en classe, des *patches* réalisés singulièrement par les groupes. En contrôlant qu'effectivement tous les groupes étaient capables d'utiliser le logiciel, certains *patches* des étudiants étaient partagés sur l'écran projeté au tableau,
par l'ordinateur du professeur. Cela a permis de travailler
véritablement ensemble au niveau de la programmation
et d'interagir avec toute la classe pour s'entraider sur la
réalisation d'un *patch* d'un groupe particulier. Par cette
situation le professeur pouvait solliciter la participation
de la classe en posant des questions concernant la
résolution du *patch*. Selon les auteurs, un tel aspect
constitue une avancée pratique importante au niveau de
l'enseignement car les étudiants en participant d'une
manière plus active accroissent leur compréhension du
logiciel et par conséquent de certains fondements de la
musique électronique.

**7.3. Point de vue du développeur**

7.3.1. *Conception et réalisation de la séance*

Cette séance de test à l'université avait, du point de
vue du développement et de la conception, deux objectifs
principaux. Le premier était d'éprouver techniquement le
logiciel dans des conditions réelles en termes de latence
du réseau et de nombre d'utilisateurs connectés à une
session. Le second était d'observer l'utilisation du
logiciel *Kiwi* par les étudiants et de collecter leurs
remarques afin de planifier de nouveaux développements
à moyen et long terme.

7.3.2. Évaluation technique et ergonomique

La robustesse et le niveau de qualité d'un logiciel sont
des notions évidemment primordiales de l'ingénierie
logicielle. Cependant, dans le cadre d'un projet
expérimental tel que *Kiwi*, l'accent est mis sur la
conception de nouvelles *features* collaboratives
innovantes obligeant parfois le développeur à faire des
compromis. C'est pourquoi il était important de planifier
une séance de test afin de relever les problèmes
techniques et de pouvoir les corriger dans la phase finale
précédent la sortie de la première version de *Kiwi*.

Comme évoqué précédemment, la qualité de
l'apprentissage de l'audio numérique collaboratif est un
point central dans le cadre de recherche du projet
Musicoll. De plus, un de nos objectifs est de rendre
accessible le *patching* audio collaboratif à une
communauté large d'utilisateurs allant du novice
souhaitant découvrir cette façon de composer à
l'utilisateur expérimenté. C'est pourquoi l'ergonomie et
l'expérience utilisateur doivent être particulièrement
soignées. Or, il est parfois difficile pour les membres de
l'équipe Musicoll, qui sont soit des utilisateurs aguerris
d'outils de *patching* audio tel que *Max* ou *Pure Data* soit
des personnes à l'aise avec l'utilisation de logiciels
collaboratifs en réseau, de distinguer certaines difficultés
d'utilisation.

7.3.3. Bilan

Du point de vue technique, cette expérience est une
réussite car elle a permis d'observer des problèmes du
logiciel difficiles à observer dans un contexte classique
d'utilisation c'est-à-dire sans latence et avec seulement
quelques utilisateurs. Ces problèmes seront bien entendu
corrigés avant le lancement officiel du cours utilisant
*Kiwi* comme support.

Nous avons pu constater grâce à ce test d'utilisation
qu'une attention particulière devait être portée à
l'ergonomie du logiciel liée à la connexion (notification
de l'état connecté/non connecté, facilité du *login*).

La discussion avec les étudiants nous a également
permis de distinguer des pistes de conception à plus long
terme. Ainsi la question du jeu collaboratif, c'est-à-dire
de la possibilité de pouvoir transmettre entre utilisateurs
des paramètres de contrôle, a de nouveau été évoquée.
Nous avons donc décidé de concrétiser le développement
de cette fonctionnalité afin que les utilisateurs de *Kiwi*
puissent en bénéficier dès la première version <fnref n="19" />.

8. CONCLUSIONS

Le changement concret d'utilisation d'un
environnement de programmation graphique implique
une innovation dans les approches pédagogiques qui ont
un impact sur la pratique musicale en elle-même et
comportent des avantages en termes d'apprentissage. Du
point de vue de la conception pédagogique du cours,
l'approche liée à *Kiwi* nous enjoint de reconstruire le lien
qui associe la question de l'enseignement du *patching*
audionumérique aux problématiques de composition que
rencontrent les étudiants en création musicale dans notre
université. Selon nous le *patching* collaboratif apporte
des innovations qui conduisent à :

- expérimenter l'intelligence collective dans ce type de pratique de programmation musicale ;

- penser les étudiants en terme de membres d'une
communauté d'apprentissage ;

- repenser la façon d'évaluer les étudiants au sein d'un
groupe ;

- commencer une réflexion / action au sein de l'équipe
pédagogique sur l'apport de l'apprentissage en
collaboratif numérique ;

- accepter de nous investir en tant qu'enseignants-
chercheurs sur cette façon collaborative d'enseigner
et de pratiquer la programmation musicale avec
l'intuition qu'elle sera très développée à l'avenir.

Lors des tests effectués, nous pouvons avancer des
considérations concernant ce paradigme collaboratif :

- nous avons remarqué une **implication différente** de
la classe qui est amenée à dialoguer d'une manière
profitable dans la réalisation des *patches* ;

- l'interaction entre les étudiants assume une
**dimension ludique** qui crée une atmosphère

<footnote n="19">¹⁹ L'objet [hub] a depuis été créé pour cela.</footnote>
favorable. Le professeur a pu apprécier des aspects
nouveaux au niveau de la conduite du cours ;

- le partage des différents *patches* des groupes permet d'impliquer les membres de la classe dans la résolution des questions liées à la programmation. Cet aspect a selon nous un impact remarquable sur la vitesse d'appréhension des concepts et des objets, leur profondeur et leur enracinement dans la pratique des étudiants.

Des aspects critiques accompagnent les éléments positifs de l'utilisation de *Kiwi* que nous venons d'évoquer :

- l'**instabilité des connexions** internet pourrait mettre en danger le déroulement des séances ;

- la mise en commun du support pourrait mener à des **déséquilibres** au niveau de la participation des étudiants. En effet le fait de travailler sur un même *patch* risque de favoriser les étudiants plus rapides et/ou aguerris. C'est pourquoi afin de remédier à cette éventualité, les enseignants ont demandé aux étudiants inscrits de remplir un questionnaire concernant leurs connaissances et pratiques audionumériques. Au cours du semestre ils veillent à la constitution de groupes d'environ 5-6 étudiants pour favoriser la proximité entre participants de niveau équilibré dans leur aptitudes (à modéliser, à mobiliser des connaissances, à expliquer leur démarches).

De fait, l'équipe pédagogique espère qu'à travers ce dispositif d'enseignement, les étudiants auront acquis une base de connaissances qui devraient leur permettre de terminer leur licence de manière efficace et d'envisager la poursuite de leurs études en ayant profité des innovations au niveau pédagogique que cette nouvelle logiciel propose. Pour mesurer le premier impact des scénarios pédagogiques envisagés, les enseignants préparent un bilan de fin de semestre en comparant les connaissances de la classe au début et à la fin du cours de *Kiwi*.

9. REMERCIEMENT

La majeure partie de la recherche exposée dans cet
article est financée dans le cadre de la convention
attributive d'aide de l'Agence Nationale de la Recherche
n° ANR-15-CE38-0006-01.

10. RÉFÉRENCES

[1] A. Agostini, D. Ghisi, R. Grimaldi, E. Maestri, A. Sarto, (collectif /nu/thing), *I mille fuochi dell'universo*, pour ensemble et électronique (2017). Commande du 26ème Festival Milano Musica et de la Fondation Siemens.

[2] C. De Lavergne, M-C. Heïd, « Former à et par la collaboration numérique », tic & société [on line], Vol. 7, n°1, online. URL : http://ticetsociete.revues.org/1308; DOI: 10.4000/ticetsociete.1308.

[3] P. Galleron, « Développement d'une communauté de pratique de la composition musicale assistée par ordinateur en milieu scolaire : conception, parcours et modélisation », thèse de doctorat. de l'Université Paris 8, 2017, 724p.

[4] P. Galleron, A. Bonardi, M. Zacklad, « La documentarisation coopérative du processus de création musicale numérique dans un contexte pédagogique », *Actes des Journées d'Informatique Musicale 2015*, Montréal, Canada, <http://jim2015.oicrm.org/#actes>. <hal-01161641>.

[5] E. Paris, J. Millot, P. Guillot, A. Bonardi, A. Sedès, « Kiwi : vers un environnement de création musicale temps réel collaboratif premiers livrables du projet Musicoll », *Actes des Journées d'Informatique Musicale 2017*, Paris, 2017.

[6] Partnership for 21st Century Learning, http://www.p21.org/component/content/article/2224.

[7] J.P. Roux « Le travail en groupe à l'école » in Cahiers Pédagogiques, N°424, Mai 2004, page 2. http://www.cahiers-pedagogiques.com/IMG/pdf/Roux.pdf, consulté 22 janvier 2017.

[8] G. Stahl, T. Koschmann, D. Suthers, « Computer-supported collaborative learning: An historical perspective ». In R. K. Sawyer (Ed.), Cambridge handbook of the learning sciences. Cambridge, UK, 2006, pages 409-426, [Cambridge University Press].

[9] D. Tao, J. Zhang, D. Gao, "Reflective Structuration of Knowledge Building Practices in Grade 5 Science: A two years Design-Based Research", *CSCL 2017 Proceedings*, p. 644-647.

[10] J. Theureau, « Les entretiens d'autoconfrontation et de remise en situation par les traces matérielles et le programme de recherche « cours d'action », Revue d'anthropologie des connaissances, Vol 4, n° 2, 2010/2.

[11] L.S. Vygotsky, (1931/1983). История развития высших психических функций // Собр. соч.: В 6 т. М.: Педагогика. Т. 3, с. 5-328. [History of the Development of the Higher Mental Functions. In R.W. Rieber (Ed.), The Collected Works of Vygotsky, vol. 4 (1-251). (1997). New York: Plenum Press.

[12] É. Wenger, La théorie des communautés de pratique. Apprentissage, sens et identité, Québec. Presses de l'Université de Laval, 2005. [Communities of Practice: Learning, Meaning, and Identity, Cambridge University Press, 1998 traduit de l'original par Fernand Gervais.

[13] M. Zacklad, « Processus de documentarisation dans les Documents pour l'Action (DopA) : statut des annotations et technologies de la coopération associées ». *Le numérique : Impact sur le cycle de vie du document pour une analyse interdisciplinaire*, Montréal, Québec, 2005. Éditions de l'ENSSIB. http://archivesic.ccsd.cnrs.fr/sic_00001072/
# APPROPRIATING MUSIC COMPUTING PRACTICES THROUGH HUMAN-AI COLLABORATION

Hugo Scurto

Ircam - Centre Pompidou

STMS IRCAM-CNRS-SU

Hugo.Scurto@ircam.fr

Frédéric Bevilacqua

Ircam - Centre Pompidou

STMS IRCAM-CNRS-SU

Frederic.Bevilacqua@ircam.fr

## ABSTRACT

This paper presents a prototypical computational framework for music computing appropriation. Putting Human-Computer Interaction at the center of the issue, it proposes to use Artificial Intelligence (AI) to assist humans in their first uses of music computing systems—namely, their exploration. We first review how interaction design may be central to exploration and appropriation of music computing systems, highlighting guidelines and potential directions to improve it. We then present our framework proposal, centered on exploration, detailing both its interactive workflow and the AI model at stake. We finally illustrate the pedagogical potential of our framework in two musical applications that we implemented, and discuss future research toward understanding how AI could be used by humans as collaborators for self-expression and appropriation of music computing practices.

## 1. INTRODUCTION

The introduction of the computer in music has brought a wealth of novel practices around sound and music. Cutting-edge technologies have been developed for sound synthesis, processing, analysis, and control, enabling the emergence of new music works, practices, notations, and performances.

However, such new technologies remain hard for people to appropriate. While music computing is now taught in many music institutions, it still suffers from its apparent complexity. As a consequence, many musicians stay attached to their classical practices and resign to appropriate music computing, while many musicians-to-be never take a chance to explore music computing systems. This is paradoxical as computing has become ubiquitous in the last ten years.

Can we think of a computer tool that would facilitate exploration and appropriation of music computing systems? In this paper we propose a computational framework for appropriating music computing. We first argue that the field of Human-Computer Interaction (HCI) may offer promising approaches to support appropriation by improving interface accessibility. We then propose to use Artificial Intelligence (AI) to provide users with human-centred interactions during their exploration of music computing tools.

We finally illustrate our framework’s potential with two example musical applications, and discuss future work to be done to better understand how AI could be used as collaborators by humans in their own appropriation of music computing and expression of musical ideas.

## 2. THE ROLE OF INTERACTION DESIGN IN MUSIC COMPUTING APPROPRIATION

We focus on a particular use case of music computing appropriation. The use case refers to the situation where a user makes use of a music computing system on his or her own, outside educational institutions. In this situation, appropriation issues arise during the first uses of the music computing system.

### 2.1. Appropriation in Music Computing

#### 2.1.1. Gathering Information on a System

A first option to start using a system consists in gathering information on it—in a passive learning setup. Information on a system can be found in various media, from the most straightforward (e.g., a text or video tutorial) to the most technical (e.g., a research paper), as well as through online discussion (e.g., an Internet forum). These activities are often time-consuming: users first have to find relevant information (which can be hard for obsolescent systems), then to filter it (i.e., find what is useful for a specific goal), supposed that they have a specific goal in mind. Overall, time spent on passively learning hinders users to interact with sound and music directly, which might drive them away from experimenting with the system.

#### 2.1.2. Experimenting with an Interface

A second option consists in starting interacting with the system’s interface from scratch—in an active learning setup. Interacting with the interface implies trying many different actions directly to understand the functioning of the system (in a trial-and-error fashion), and eventually to achieve a specific goal. In our case of music computing, these activities are crucial as it is important for users to actively control sound so as to strengthen action-perception loops [15]. Yet, it is also possible that users get discouraged in interacting with the interface if they get too much
<figure><img src="image_88.png" /><figcaption>**Figure 1.** Example of interface in a music computing system (here, the u-he Bazille VST<fnref n="1" />).</figcaption></figure>

error during their trials. Notions of appropriation [23] and novice to expert transition [7] are thus crucial in the design of interactions at stake in a given interface. Several works in the field of Human-Computer Interaction (HCI) have given guidelines for designing interactions in creative interfaces that facilitates appropriation [19]. We believe these could be applied to the design of interactions in music computing systems.

## 2.2. Human-Computer Interaction in Music Computing Systems

### 2.2.1. User Interface

We identify two drawbacks of current music computing systems in the context of appropriation. First, most music computing systems' interfaces can look quite intimidating for completely novice users. Some of them directly derive from their analog ancestors (e.g., sound synthesis engines, see Figure 1, or spatialization tools [4]): they are thus designed for expert users, not to facilitate interaction for novice users. There do have been attempts to improve interface accessibility of these systems [6, 5, 20]. Yet, these interface simplifications are often done to the detriment of the system's abilities: after having appropriated some tasks, users become limited by the interface's lack of sophistication.

### 2.2.2. Models and Representations

The second drawback is that music computing systems often rely on complex models and representations that are not directly linked to sound or music. For example, improvisational systems [1] or gesture following systems [3] require users to have specific knowledge on models at stake (see Figure 2) to understand how parameters relate to system customization. Similarly, musical environments such as Max or PureData require to learn new representations as well as programming to start interacting. This drawback is common to both music novices and experts— who might know a certain amount of musical parameters, but do not know how they relate to new mathemat-

<figure><img src="image_89.png" /><figcaption>**Figure 2.** Example of model in a music computing system (here, a Gaussian Mixture Model for gesture-sound mapping<fnref n="2" /> [13]).</figcaption></figure>

ical parameters—, and constitutes a major issue for music pedagogy—as such music computing systems have been shown promising for instrument learning [8] and embodied practice [2]. We believe redesigning interaction with these systems for improving appropriation could spread these pedagogical benefits among more people.

## 2.3. Interactive Machine Learning

### 2.3.1. Overview

In the last decade, the field of Interactive Machine Learning has enabled more accessibility and appropriation of music computing systems by implementing human-centred interactions. At the crossroads between HCI and AI, it studies human interaction with algorithms, and integrates human actions in the design of algorithms themselves. Its applications has enabled the emergence of new music practices [11], as well as new computational frameworks [13]. As an example, the "mapping-by-demonstration" framework developed by Françoise [12] allows users to build custom gesture-sound mappings by directly demonstrating examples of gestures while listening to sounds, thus improving accessibility compared to previously-cited systems.

### 2.3.2. Pedagogical applications

From a pedagogical point of view, the potential of interactive machine learning systems has been identified, yet little exploited. For gestural control of sound, they have been cited as allowing "learners to experience components of higher-level creativity and social interaction even before developing the prerequisite sensorimotor skills or academic knowledge" [18]. Interestingly, novel application domains, such as music therapy and musical expression for people with disabilities, have also emerged [21]. We believe extending interactive machine learning approaches to other music computing systems could constitute an opportunity to widen the reach of more music computing practices to more people.

<footnote n="1">¹ http://www.u-he.com/cms/bazille</footnote>

<footnote n="2">² https://github.com/Ircam-RnD/xmm</footnote>
# 3. CO-EXPLORATION: A FRAMEWORK PROPOSAL FOR AI-ASSISTED INTERACTION

We now present a framework proposal that focuses on assisting human exploration of music computing systems using AI. We first motivate the framework, then describe both its interactive workflow and AI modelling.

## 3.1. Motivation

### 3.1.1. Why assisting exploration?

Exploration is the early phase of learning during which a human iteratively acts on an interface and receives feedback information, allowing him or her to gradually grasp the system's functioning and qualities. As discussed previously, it is a crucial phase in appropriation regarding learning and skill development, as good or bad initial experience will determine the future degree of motivation and involvement of a learner term for a given task [7]. By aiming at a framework that assists this exploration phase, our wish is to lower the threshold for learners to directly interact with the system and sense its abilities, paving the way for further understandings of how the system actually works. Moreover, we argue that exploration may be a specific case of embodied interaction [15], in which expression plays a key role [16].

### 3.1.2. How to assist exploration?

To assist human exploration, we find it relevant to use the metaphor of transmission of knowledge between humans. Consider a human that has an idea but does not know how to convert it in a concrete realization. Usually, the human will ask assistance to a second human to realize this conversion—we call it the assistant. Iterative interaction between the two humans takes place, during which the assistant takes actions on the system and the human gives feedback on it—until converging to a final design. Our idea is to have an AI agent take the role of the assistant: AI acts on the system, upon which the human gives feedback. AI thus explores design possibilities in collaboration with the human, letting the human focus solely on aligning their conceptual space with the perceptual space offered by the AI—postponing the sensorimotor and/or academic learning phase to a later phase. Such co-adaptation phenomenon between the human and the machine has been shown as a useful mechanism for reducing the human's cognitive overload [17].

## 3.2. Workflow Definition

We propose to formalize the interactive workflow of such a framework—we call it "co-exploration" (see Figure 3).

### 3.2.1. Design Through Co-Exploration

Co-exploration stands for collaborative human-AI exploration of a given music computing system. The human explores the expressive abilities of the system (progressively

<figure><img src="image_90.png" /><figcaption>**Figure 3.** Co-exploration framework. In a standard situation (behind), a human explores a system by iteratively acting on it. In co-exploration (front), an AI agent explores a system in parallel to the human.</figcaption></figure>

learning interesting abilities in the system), while the AI explores the aesthetic preferences of the human (progressively learning which system parameters are relevant for the human). Design through co-exploration encapsulates the possibility for a (possibly novice) human to create a musical artifact from a (possibly unknown) computer system by collaborating with an AI agent in the exploration of design possibilities. A typical scenario would imply the agent generate an initial random solution to the human, who would progressively shape it through her preferences.

### 3.2.2. Feedback-mediated interaction

As we saw it, human interaction with the music computing system is mediated by an AI. Concretely, this means that the human does not interact with the system's interface: an AI agent does it instead. Instead, the human focuses on giving evaluative feedback on the AI agent's actions, judging the system's output on a perceptual level. Potentially, this feedback could be of any type—be it text-based, demonstration-based, or physiological.

### 3.2.3. Reinforcement feedback

We propose to investigate reinforcement feedback, which can be positive or negative. Advantages are threefold. First, it could encapsulate several kinds of feedback in one unique format, such as general advice (e.g. "this is good", "this is bad"), implicit knowledge (e.g. "do it more like this", "don't go that way"), as well as explicit specification (e.g. "this is exactly what I want", "never show me this again"). Second, it could be expressed relatively easily (compared to text-based feedback, which forces users to create a concrete verbalization of what they want). Third, it could give a sense of agency to the human (compared to physiological feedback, which most humans do not control). Overall, we hypothesize that communicating such high-level feedback could facilitate musical exploration of a system compared to specifying its low-level parameters.
## 3.3. AI Model

We propose to investigate the interactive use of a specific category of AI algorithms, called reinforcement learning, which applications in music computing have been few and far between [10, 9].

### 3.3.1. Reinforcement learning

Reinforcement learning defines a formal framework for the interaction between a learning agent and an environment in terms of states, actions, and rewards [22]. At time $t$, an agent senses its environment through an observation called state $S_t$ (typically, a vector of discrete parameters), and on that basis takes an action $A_t$ on it (typically, a set of discrete modifications on these parameters). At time $t+1$, in response to its action, the agent receives a reward $R_{t+1}$ from the environment, as well as a new state $S_{t+1}$. From this information, the agent iterates interaction, progressively learning how to optimize interaction with the environment so as to maximize the total amount of reward it receives over the long run.

### 3.3.2. Learning from exploration

Reinforcement learning algorithms differ from supervised (and unsupervised) learning algorithms. For the latters, learning typically occurs offline on the basis of a static training dataset, which is a set of labeled (or unlabeled) examples we would like the system to generalize behaviour from. In reinforcement learning, the agent learns online by directly interacting with its environment. As a result, a reinforcement learning agent must always balance between exploration and exploitation to improve its learning – exploration meaning trying new actions to discover which ones yield the most reward, and exploitation meaning choosing the best actions in terms of reward at the time of computation.

### 3.3.3. Requirements for human interaction

In the case of co-exploration, we must add another element to the formal framework defined above. We propose that a human would be responsible for giving reward to the learning agent, as a consequence of the agent's action toward the environment's state (see Figure 4). Our hypothesis is that the numerical reward could constitute a feedback channel from the human to the AI agent (e.g. telling the agent that its action has been good or bad from the human's subjective point of view).

Interactive agent teaching have been investigated in previous research, leading to the creation of efficient learning agents [14]. Our research differs from these works in the sense that it focuses on interactive agent teaching from the human point of view (how it is "efficient" for the human, not necessarily for the agent), and that the tasks to be learned in creative activities may have different properties than those in goal-oriented activities (such as learning how to play Tetris).

<figure><img src="image_91.png" /><figcaption>**Figure 4.** Co-exploration workflow. Interaction between the human and the music computing system is mediated by an AI agent (in blue). At time $t$, the agent acts directly on the system's parameters. At time $t+1$, the system generates a new state (for example, a sound), that is subjectively evaluated by the human through a reinforcement feedback. By iterating the loop, the agent learns how to co-explore.</figcaption></figure>

## 4. EXAMPLE MUSICAL APPLICATIONS

We implemented a first prototype of our co-exploration agent—we call them "co-explorers"—and applied it within two existing music computing systems.

### 4.1. Implementation

We are currently implementing coax, a software library for collaborative human-AI exploration. Its architecture will allow users to choose among a variety of reinforcement learning agents, and to modify some high-level parameters that control their exploration. Agents can be connected to any kind of interactive music system that sends and receives OSC messages. The current prototype implements the Sarsa learning algorithm [22] upon a set of Python classes. Its interface consists in two buttons: one for indicating positive feedback, one for negative—we will discuss further improvements in next section. We implemented our two applications in the Max/MSP environment.

### 4.2. First application: VST Exploration

#### 4.2.1. Motivation

The first application connects an AI agent to a VST (u-he Bazille, see Figure 1). VSTs are software interfaces that allows to create sounds by combining various synthesis algorithms and audio processings. Their interface typically consists of knobs and faders, directly linked to low-level parameters of synthesis and processing. While these music computing systems are widely used and effective among expert composers, their interface may constitute a huge barrier for novice users to launch into exploring and understanding their functioning, preventing them from appropriating digital sound creation.
### 4.2.2. *Description*

The workflow consists of users first listening to a random sound generated by the VST, give positive or negative feedback on it depending of their subjective evaluation of the sound, then listen to a new sound that was synthesized taking into account previous feedback. Formally, the environment's state consists of a vector of twelve VST parameters; the agent's actions consists of moving one of these parameters up or down. The resulting collaboration consists in the user focusing on developing its listening abilities and tastes toward the VST, while the AI agent learns how to convert the user's tastes in terms of VST parametrization. A preliminary evaluation led with four expert computer musicians experimenting with our system with three different VSTs confirmed our initial conjectures on how useful co-exploration could be for appropriating a VST—we should discuss such results in a future publication.

## 4.3. Second application: Mapping Exploration

### 4.3.1. *Motivation*

The second application connects an AI agent to a gesture-sound mapping (using the *XMM* library, see Figure 2). Mappings are complex functions that link gestural devices to sound synthesizers. They allow performers to focus on their physical gestures in their musical practice and embodied engagement with sound. However, they typically imply a phase of parametrization, which require knowledge on mathematical modelling and programming. This can hinder novice users as well as expert musicians to create their own gestural controller and develop self-expression.

### 4.3.2. *Description*

The workflow consists of users first experimenting with a random gesture-sound mapping, give positive or negative feedback on it depending of their subjective evaluation of the mapping, then experiment with a new mapping that was generated taking into account previous feedback. Formally, the environment's state consists of a vector of twelve mapping parameters; the agent's actions consists of moving one of these parameters up or down. The resulting collaboration consists in the user focusing on developing its sense of corporeal engagement with sound, while the AI agent learns how to convert it in terms of mapping parametrization. Ultimately, as users give feedback on mappings that they experiment with, the AI agent would be able to generate mappings that either suit them (exploitation), or aim at surprising them (exploration).

## 5. CONCLUSION AND FUTURE WORK

In this paper we have formulated a scientific hypothesis on how human-AI collaboration could support music computing appropriation. Part of future work will consist of

refining the design of learning algorithms, as to optimize human-AI exploration. Also, a general interface for co-exploration might be designed. We will keep on testing our framework with other music computing systems as well to spread the range of musical activities covered—for example, connecting co-explorers with sequential music content (such as notes or events).

An important part of future work will consist of evaluating our framework with expert users, i.e. users that work around music at a professional level. We are currently leading and building a set of case studies that aim at better understanding how AI agents could assist these users in their exploration of music computing practices. Specifically, our aims are (1) assessing whether co-exploration might be useful for them compared to their standard exploration strategies, and (2) studying how co-exploration might be useful on a longer term along their creative practice. These two-scale studies would allow us to better quantify the pedagogical benefits our framework might offer.

Finally, we will lead real-world applications with novice users, i.e. users that are neither musicians, nor computer specialists. The goal of these applications will rely on observing how co-exploration might constitute an entry point for these novice users to music computing practices. Based on previous works [18], we envision that our interactive machine learning workflow may allow novices to experience creative and social aspects of music before devoting time to learning and understanding technical aspects. Overall, we will be able to better understand how AI could be used by humans as collaborators for self-expression and appropriation of novel music computing practices.

# 6. ACKNOWLEDGEMENTS

We thank Baptiste Caramiaux, Jules Françoise and Benjamin Matuszewski for useful discussions and suggestions.

## 7. REFERENCES

[1] G. Assayag, G. Bloch, M. Chemillier, A. Cont, and S. Dubnov. Omax brothers: a dynamic topology of agents for improvisation learning. In *Proceedings of the 1st ACM workshop on Audio and music computing multimedia*, pages 125–132. ACM, 2006.

[2] F. Bevilacqua, F. Guédy, N. Schnell, E. Fléty, and N. Leroy. Wireless sensor interface and gesture-follower for music pedagogy. In *Proceedings of the 7th International Conference on New Interfaces for Musical Expression (NIME)*, pages 124–129. ACM, 2007.

[3] F. Bevilacqua, B. Zamborlin, A. Sypniewski, N. Schnell, F. Guédy, and N. Rasamimanana. Continuous realtime gesture following and recognition. In *International gesture workshop*, pages 73–84. Springer, 2009.
[4] T. Carpentier, M. Noisternig, and O. Warusfel. Twenty years of IRCam spat: looking back, looking forward. In *41st International Computer Music Conference (ICMC)*, pages 270–277, 2015.

[5] M. Cartwright and B. Pardo. Synthassist: Querying an audio synthesizer by vocal imitation. In *Proceedings of the 14th International Conference on New Interfaces for Musical Expression (NIME)*, 2014.

[6] M. Cartwright, B. Pardo, and J. Reiss. Mixploration: Rethinking the audio mixer interface. In *Proceedings of the 19th International Conference on Intelligent User Interfaces*, pages 365–370. ACM, 2014.

[7] A. Cockburn, C. Gutwin, J. Scarr, and S. Malacria. Supporting novice to expert transitions in user interfaces. *ACM Computing Surveys (CSUR)*, 47(2):31, 2015.

[8] A. Cont. Antescofo: Anticipatory synchronization and control of interactive parameters in computer music. In *International Computer Music Conference (ICMC)*, pages 33–40, 2008.

[9] N. Derbinsky and G. Essl. Exploring reinforcement learning for mobile percussive collaboration. In *Proceedings of the 2012 International Conference on New Interfaces for Musical Expression (NIME)*, 2012.

[10] R. Fiebrink and B. Caramiaux. The machine learning algorithm as creative musical tool. *arXiv preprint arXiv:1611.00379*, 2016.

[11] R. Fiebrink, D. Trueman, N. C. Britt, M. Nagai, K. Kaczmarek, M. Early, M. Daniel, A. Hege, and P. R. Cook. Toward understanding human-computer interaction in composing the instrument. In *Proceedings of the 2010 International Computer Music Conference (ICMC)*, 2010.

[12] J. Françoise. *Motion-sound mapping by demonstration*. PhD thesis, Université Pierre et Marie Curie, 2015.

[13] J. Françoise, N. Schnell, R. Borghesi, and F. Bevilacqua. Probabilistic models for designing motion and sound relationships. In *Proceedings of the 2014 International Conference on New Interfaces for Musical Expression (NIME)*, pages 287–292, 2014.

[14] W. B. Knox and P. Stone. Interactively shaping agents via human reinforcement: The tamer framework. In *Proceedings of the fifth international conference on Knowledge capture*, pages 9–16. ACM, 2009.

[15] M. Leman. *Embodied music cognition and mediation technology*. MIT Press, 2008.

[16] M. Leman. *The expressive moment: How interaction (with music) shapes human empowerment*. MIT press, 2016.

[17] W. E. Mackay. Responding to cognitive overload: Co-adaptation between users and technology. *Intelligențica*, 30(1):177–193, 2000.

[18] D. Morris and R. Fiebrink. Using machine learning to support pedagogy in the arts. In *Personal and ubiquitous computing*, pages 1631–1635. Springer, 2013.

[19] M. Resnick, B. Myers, K. Nakakoji, B. Shneiderman, R. Pausch, T. Selker, and M. Eisenberg. Design principles for tools to support creative thinking. In *National Science Foundation Workshop on Creativity Support Tools*. Washington DC., 2005.

[20] D. Schwarz, G. Beller, B. Verbrugghe, and S. Britton. Real-time corpus-based concatenative synthesis with catart. In *9th International Conference on Digital Audio Effects (DAFx)*, pages 279–282, 2006.

[21] H. Scurto, R. Fiebrink, et al. Grab-and-play mapping: Creative machine learning approaches for musical inclusion and exploration. In *Proceedings of the 2016 International Computer Music Conference*, 2016.

[22] R. S. Sutton and A. G. Barto. *Reinforcement learning: An introduction*. Cambridge, MA: MIT Press, 2011.

[23] V. Zappi and A. McPherson. Dimensionality and appropriation in digital musical instrument design. In *Proceedings of the 2014 International Conference on New Interfaces for Musical Expression (NIME)*, pages 455–460, 2014.
# REDI-MUSIX :
## RESEAU POUR LA DISTRIBUTION DE LA MUSIQUE MIXTE

Alexander Mihalic
Musinfo
mihalic@musinfo.fr

Mikhail Malt
Musinfo
malt@musinfo.fr

## RÉSUMÉ

La mutation numérique de la société donne lieu à la production d'œuvres qui croisent les nouvelles technologies et les instruments traditionnels. Les assemblages d'outils destinés aux tâches multiples favorisent les installations uniques, difficilement maîtrisées par les interprètes ([1], [2], [3], [4], [5] et [6]). Pour jouer de la musique mixte, la seule solution viable est la création et la fabrication d'un instrument dédié. Si cette démarche permet la standardisation de l'instrument électronique, il reste en outre indispensable de sécuriser l'accès au répertoire existant. La mobilité et la nécessité de produire ces œuvres indépendamment du lieu et de leur complexité technologique nous amènent à proposer un projet de réseau de distribution de la musique mixte dans les conservatoires et les écoles de musique, quelles que soient leurs situations géographiques ou leurs tailles.

Le projet proposé RéDi-Musix, porté par Musinfo et soutenu par le Ministère de la culture et de la communication<fnref n="1" />, consiste à mettre en place un service de distribution de configurations électroacoustiques au travers d'un réseau numérique. Ce réseau connectera les établissements musicaux en France et à l'étranger afin de favoriser la création et l'accès au patrimoine vers un public le plus large possible. Les configurations électroacoustiques seront distribuées sur des terminaux appelés « Sampo », placés dans les établissements partenaires et permettant de jouer la musique mixte de façon autonome.

## 1. INTRODUCTION

La musique mixte met en relation un instrument acoustique avec un environnement électroacoustique. Pour produire ce type de musique, nous avons besoin de partitions, mais aussi de configurations et d'éléments matériels et logiciels, indissociables d'une telle œuvre. La mise en place de ces configurations matérielles et logicielles ainsi que leur gestion (mise à jour des configurations et mise en route) sortent dans la grande majorité des cas du champ de connaissance et de maitrise des interprètes.

Si la distribution des partitions ne pose pas de problème particulier aujourd'hui, les partitions étant vendues sur les sites internet et pouvant être téléchargées directement sur les ordinateurs et imprimées chez les musiciens, le problème se pose pour les configurations matérielles et logicielles. Dans ces conditions, comment aller directement à l'essentiel, soit l'étude, la composition et la performance de cette catégorie d'œuvres, sans perdre trop de temps avec les éléments techniques ? De plus, comment échanger efficacement des informations, configurations et fichiers sons, lors de la phase de composition, entre compositeur et interprète, pour ce même dispositif, directement chez le musicien pour qu'il puisse travailler et jouer ? C'est dans ce contexte et pour palier à ces difficultés, que voit le jour le projet RéDi-Musix.

## 2. LE PROJET REDI-MUSIX

Le projet « RéDi-Musix - Réseau de distribution de la musique mixte »<fnref n="2" />, repose d'un côté sur un instrument/terminal et de l'autre sur un service centralisé de distribution de contenus/configurations sous forme d'une base de données en ligne (Figure 1).

<figure><img src="image_92.png" /><figcaption>Figure 1. Schéma du réseau RéDi-Musix.</figcaption></figure>

Ce projet propose de réunir tous les éléments nécessaires à la production de la musique mixte depuis sa création et sa distribution jusqu'à son archivage. Techniquement le projet se présente comme un service

<footnote n="1">¹ http://www.culturecommunication.gouv.fr/Aides-demarches/Appels-a-projets/Appel-a-projets-services-numeriques-innovants-2016</footnote>

<footnote n="2">² http://www.redi-musix.com/</footnote>
appelé communément « cloud » (nuage) ainsi que des éléments matériels et logiciels annexes :

* **terminal Sampo** - instrument électroacoustique autonome et universel et qui permet d'accéder au répertoire sur le cloud

* **logiciel P-Soft** - logiciel pour les musiciens désireux d'échanger leurs configurations et déposer des pièces dans la base à la disposition des autres musiciens.

* **base de données** - base de pièces du répertoire de la musique mixte

* **stockage des fichiers** - fichiers sons, fichiers de configurations du dispositif et accès aux fichiers

* **communauté d'utilisateurs** - les compositeurs/musiciens qui déposent leurs œuvres dans la base

## 3. INSTRUMENT/TERMINAL SAMPO

Sampo est un dispositif matériel intégrant tous les éléments nécessaires à la performance et à la composition de musique mixte (Figure 2). Il offre une solution complète, dès la captation du son par le micro, en passant par sa transformation à l'aide des pédales<fnref n="3" />, jusqu'à la sortie sur les haut-parleurs intégrés. Pour les salles de concert, des sorties audio professionnelles sont prévues. Le jeu sur Sampo se fait à l'aide de pédales, ce qui rend cet outil plus maniable. De plus, son utilisation ne nécessite aucune connaissance technique préalable ni aucune installation logicielle. Les pédales servent d'interface de gestion de l'environnement électroacoustique. En fonction de l'œuvre jouée, les affectations des pédales permettent de contrôler directement des paramètres de processus temps réel (volume, temps de retard, transposition, etc.) ou / et la gestion des déclenchements de fichiers sons (arrêt, pause, déplacement en avant ou en arrière). C'est un dispositif qui se veut intuitif. Chaque geste (mouvements des pédales) affecte les paramètres du son de l'instrument, permettant ainsi au musicien d'appréhender immédiatement le résultat. Pouvant être utilisé pour la création sonore avec n'importe quel instrument acoustique, ainsi que dans les classes de composition, son ergonomie le rend particulièrement intéressant pour l'enseignement de la musique électroacoustique, des musiques actuelles et de l'improvisation dans les conservatoires et dans les écoles de musique<fnref n="4" />.

### 3.1. P-Soft

Une application autonome sur PC ou Mac est en préparation pour les utilisateurs qui désirent créer des configurations et des pièces pour Sampo. Il s'agit principalement des compositeurs ou des enseignants et des élèves de classes de compositions dans les conservatoires. Une configuration est l'ensemble des modules de traitement temps réel avec un parcours audio spécifique contenant les assignations entre les pédales et les différents paramètres que contiennent les modules. Chaque œuvre possède sa propre configuration.

<figure><img src="image_93.png" /><figcaption>**Figure 2.** Boîtier/unité de traitement – élément principal de Sampo</figcaption></figure>

L'application est un éditeur de configurations pour Sampo et son rôle principal est de rassembler tous les éléments nécessaires pour une pièce. La principale différence avec Sampo est la possibilité d'ajouter et d'organiser les fichiers sons d'une pièce, ainsi que tous les autres fichiers qui accompagnent la pièce, comme une partition PDF ou un exemple sonore de la pièce.

En effet, les fichiers sons utilisés pour la pièce contiennent des marqueurs ajoutés par l'utilisateur. Ces marqueurs déterminent les endroits dans les fichiers sons où l'interprète peut intervenir sur leur déroulement. Une fois que l'utilisateur a édité les fichiers sons et ajouté les marqueurs aux endroits voulus – au minimum un marqueur au début de chaque fichier son pour le déclencher – il dépose le fichier dans l'application. Il est aussi possible d'ajouter des fichiers sons « d'alerte audio » ou « click-track ». Ce sont des fichiers qui produisent des impulsions pendant la lecture de fichiers sons. Ces impulsions sonores sont envoyées vers le casque connecté au Sampo.

<footnote n="3">³ Écart à l'Equilibre pour violon et Sampo (Arturo Gervasoni) :
https://www.youtube.com/watch?v=v7y7OvpoakQ</footnote>

<footnote n="4">⁴ https://www.youtube.com/watch?v=_3h_J3TRuX0 et
https://www.youtube.com/watch?v=jGqrcVoY07g</footnote>
L'application est reliée à l'utilisateur et à la machine
hôte et se connecte directement sur son compte
utilisateur de la base. Contrairement au Sampo,
l'utilisateur ne peut télécharger sur son ordinateur que
les pièces qu'il a lui-même créées.

4. BASE DE DONNEES

La base de données est un élément central du projet
et de la mise en place du réseau des Sampos et de leur
interconnexion mutuelle. La nécessité de ce réseau est
apparue avec les prototypes de Sampos fabriqués entre
novembre 2014 et mai 2015.

En effet, l'un des avantages matériels de Sampo est la
possibilité de l'envoyer par la poste, comme n'importe
quel instrument, aux interprètes ou compositeurs dans le
monde entier. Il garantit la restitution exacte dans les
deux endroits, mais à la condition de disposer des
mêmes configurations et des fichiers nécessaires pour
l'exécution de la pièce.

Or, lors de la préparation d'un concert, il est fréquent
de changer les œuvres et en demander d'autres qui ne
soient pas présentes localement sur Sampo. Le problème
qui se pose alors est que la configuration interne change
en fonction de l'œuvre que l'on veut jouer et ceci
nécessite de trouver un moyen d'accès aux
configurations et fichiers nécessaires pour les œuvres
directement à partir de Sampo. Chaque Sampo dispose
d'une connexion Wifi, ce qui permet de déposer
manuellement les configurations et les fichiers
directement à partir de la base centrale (Figure 3) et
sans l'intervention du musicien. Avec quelques
prototypes il était ainsi possible de gérer les dépôts des
configurations manuellement pour chaque Sampo.
Toutefois, l'évolution actuelle, c'est-à-dire la fabrication
des Sampo en séries, nécessite une autonomie de gestion
des contenus de Sampo.

Nous avons donc mis en place le projet d'une base en
ligne, actuellement en cours, sur laquelle les Sampos se
connectent automatiquement à partir du moment où ils
ont accès à internet. Pour l'utilisateur de Sampo, l'accès
à la base est totalement transparent et en absence de
connexion l'utilisateur ne parcourt que la base locale.

<figure><img src="image_94.png" /><figcaption>Figure 3. Affichage de la base dans la fenêtre sur Sampo.</figcaption></figure>

Une fois connecté, l'affichage inclut la base centrale
où l'utilisateur peut récupérer les configurations des
œuvres dont il souhaite faire l'acquisition. Ainsi, le
terminal Sampo se connecte sur la base, affiche son
contenu pour permettre les uploads et downloads des

configurations des utilisateurs. L'utilisateur qui travaille
avec Sampo peut facilement créer et gérer des pièces,
les déposer sur le serveur ou télécharger les pièces
publiques ou celles partagées avec lui. La seule limite
consiste en l'absence de possibilité d'édition des fichiers
son et des partitions. Le logiciel P-Soft possédant des
fonctionnalités d'édition plus poussées, permet de
préparer les configurations et le contenu pour la base.
Ces deux outils sont donc complémentaires.

Sampo dispose de trois fenêtres d'accès à la base de
données en ligne :

• liste des pièces

• détails de la pièce

• gestion de partage dans les groupes

Les deux premières permettent de faire la recherche
et d'accéder aux détails de la pièce. La troisième fenêtre
affiche les outils pour la gestion de partage de la pièce et
la création des groupes d'utilisateurs.

Cela permet à un compositeur d'écrire une pièce pour
un interprète (avec Sampo ou avec le logiciel P-Soft)
qui soit à un autre endroit et de synchroniser leur travail
(les fichiers de configuration et fichiers son) par réseau.

4.1. Structure & terminologie

La base se compose de quatre principales tables :

• utilisateurs

• Sampos

• pièces

• compositeurs

4.1.1. Utilisateur

L'utilisateur s'inscrit dans la base, son compte est
créé, et il lui est possible d'accéder aux « pièces » dont
il a la permission. L'utilisateur peut aussi créer lui-
même les pièces. L'utilisateur est lié ou non à un
Sampo. S'il est lié, alors Sampo effectue la connexion
automatique à la base et présente à l'utilisateur l'état de
son compte. L'utilisateur peut recevoir l'application qui
émule Sampo dans le but de composer pour Sampo.
Ceci veut dire assembler les fichiers nécessaires pour
une configuration et les télécharger sur la base pour les
rendre accessibles aux Sampos.

4.1.2. Pièce - configuration

La « pièce » ou configuration est un ensemble des
fichiers et de leurs liens pour présenter et exécuter une
œuvre avec Sampo. Ceci concerne le fichier de
configuration interne des effets et leurs affectations aux
pédales, les fichiers sons avec les marqueurs, fichier
PDF de la partition, fichier d'un enregistrement,
informations sur la pièce telles que date de composition,
instrumentation, description, etc.

L'utilisateur peut créer lui-même des pièces sur son
Sampo et les déposer sur le serveur. L'utilisateur peut
voir le contenu de la base visible - ce sont les pièces des
compositeurs. Un compositeur est lié à une ou plusieurs
pièces.
### 4.1.3. Compositeur

L'utilisateur n'est pas compositeur par défaut, mais il peut demander la création d'un profil compositeur avec son nom et les données qui lui seront demandées, comme biographie, photo, adresse, etc. Une fois le profil créé après vérification des données, l'utilisateur obtient l'accès à la création des pièces au nom du compositeur en question.

### 4.1.4. Relations : utilisateur/pièce/compositeur

Il peut y avoir en conséquence un ou même plusieurs utilisateurs qui écrivent des pièces au nom d'un compositeur. Il s'agit alors de « transcriptions » des pièces existantes pour un compositeur qui lui, en tant que personne physique, peut ne pas être utilisateur de la base.

Les pièces des compositeurs, contrairement aux pièces des utilisateurs, peuvent être déclarées publiques. Ceci veut dire que la pièce est verrouillée et qu'il n'est plus possible d'y faire de modifications. À partir de ce moment, la pièce devient alors visible pour tous les utilisateurs. Les utilisateurs peuvent voir les données de la pièce telles que titre, instrumentation, extraits sonores, extrait de partition, etc. L'accès à la partition de la pièce dans sa totalité est décidé par le compositeur. Cet accès peut être l'accès en libre téléchargement ou l'achat de la partition chez l'éditeur.

L'accès à la configuration de la pièce se fait au cas par cas. Si la pièce est déclarée libre par le compositeur, l'utilisateur peut télécharger la configuration immédiatement sur son Sampo. Si la partition de la pièce est éditée, il est possible que l'éditeur mette à la disposition libre les éléments pour jouer la partie électronique de la pièce, fichiers sons ou patchs, et dans ce cas le téléchargement de la configuration est disponible. Si l'éditeur fournit les éléments pour jouer la partie électronique uniquement avec l'achat de la partition, la configuration n'est disponible pour l'utilisateur qu'après son achat auprès de l'éditeur.

### 4.1.5. Groupes

Après avoir créé une pièce en dehors d'un profil compositeur, l'utilisateur est le seul à pouvoir la visualiser et éditer sa configuration. S'il crée la pièce avec l'application, et s'il est lié en même temps à un Sampo, il peut voir sur Sampo sa pièce et la télécharger.

S'il le souhaite, l'utilisateur peut partager sa pièce pour plusieurs utilisateurs et Sampos. Ce partage s'effectue à travers la création de groupes à partir de la pièce existante. Il est donc seulement possible de créer un groupe pour partager une pièce que l'utilisateur a créée, et il n'est pas possible de créer un groupe sans pièce.

Pour créer un groupe, l'utilisateur crée ou sélectionne sa pièce et ensuite choisit les utilisateurs ou les Sampos qui vont faire partie du groupe. L'utilisateur choisit si les membres du groupe peuvent modifier la

configuration ou uniquement la lire. L'utilisateur peut créer un groupe pour chaque pièce. Si la pièce est effacée, le groupe l'est aussi.

L'utilisateur peut créer plusieurs groupes à partir d'une pièce. Chaque groupe peut contenir des utilisateurs et Sampos différents et chaque groupe est autorisé ou non à modifier la pièce. La dernière modification de la pièce sur le serveur est récupérée pour tous les utilisateurs du groupe.

Le groupe est une solution pour travailler à distance sur des pièces non publiques. Ceci est particulièrement utile dans le cadre d'une création de la pièce où le compositeur travaille avec le logiciel et l'interprète travaille chez lui avec son Sampo. L'utilisateur/compositeur crée une pièce et aussi le groupe dans lequel il inclut soit l'interprète utilisateur, soit le Sampo. La pièce est alors visible à partir du compte de l'utilisateur/interprète ou de son Sampo. L'utilisateur/compositeur peut changer la configuration en fonction des remarques de l'interprète qui peut même avoir la possibilité de changer les paramètres dans la configuration et échanger ainsi avec le compositeur.

Un autre but de la création des groupes est le travail collaboratif dans les conservatoires. C'est un moyen simple et efficace pour faire travailler les pièces des élèves des classes de composition aux élèves instrumentistes. De plus, les groupes permettent d'inclure d'autres conservatoires pour échange des pièces.

## 4.2. Accès à la base

### 4.2.1. Environnements

La base des pièces mixtes est accessible à partir de trois environnements (Figure 4) :

<figure><img src="image_95.png" /><figcaption>**Figure 4.** Environnements et accès à la base en ligne de RéDi-Musix.</figcaption></figure>

Le premier accès se fait directement à partir de Sampo où l'utilisateur peut faire des recherches, téléchargements, mises à jour des pièces existantes, création de nouvelles pièces et leur dépôt dans la base.
De même, l'application P-Soft, destinée principalement aux compositeurs, permet la connexion à la base avec le login de l'utilisateur qui installe l'application. Si l'application permet d'envoyer les fichiers sons ou PDF, elle ne peut en revanche recevoir que les « pièces » composées par l'utilisateur lui-même.

Enfin, il est possible de se connecter à la base à partir d'un navigateur internet. Dans ce cas, l'utilisateur peut accéder aux informations dans son espace personnel, c'est-à-dire aux œuvres dont il dispose et à l'impression des fichiers PDF des partitions à partir de son espace.

### 4.2.2. Espace personnel

Le contenu de la base est en grande majorité accessible uniquement aux utilisateurs inscrits. Le public ne peut se connecter à la base qu'à partir d'un navigateur et n'a accès qu'aux informations générales, comme la liste des compositeurs ou des pièces, la possibilité de faire des recherches dans la base, mais il ne peut pas télécharger les partitions ou déposer de nouvelles pièces.

Un utilisateur inscrit peut accéder à son espace où il peut télécharger les partitions libres, modifier les pièces qu'il a créées, déposer les nouvelles pièces privées, etc.

### 4.2.3. Navigateurs

L'accès le plus simple à la base s'effectue à travers un navigateur internet sur n'importe quel ordinateur ou tablette. La base est présentée sur le site pour être librement consultable. Seules les informations de base sur la pièce sont proposées comme les titres, instrumentations, extraits de partitions ou exemples sonores. L'utilisateur inscrit dans la base a, en plus, l'accès au téléchargement des partitions libres déposées par les compositeurs.

## 5. LE SERVICE CENTRALISE DE DISTRIBUTION DE CONTENUS/CONFIGURATIONS

Le but du projet est, entre autres, d'interconnecter les conservatoires et les écoles de musique et permettre l'échange et la création d'œuvres pédagogiques de la musique mixte, facilitant ainsi la diffusion des contenus culturels. Pour cela nous avons mis à disposition dans les établissements partenaires des terminaux Sampo - sur lesquels il est possible de jouer et composer la musique mixte dans les mêmes conditions et avec les mêmes résultats sonores dans tous les lieux. La distribution des configurations/compositions sur les terminaux (Sampo) se fait au travers d'un serveur et d'une base de données. Cette base est alimentée d'une part avec des pièces du répertoire et d'autre part par les compositeurs-élèves durant toute l'année scolaire. Les pièces pédagogiques sont ainsi disponibles dans tous les conservatoires disposant d'un Sampo. Les pièces composées sont immédiatement mises à la disposition

de tous les partenaires du projet et travaillées par des enseignants et étudiants de ces établissements.

## 6. COMMUNAUTE D'UTILISATEURS

Nous avons, actuellement, un total de 8 partenaires culturels (Figure 5) dans le cadre du projet. La carte ci-contre représente les villes dont les conservatoires se joignent au déploiement du réseau de service RéDi-Musix.

<figure><img src="image_96.png" /><figcaption>**Figure 5.** Carte des partenaires du projet RéDi-Musix.</figcaption></figure>

Voici la liste des partenaires du projet :

* Conservatoire d'Annecy (CRR)<fnref n="5" />

* Conservatoire Massenet à Saint-Étienne (CRR)<fnref n="6" />

* Conservatoire de Saint-Nazaire (CRD)

* Conservatoire de Nantes (CRR)

* Conservatoire Francis Poulenc de Tours (CRR)

* Conservatoire de Noisy-le-Sec (CRC)

* Conservatoire du 9e arrondissement de Paris (CRC)

* Curso de Música Silva Monteiro à Porto (Portugal)

Dans chaque établissement nous avons mis en place une équipe composée d'enseignants d'instruments (par exemple, flûte, violon, clarinette...) et de leurs élèves, ainsi que d'enseignants de composition avec leurs élèves qui composeront pour les divers instruments acoustiques accompagnés du terminal Sampo.

### 6.1. Pratique dans les conservatoires

Sampo permet de sensibiliser les instrumentistes aux musiques électroacoustiques, mixtes, improvisées, contemporaines, jazz... en puisant dans le répertoire déjà écrit. Comme avec son instrument acoustique, le musicien est invité à écouter le son qu'il produit et réfléchir à la manière d'obtenir un effet particulier. Un click-track et la possibilité de se déplacer à volonté dans

<footnote n="5">⁵ https://www.youtube.com/watch?v=ArRLnUfrzB4</footnote>

<footnote n="6">⁶ https://www.youtube.com/watch?v=6av2w8UbjOA</footnote>
le fichier son sans quitter l'instrument de ses mains,
facilitent le travail du musicien.

## 6.2. Catégories de pièces

Les pièces - ensembles de configurations électroacoustiques et de contenus fixes - sont accessibles à travers de l'interface graphique sur l'écran tactile de Sampo. Une fois sélectionnée, la pièce est chargée et immédiatement prête à être jouée.

Deux catégories de pièces sont travaillées dans le cadre du projet.

En premier lieu, les compositeurs et les élèves dans les classes de composition composent de courtes pièces pédagogiques mixtes pour les instruments choisis au début du projet. Ces pièces sont placées sur le serveur à la disposition de tous les autres établissements pour les classes d'instruments. Les élèves de tous les établissements peuvent ainsi préparer les pièces pour les concerts de restitution qui auront lieu à la fin du projet.

En plus des pièces nouvellement composées pour l'occasion, les étudiants et les enseignants peuvent travailler les pièces mixtes déjà existantes et qui sont ou seront transcrites pour le terminal Sampo. Les pièces sont disponibles sur le serveur et sont distribuées directement sur le terminal à la demande des établissements. Les musiciens avec les instruments acoustiques pourront ainsi interpréter les pièces dans des conditions identiques dans tous les établissements en France ou à l'étranger.

## 7. EXEMPLE D'UNE ACTION PEDAGOGIQUE

Les *Reflets*<fnref n="7" /> (2000-2002) et les *Contemplations*<fnref n="8" /> (2004) sont deux ensembles de pièces pédagogiques, pour instrument solo et support fixe commandés par le Conservatoire de Bagnolet. Ces pièces ont été composées pour initier de jeunes instrumentistes au jeu avec l'électronique, et conçues en étroite collaboration avec les professeurs d'instruments. Malgré la volonté de faciliter au maximum la mise en œuvre des pièces, prenant le soin de les adapter au niveau des étudiants, en concevant une électronique qui tenait sur un CD et un CD d'étude avec une piste métronome, la mise en route de ces œuvres et leur étude et performance étaient toujours complexes. Insérer un CD dans la chaine, le

besoin d'une deuxième personne pour démarrer la lecture du CD et le déroulement complexe des répétitions et séances d'étude (arrêt, « fast forward » ou « rewind » pour caler le CD sur des positions temporelles précises correspondant aux mesures) freinaient le travail des élèves.

Lors d'une réalisation au Conservatoire de Saint-Nazaire (02/12/2017), nous avons pu constater que l'environnement proposé par RéDi-Musix avec le Sampo permettait un accès plus simple et direct aux œuvres. Il est aisé au jeune musicien de démarrer la bande à la pédale, arrêter et pouvoir choisir une mesure pour redémarrer, jouer avec ou sans click-track. Autant l'étude que la répétition pour le concert se fait avec aisance de la part de l'instrumentiste. L'environnement proposé s'est montré efficace permettant une approche directe des courtes pièces, évitant de confronter les jeunes instrumentistes à des problèmes techniques hors de leur intérêt et du contexte musical, leur permettant un accès direct à l'interprétation.

D'autres actions pédagogiques de ce type dans les conservatoires partenaires confirment la pertinence de la solution de jouer les œuvres mixtes avec le terminal Sampo.

## 8. CONCLUSIONS

La musique mixte, avec des éléments temps réel et/ou avec des supports fixes, est actuellement tributaire de la mise en place d'environnements matériels et logiciels qui, par leur complexité et la nécessité de connaissances techniques spécifiques, découragent souvent les interprètes. En plus, l'agencement et la mise en marche de ces environnements est souvent chronophage, laissant peu ou pas de place à l'interprétation musicale, cela même pour des œuvres dites « pour bande ». La mise en place d'environnements matériels et logiciels est au même niveau que la lutherie pour un interprète qui ne fabrique pas l'instrument sur lequel il joue. Il y a donc une claire différence entre les compétences nécessaires pour les deux métiers.

On constate que ce n'est pas le type de répertoire, mais son inaccessibilité qui est la raison principale de son absence chez les interprètes. Ce que nous avons remarqué ces derniers mois est le fait que proposer aux interprètes, professeurs d'instruments et élèves d'instrument un environnement de travail dans le contexte de RéDi-Musix (comprenant la base de données et le terminal Sampo), leur a permis un accès à ces musiques aussi simple qu'ouvrir une partition pour en faire une lecture.

Pour la suite du projet, nous prévoyons de stabiliser la base de données pour l'alimenter ensuite avec des transcriptions des pièces de répertoire existant et ainsi contribuer à la pérennisation de ce répertoire.

Concernant les prochaines étapes, nous prévoyons de définir un protocole de transcription d'œuvres mixtes pour Sampo et de le proposer aux partenaires intéressés par ce type de travail. En parallèle, nous allons élargir les possibilités du logiciel Sampo en y autorisant

<footnote n="7">⁷ Cinq reflets sur fond bleu (2000), Mikhail Malt. Cinq pièces pédagogiques pour piano, hautbois, saxophone alto, violoncelle, violon et électronique sur support fixe. Création décembre 2000 à l'auditorium de Bagnolet. Et Le sixième reflet (2002), Pièce pédagogique pour batterie et électronique sur support fixe. Commandes du Conservatoire de Bagnolet.</footnote>

<footnote n="8">⁸ Six contemplations (2004), Mikhail Malt. Six pièces pédagogiques pour trompette, flûte, alto, guitare, clarinette et électronique sur support fixe. Commande du conservatoire de Bagnolet. Création avril 2005 à l'auditorium Pablo Neruda de Bagnolet, direction Wim Hoogewerf.</footnote>
l'intégration de patchs Max. Ainsi, Sampo permettra de
jouer les pièces avec fichiers son, les pièces avec accès
gestuel, et enfin, les pièces avec déclenchements
d'évènements.

9. REFERENCES

[1] Barthélemy, Jérôme; Bonardi, Alain; Orlarey, Yann; Lemouton, Serge; Ciavarella, Raffaele; Barkati, Karim. (2010). "Toward An Organology Of Virtual Instruments" In *Computer Music. 369-372.*

[2] Bonardi, Alain (2015) « Rejouer une œuvre avec l'électronique temps réel : enjeux informatiques et musicologiques » *Genèses musicales*, Presses de l'Université Paris-Sorbonne, pp. 239-254.

[3] Bonardi, Alain (2013) « Copier/coller ou recopier ? La transmission entre artistes des œuvres musicales avec dispositif numérique » In *Technique et science informatiques* Volume 32 - n° 3-4.

[4] Bonardi, Alain; Barthelemy, Jérôme (2008) “The preservation, emulation, migration, and virtualization of live electronics for performing arts: An overview of musical and technical issues”, *Journal on Computing and Cultural Heritage*, 1, 1, p. 6:1-6:16

[5] Lemouton, Serge (2016). La préservation des œuvres musicales du répertoire de L'ircam : présentation du modèle Sidney et analyse des dispositifs temps réel. *Computer Music Interpretation In Practice*.

[6] Lemouton, Serge; Ciavarella, Raffaele; Bonardi, Alain (2009) “Peut-on envisager une organologie des traitements sonores temps réel, instruments virtuels de l’informatique musicale?”, *Proceedings of the Fifth Conference on Interdisciplinary Musicology (CIM09)*, Paris.
# MUSIC FROM AURA: MUSIC GENERATION USING EEG AND KIRLIAN PHOTOGRAPHY FOR TEMPORAL DIFFERENCE LEARNING

Pierre-Henri Vulliard

SCRIME/LaBRI

pierre-henri.vulliard@u-bordeaux.fr

## ABSTRACT

Our aim is to fill the gap between computer music and musical emotions. We use a 2D emotional space (2D ES) both to analyze listener's emotions captured from physiological measure and to drive a music generator with a Reinforcement Learning algorithm. We present hereafter the Reinforcement Learning algorithm and the different parts of our framework used as input (emotions classification with Emotiv EEG headset and Kirlian photography device, to improve the machine learning by using data that have no correlation between them), and output of the algorithm (rhythm and scale/chords generation). Some current and future applications are also briefly depicted.

## 1. INTRODUCTION

*How to represent emotions both in music and in brainwaves analysis:* The most used model is the representation of emotions in 2D valence/arousal space, where valence represents the way one judges a situation, from unpleasant to pleasant and arousal expresses the degree of excitement felt by people, from calm to exciting [1].

*Emotions as a model for the interaction between brainwaves and music:* Numbers of experimentations have been pursued for the sonification of brainwaves. However, the fuzzy aspect of both music and emotions spaces makes traditional algorithms inefficient. Thus we choose for this experiment two more appropriate algorithm from Reinforcement Learning family, QLearning and Sarsa(λ) [2].

One characteristic of our work is to include machine learning tools with a great symmetrical between its inputs (listener's emotions captation from his brainwaves analysis) and its outputs (music generation based on emotionnaly connoted parameters). From an algorithmic point of view, this symmetry has no particular meaning; but beyond a purely artistic approach, it should create conditions for a retroactive loop, it is widely admitted that music has an undisputable influence upon listener's mood and emotion, and numerous studies have adressed its effect [3, 4].

## 2. REINFORCEMENT LEARNING

### 2.1. Reinforcement Learning features

Reinforcement learning (RL) is learning by interactions with the environment. Its aim is, roughly speaking to map situations to actions in order to maximize a numerical reward signal. Clearly, a learning agent must be able to sense the state of the environment and to take actions that affect this state, and it also needs a goal to achieve. Temporal difference learning (TD) is a combination of Monte Carlo approach and Dynamic Programming. As for the Monte Carlo approach, TD can learn directly from the experiment (no need of a model of the environment dynamics), and as for the Dynamic Programming approach, TD updates its estimate based on prior estimation without waiting the end of the experiment and the final outcome.

### 2.2. Interest of Reinforcement Learning for music

**Bio-mimetism:** Reinforcement Learning methods take their insight from animal psychology studies, like those analy- sing how an animal can learn from trial and error to adapt to its environment, or those based upon language learning.

They are from the family human-like algorithms, and so seem well adapted to musical language learning.

*Ways emphasis vs single target:* One of the special features of the algorithm is that, in addition to the final target (tonic for tonal resolution), it also takes into account paths (harmonic walks).

*Early effectiveness:* Reinforcement learning differs from standard supervised learning in that correct input/output pairs are never presented, so it does not need prior calibration, and can be effective since early bars of music.

*Short or long term optimisation:* One of the properties of the RL approach is the trade-off between exploration (of uncharted territory) and exploitation (of current knowledge). This is a way of optimising for a fast result or for a long term optimised solution. *Poietic process:* Could help to describe musical rules directly from their attributes, for example using functional value of chords (dominant preparations, dissonances, resolutions) in mainstream tonal music based on tension/relaxation.

<figure><img src="image_97.png" /></figure>
## 2.3. Reinforcement Learning in MuZICO

A module of Reinforcement Learning is implemented in MuZICO as a PureData interface using C++ functions

Following [2] a RL task can be expressed as a Markov Decision Problem (MDP) provided that we assume decisions and values to be functions of the current state only. At each discrete time $t$, the agent observes the environment state $s_t$ - in our case it is the projection of EEG signal of the listener into the 2DES. It selects an action $a_t$ - in our case the musical parameters driving the music generation. The action is performed and one step later (time $t+1$) the agent receives a reward $r_{t+1}$ and reaches a new state, the reward is the distance between the classification of the EEG signal projected in the 2DES space and the goal to reach. The last component is the policy $\pi_t$ where $\pi_t(s, a)$ is the probability that $a_t = a$ when $s_t = s$ which is used to update the estimates.

Choice for the Reinforcement Learning algorithm are: five parameters (temperature, epsilon ($\epsilon$), lambda ($\lambda$), earningRate ($\alpha$) and gamma ($\gamma$)), two possible policies (egreedy and softmax), two learning methods (qlearning and sarsa).

Temperature and $\epsilon$ are parameters for the policies, $\alpha$ is the learning rate used to update the expected reward of the states, $0 \le \lambda \le 1$ is the parameter which drives the number of states updated ($\lambda = 0$ the state updated is $s_t$; $\lambda = 1$ states $s_0, \dots, s_t$ are updated). $0 \le \gamma \le 1$ is the discount factor used to compute the long run reward, if $\gamma = 0$, the agent maximizes the immediate rewards.

# 3. ACTIONS

## 3.1. Muzico

The actions are changes of the generative music settings to aim a target emotion. According to [5], the musical parameters related to the valence of emotions induced by music are tonality and complexity. We propose here harmonic, rhythmic and melodic generative models, as well as a description of their parameters from the point of view of musical complexity.

These parameters, as they are used in the MuZICO environment, have either discrete or continuous values, and are either defined by adjectives (fuzzy classes) or by numerical values. For example, the spectrum of a sound can take values from “muted” to “bright”, corresponding to specific energy values that are measurable in the signal and are linked to its spectral centroid. The other parameters related to energy in music are: the tempo of the music, the attack of the notes’ dynamic envelope, the pitch of the notes, the number of instruments playing simultaneously, the more or less “natural” sound of the instruments, the percussive or sustained aspect of sounds, as well as the number of simultaneous notes [5].

All these parameters are characterized by bounded intervals used by MuZICO to generate music. Those values, corresponding to low and high energies induced by the music, can be fuzzy values (such as muted, bright) or in-

tervals for physical data. The parameters that have undefined units are translated by MuZICO into various units according to the algorithms used to produce the sounds (synthesis, sample playing, audio effect control). For instance one can translate the brightness of a sound by a particular setting of the modulation index in a FM synthesis algorithm, or by the control of the cutoff frequency of a low-pass filter applied to a sample player.

### 3.1.1. Pitch scales

Usually scales are generated by an integer as interval, following Eq. 1.

$$ \left\{ \begin{array}{l} U_{n+1} = (U_n \times \omega^{\frac{V}{\theta}} - U_0) \times \omega^{-p} \\ U_0 = f_f \\ \text{with } p \in \mathbb{N}^+ \text{ such that } U_0 < U_{n+1} < \omega \times U_0 \end{array} \right. \qquad (1) $$

where $\omega$ is the octave ratio, $\theta$ the divider of the octave to obtain the temperament, $f_f$ is the root frequency of the generated scale, and $V$ the interval seed of the scale.

We consider that the complexity of a pitch scale relies on the number of iterations needed to generate it, and on the values of the different parameters $\omega, \theta$, and $V$.

For example, taking $\omega = 2$, $\theta = 12$ (tonal occidental music). Let $V = (7)$ (generation of the pitch scale by iterating through steps of fifths), and $N$ be the number of iterations. This gives: the pentatonic scale or the Maj 6/9 chord for $N = 4$, the diatonic scale for $N = 6$, the chromatic scale for $N = 11$

These scales have an increasing harmonic complexity.

Scales of different complexities can be generated by varying $V$: $V = (4)$ and $N = 2$ generate a pitch scale corresponding to an augmented chord, $V = (3)$ and $N = 3$ give a diminished chord, $V = (3, 4, 4, 3)$ and $N = 6$ give the ascending melodic minor scale.

### 3.1.2. Rhythmic patterns

To keep a human-like style in beat generation, we model our inspiration upon the rhythms accompanying work songs during community repetitive labour, as activities in the field (threshing and winnowing) or domestic work (the pestle pounding the mortar). Each participant produces one single regular beat but the collective result is a more complex rhythm.

The rhythmic patterns are created by layering various iterative rhythmic patterns, all synchronized to the same underlying pulse, each pattern being defined by an offset from the common initial pulse and by a rhythmic density (number of pulses between two onsets in the pattern). The superimposition is done by a logical OR operation, considering the superimposed patterns as bit vectors, a value of 1 representing an onset, and a value of 0 no onset:

$$ \begin{aligned} \text{density} = 0 \text{ offset} = 0 & \rightarrow 11111111 \\ \text{density} = 0 \text{ offset} = 2 & \rightarrow 00111111 \\ \text{density} = 1 \text{ offset} = 2 & \rightarrow 00101010 \\ \text{density} = 3 \text{ offset} = 0 + \text{density} = 5 \text{ offset} = 3 \\ 10001000 + 00010000 = 10011000 \end{aligned} $$
For the rhythmic complexity, we use a model based on Toussaint's complexity measure [6] or other techniques of rhythmic complexity evaluation, that assign a weight to each pulsation.

## 3.2. Generative attributed grammar

**Chords series:** In MuZICO, the chords sequences generation takes the context into account to oversee the transpositions related to the modulations. The complexity of a chord depends on several factors that we identified: the number of notes that make it up, the complexity of the scale on which it is built, the order of appearance of its notes in the building of this scale by iterations. The complexity of a chords sequence also depends on several factors: the complexity of the chords that make it up, the number of different chords in the sequence, the harmonic complexity of the chords sequences, mainly taking into account the cadences and resolutions in the context of modern modal and tonal music, and the modulations in the context of the latter.

# 4. REWARD

Reward is calculated from Arousal and Valence axis of emotions, according to the Two-Dimensional Emotion Space (2DES) [1]. It is the distance between the current projection of the classification of the EEG to the final state at aim in the 2DES.

### 4.1. Emotions caption system

**Hardware:** As the title of the poster indicates, we use different sources for data acquisition: EEG headsets, connected watches, G.D.V (kirlian photography). Since the data is digital, the most scientific data (EEG, pulse) should make it possible to evaluate the relevance of the more fanciful data (aura, meditation analysis by Emotiv helmet). For EEG, we use an Emotiv headset for its convenience and its growing dissemination. We acquire data from the headset with the Emotiv C++ SDK, and transmit them via UDP protocol for further use.

**Software:** OpenViBE software[7], designed for Brain Computer Interface work, provides all the necessary tools we need for our experiment setup.

## 4.2. EEG Data Analysis

**Filters:** First level is managed by the Emotiv headset itself. By request to the C++ api, we receive two types of data from the sensors: on one hand, raw data on the fourteen channels, on the other hand, filtered face muscles information (EMG), i.e. bottom or upper face tensions. In OpenViBE software. EEG data channels are sorted and a first stage of band filters is applied, according to traditional brainwaves categories. Then comes the Common Spacial Pattern (CSP) filter stage, to improve the classification [8]. A CSP filter of dimension four is used for each band of brainwaves.

# 5. EXAMPLES OF APPLICATIONS

## 5.1. Short term convergence: Live Music Performing

**Saxophone and generative music:** Interactive music is used in real time in a saxophone improvisation show, (sometimes with dance and video projections).

## 5.2. Long term convergence: Relaxation, Music Therapy

Aware of the highly controversial statements coming from the alternative medicine community about audio stimulations which may help to induce relaxation, meditation, creativity and other desirable mental states, we implemented, nevertheless, some of these stimulations and synchronized them with the music beat.

The main clock of MuZICO calculates equivalences of tempo in BPM, duration of 16th notes, and difference in Hz for binaural beats. For instance, if bpm=120, the 16th note duration is 0.125 second, the isochronic sounds have a frequency of 8 HZ, and the left/right binaural beats channels are respectively raised and lowered from 8/2 = 4Hz.

Some of the mostly used audio processes:

**ASMR (Autonomous Sensory Meridian Response):** Rhythmic noises and sounds used to provoke a pleasant sensation of tingling or chills in the skull or scalp, or as a sleep aid.

**Mindmachines:** Audio impulsions are generated on an independent stereo output to control flashing leds glasses to make a "brainwave synthesizer" (or "mindmachine").

**Binaural beats:** Binaural beats, or binaural tones, are auditory processing artifacts, or apparent sounds, produced by a slight difference in the frequencies percieved by each ear of the same tone.

**Isochronic sounds:** Isochronic tones are evenly spaced tones, quickly turned on & off;

# 6. CONCLUSION - FUTURE WORKS

In this poster we presented the MuZICO framework and the core learning algorithm as an attempt to fill the gap between computer music and musical emotions.

Preliminary results have shown that a musical construction can be deduced from EEG analysis and Reinforcement Learning. The difficulty which remains is to assert that the state reached in the 2DES is effectively the intended real emotional state.

Exploratory experiments of various scenarii evaluating the different parameters of the MuZICO framework (LDA, CSP, TD on-policy, TD off-policy, long run rewards such as maximum valence and maximum arousal for music shows, or maximum valence and minimum arousal for relaxation) are undergoing.

The operation of the algorithm requires a large amount of data, so we created a smartphone app called Personal Hypno Vibes for listening to music and to acquire physiological data in various use cases (meditation, self-hypnosis, tests on the aura).
7. REFERENCES

[1] E. Schubert, "Measuring emotion continuously: validity and reliability of the two dimensional emotion space." *Australian Journal of Psychology*, vol. 51, no. 3, pp. 154-165, 1999.

[2] R. S. Sutton and A. G. Barto, *Reinforcement Learning: An Introduction*, 1998. [Online]. Available: webdocs.cs.ualberta.ca/~sutton/book/the-book.html

[3] L. B. Meyer, *Emotion and Meaning in Music*. University of Chicago Press, 1956.

[4] M. M. Bradley and P. J. Lang, "Affective reactions to acoustic stimuli." *Psychophysiology*, vol. 37, pp. 204-215, 2000.

[5] S. Livingstone, R. Muhlberger, A. Brown, and W. Thompson, "Changing musical emotion: A computational rule system for modifying score and performance." *Computer Music Journal*, vol. 34, no. 1, pp. 41-64, 2010.

[6] G. Toussaint, "Computational geometric aspects of rhythm, melody, and voice-leading." *Computational Geometry*, vol. 43, no. 1, pp. 2-22, jan 2010.

[7] Y. Renard, F. Lotte, G. Gibert, M. Congedo, E. Maby, V. Delannoy, O. Bertrand, and A. Lécuyer, "Open-vibe: an open-source software platform to design, test, and use brain-computer interfaces in real and virtual environments." *Presence: teleoperators and virtual environments*, vol. 19, no. 1, pp. 35-53, 2010.

[8] F. Lotte and C. Guan, "Regularizing common spatial patterns to improve bci designs: unified theory and new algorithms." *Biomedical Engineering, IEEE Transactions*, vol. 58, no. 2, pp. 355-362, 2011.
# LA THEORIE DE LA GRAVITATION TONALE

Emanuele Di Mauro

emanuele.dimauro@gmail.com

## RÉSUMÉ

La théorie de la gravitation tonale a comme objectif premier d'identifier les liens entre l'univers de l'harmonie (aspect vertical de la musique) et celui de la mélodie (aspect horizontal).

Ces liens sont obtenus grâce à l'application de trois principes mathématiques qui constituent la base du calcul algorithmique et combinatoire exploité par le logiciel en ligne www.gravitation-tonale.fr.

L'idée principale de la théorie est d'exclure de l'univers musical un son particulier, disharmonique et caco-phonique. Ce son, appelé *condensation tonale*, est constitué par la superposition de trois notes contiguës de la gamme chromatique.

L'étude faite par l'auteur montre que cette superposition est le seul son à 3 notes distinctes qui n'est jamais présent dans le corpus des accords connus, à la différence de n'importe quelle autre superposition de trois notes de la gamme chromatique pour laquelle on trouve toujours au moins un accord qui la contient.

## 1. LES TROIS PRINCIPES

L'exclusion de la condensation tonale est, avant tout, un principe harmonique. On considère l'harmonie non pas à travers des règles relationnelles entre les notes, mais en définissant une limite extrême, une frontière au-delà de laquelle le son ne peut plus être considéré harmonieux.

L'extension de ce *principe d'exclusion* à l'aspect horizontal de la musique donne lieu à un corpus de gammes dites « verticalisables ». Cela permet d'identifier tous les liens accords/gammes avec un simple *principe d'inclusion* : la gamme verticalisable doit contenir toutes les notes de l'accord avec lequel elle se lie.

Un troisième *principe de complétude* est appliqué à l'objet « gamme » : une gamme verticalisable est complète seulement si aucune note peut être ajoutée sans produire une condensation tonale<fnref n="1" />. Ce principe permet de définir une gamme sans aucune ambiguïté. N'importe quelle autre gamme non verticalisable peut toujours être obtenue par combinaison de deux ou plusieurs gammes verticalisables.

## 2. L'UNIVERS MELODIQUE PRIMAIRE

Si on considère le principe d'exclusion et le principe de complétude on peut facilement calculer toutes les gammes complètes possibles. L'analyse de ces résultats et l'association avec les gammes connues a conduit à identifier et classer ces gammes comme suit :

- Gamme majeure ou mineure «naturelle»

- Gamme mineure mélodique

- Gamme mineure harmonique

- Gamme majeure harmonique

- Gammes par ton

- Gammes par ton, demi-ton

- Gamme par demi-ton / tierce mineure

Ce corpus de gammes est appelé par la théorie « **univers mélodique primaire** ». Le principe d'exclusion de la condensation tonale peut alors s'appliquer à l'ensemble de tous les accords et aux gammes de l'univers mélodique dans un total de 57 transpositions (12 par gamme majeure ou mineure, 2, 3 ou 4 pour celles à transpositions limitées)

## 3. LA GRAVITATION TONALE

Dans une approche mathématique on recherche le moyen d'un processus de segmentation, où les accords sont groupés d'une façon telle que chaque groupe puisse exprimer un sens musical propre. Segmenter n accords veut dire trouver m groupes d'accords (**segments**), chacun constitué par un ou plusieurs accords. Le passage d'un groupe à l'autre doit exprimer un changement d'univers musical.

La question est alors d'identifier un processus capable de lier un segment à une ou plusieurs gammes et de déterminer les conditions nécessaires afin que cette association soit possible.

### 3.1 Définition

La segmentation d'une suite d'accords en segments conduit à la notion de « gravitation tonale ». Chaque groupe d'accords ainsi constitué est capable de générer des gammes verticalisables. Une gravitation tonale est donc identifiée par un centre de gravité (un ou plusieurs accords) et par toutes les gammes que ce centre de gravité peut produire. Chaque gamme doit contenir toutes les notes du centre de gravité qui l'a générée (principe d'inclusion). L'ensemble de toutes les notes du centre de gravité ne doit pas, alors, contenir de condensation tonale, car, pour le principe d'exclusion, aucune gamme verticalisable ne la contient. Une gravitation tonale ne

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

<footnote n="1">¹Par exemple la **gamme de Do majeur** est une gamme complète, car aucune autre note ne peut être ajoutée sans produire une condensation tonale</footnote>
peut donc exister que si aucune condensation tonale n'est présente dans l'ensemble de toutes les notes des accords qui constituent le centre de gravité.

## 3.2 Exemples

Les exemples suivants montrent les gravitations tonales pour la suite d'accords G | Am (Figure 1) et pour Dm | G7 (Figure 2):

<figure><img src="image_99.png" /><figcaption>Figure 1. Gravitation tonale pour les accords G | Am</figcaption></figure>

<figure><img src="image_100.png" /><figcaption>Figure 2. Gravitation tonale pour les accords Dm | G7</figcaption></figure>

# 4. LA SEGMENTATION

Un processus de segmentation est sensé fournir toutes les façons possibles de grouper les accords afin que chaque groupe d'accords puisse générer une gravitation tonale. Cette problématique aboutit, en général, à plusieurs solutions.

## 4.1 La segmentation atomique

Une première réflexion porte à dire qu'on peut toujours segmenter les accords dans des groupes ayant chacun un seul accord, et réaliser ce qu'on appelle une segmentation atomique. Chaque accord aura alors sa propre gravitation tonale et cela est toujours possible car aucun accord ne contient une condensation tonale.

## 4.2 Groupement des accords

La découverte des segmentations possibles découle de la segmentation atomique. Pour obtenir toutes les segmentations le processus est celui de grouper, si possible, les gravitations tonales adjacentes. Cela peut être fait si l'ensemble des notes des deux gravitations adjacentes ne contient pas de condensation tonale. Dans

l'exemple en figure 3 on applique cet approche à la suite d'accords : Am | A7 | Dm | G7 | C

<figure><img src="image_101.png" /><figcaption>Figure 3. Possible segmentation [Am] [A7 | Dm] [G7 | C] pour la suite d'accords Am | A7 | Dm | G7 | C</figcaption></figure>

# 5. LE CHOIX DES GAMMES

## 5.1 Problématique

Le processus de segmentation ne donne pas, en soi, d'informations sur les gammes utilisables pour chaque gravitation tonale. En général on peut imaginer une suite de m gravitations tonales comme une suite d'ensembles de gammes. Dans une logique purement combinatoire on obtient alors un nombre N de combinaisons de gammes qui est le produit du nombres de gammes $n_1, \dots, n_m$ associées à chaque gravitation tonale :

$$N = n_1 * n_2 * \dots * n_m$$

Une suite de 10 accords majeurs ou mineurs, par exemple, fournit plus de 60 milliards de combinaisons de gammes (chaque accord, mineur ou majeur est lié à 12 gammes verticalisables) :

$$N = 12^{10} = 61.917.364.224$$

Le processus de segmentation (Figure 4) est alors essentiel pour réduire considérablement le nombre de combinaisons des gammes impliquées. En effet la création d'une gravitation tonale entre 2 ou plusieurs accords fait augmenter les notes du centre de gravité, et cela réduit d'une façon considérable les gammes associées.

## 5.2 Le choix des gammes

Quoi qu'il en soit, le problème du choix des gammes s'impose à partir du moment où plusieurs gravitations tonales existent et s'enchaînent. On se doit de choisir la gamme qui sera utilisée dans chaque gravitation tonale. Or, le choix d'une gamme, pour une gravitation tonale donnée, ne peut pas se faire dans l'absolu, et il doit tenir compte des gammes liées aux autres gravitations tonales adjacentes. Pour cela, on exploite une notion de similitude entre gammes afin de choisir la combinaison des gammes qui rend minimale cette distance.
## 5.3 La similitude entre gammes

La similitude entre gammes doit donc faire l'objet d'un calcul mathématique aux caractéristiques suivantes :

* La comparaison entre une gamme g1 et une autre gamme g2≠g1 donnera lieu à un score qui ne sera pas maximal.

* La comparaison entre n'importe quelle gamme et elle-même (auto-similitude) devra avoir une valeur maximale et normalisée.

Ce deuxième point est important. N'importe quelle gamme doit avoir une auto-similitude normalisée.

<figure><img src="image_102.png" /><figcaption>Figure 4. Choix des gammes pour une segmentation donnée.</figcaption></figure>

## 5.4 Algorithme de similitude entre gammes

L'algorithme proposé par la théorie (qui n'a pas de valeur absolue, il s'agit d'une proposition ouverte) est alors le suivant :

* On considère deux gammes à comparer

* On part d'un indice de similitude de 0

* Pour chacune des 12 notes chromatiques (do, do#, ré...) on vérifie si la note est présente dans les deux gammes

* Si la note est présente dans les deux gammes l'indice de similitude est incrémenté d'une valeur 1.

* Si la note est absente dans les deux gammes l'indice de similitude est incrémenté d'une valeur 1.

* Si la note est présente dans une gamme, mais pas dans l'autre l'indice de similitude n'est pas incrémenté.

Le score obtenu va de 0 à 12. La valeur 12 est toujours le score d'auto-similitude. Ce score nous permet

alors de trier les résultats combinatoires par similitude, ou par moyenne de similitude, et éventuellement par variance de similitude. En triant par ordre décroissant, on obtient en premier lieu les résultats qui expriment les transitions les plus douces en passant d'une gravitation tonale à l'autre.

# 6. LOGICIEL EN LIGNE

## 6.1 Le logiciel gravitation-tonale

Le logiciel en lige gravitation-tonale.fr exploite les résultats de la théorie. Quatre outils sont mis à disposition, selon l'objectif visé :

**Objectif 1** : Déterminer à partir d'un accord, toutes les gammes possibles verticalisables liées.

**Objectif 2** : Déterminer, à partir d'une suite d'accords, si possible, toute les gammes liées.

**Objectif 3** : Obtenir à partir d'une suite d'accords toutes les segmentations possibles.

**Objectif 4** : Pour une segmentation donnée, obtenue en objectif 3, le logiciel propose toutes les combinaisons des gammes possibles, triées en ordre décroissant de similitude (moyenne et variance).

# 7. CONCLUSIONS

Sur des séquences d'accords issues d'un univers musical où on peut reconnaître une notion de tonalité globale ou locale, les liens accords/gammes obtenus en appliquant les trois principes de la théorie paraissent cohérents avec la vérité du terrain. Le logiciel suggère, par exemple, la bonne gamme diatonique, pour des séquences II-V, ou II-V-I, même en présence de modulations et de changements de tonalité.

Sur des séquences d'accords inhabituelles, où la notion de tonalité parait insaisissable, l'application des trois principes de la théorie conduit à des liens accords/gammes difficilement imaginables sans faire recours au calcul assisté par ordinateur. L'explosion combinatoire des résultats est fortement limitée par la segmentation automatique et par l'identification des gravitations tonales, chacune réduisant fortement le nombre des gammes impliquées.

Le logiciel gravitation-tonale, pourrait en premier lieu, être un support intéressant pour l'exploration de nouveaux univers musicaux, sur des séquences d'accords complexes. Mais il peut être aussi un support pédagogique valide sur des séquences classiques (sous-dominante, dominante-tonique, cycle des quintes, modulations et changements de tonalités locales...).

# 8. REMERCIEMENTS

Je souhaite adresser mes remerciements les plus sincères au professeur émérite Nicolas Meeus (Université Paris-Sorbonne) pour sa disponibilité, son écoute, sa générosité, ses enseignements et ses conseils tout au long de ce travail de recherche.
9. RESSOURCES

[1] Logiciel en ligne : http://www.gravitation-tonale.fr

[2] Aspects algorithmiques :
http://www.gravitation-tonale.fr/algos.pdf
# POLYPHONIC SINGING PRESENTED AS A MULTIPLAYER CLASSROOM ONLINE GAME

Jonathan Bell

Aix Marseille Univ, CNRS, PRISM

« Perception, Representations, Image, Sound, Music »

Marseille, France.

jonathan.BELL@univ-amu.fr

## ABSTRACT

This paper proposes to use web technologies in a classroom environment, in order to help singers and/or instrumentalists of all levels read and perform polyphonic music. Recent tests in conservatoires and universities have proved that networked music performances of this sort can foster interest in music reading among various groups of music students. The application presented here, *SmartVox*, is hosted on a server, either run locally or via the internet. The *server* provides a web page accessible by the *client* through an IP address (*e.g.* **smartkids.smartvox.eu**)<fnref n="1" />, which the students type into the browser of their smartphone. Students typically access the application together, in the same classroom - but each with his/her own device - and request the individual parts of the polyphony corresponding to their tessitura. The conductor's interface, a 2^nd^ type of *client* (**smartkids.smartvox.eu/conductor**), controls the global state of the distributed application (*e.g.* play, pause...). The coupling of auditory and visual signals, as well as the ability to render and synchronize different parts on each performer's device makes *solfège* and various forms of elaborate contrapuntal musical situations accessible to untrained musicians.

## 1. INTRODUCTION

This article presents the continuation of the research published in *SmartVox*, a web-based distributed media player as notation tool for choral practices [3]. Based upon a doctoral thesis investigating *audio-scores* [2], *SmartVox* was developed at IRCAM in Paris in 2015, by Benjamin Matuszewski and the author.

<figure><img src="image_103.png" /><figcaption>**Figure 1.** *SmartVox running on a local area network*</figcaption></figure>

### 1.1. Technical presentation

*Smartvox* is open source <fnref n="2" />, it was developed within the Javascript *Soundworks* [9] framework, running on node.js (server-side javascript). The single-page web application consists of two web clients: the *player* (see Figure 1, right-hand side) and the *conductor* (Figure 1, bottom left), that can be executed in any recent web browser on mobile devices (smartphones, tablets and laptops). The real-time communication between clients is achieved through the *WebSocket* protocol <fnref n="3" />. The scores are composed and/or transcribed in the *Bach* [1] environment for Max/MSP.

### 1.2. Nature and function of the application

*Smartvox* serves multimedia (audio + visual) scores in the mp4 format. Once the players have chosen their part, the application synchronizes all the videos over a shared time-line. Figure 1 shows a typical *Local Area Network* classroom setup, where no access to the internet is required, and where communication is realized through a router that generates a wifi network. A computer runs the node.js

<footnote n="1">¹ Click on this link or type-in **smartkids.smartvox.eu** directly in the address bar of a browser connected to the internet. On the homepage, click on the screen, choose one part, and press the *send* button. Once the part loaded, the video needs to be unlocked, pressing the *play* button of the device's media player.</footnote>

<footnote n="2">² The code can be downloaded at the following address: https://github.com/belljonathan50/SmartVox0.1</footnote>

<footnote n="3">³ https://www.w3.org/TR/websockets/</footnote>
<table><caption>**Table 1.** Pieces currently available on the web. The links can be copied into a browser or directly clicked on this page.</caption><thead><tr><td>Pieces</td><td>Player's address</td><td>Conductor's address</td></tr></thead><tbody><tr><td>1. And the sea</td><td>smartvox.eu</td><td>smartvox.eu/conductor</td></tr><tr><td>2. Nuages</td><td>nuages.smartvox.eu</td><td>nuages.smartvox.eu/conductor</td></tr><tr><td>3. Smartkids</td><td>smartkids.smartvox.eu</td><td>smartkids.smartvox.eu/conductor</td></tr><tr><td>4. Josquin</td><td>josquin.smartvox.eu</td><td>josquin.smartvox.eu/conductor</td></tr><tr><td>5. Vitry</td><td>avignon.smartvox.eu</td><td>avignon.smartvox.eu/conductor</td></tr><tr><td>6. Tallis</td><td>tallis.smartvox.eu</td><td>tallis.smartvox.eu/conductor</td></tr><tr><td>7. Dunstaple</td><td>dunstaple.smartvox.eu</td><td>dunstaple.smartvox.eu/conductor</td></tr><tr><td>8. Dufay</td><td>dufay.smartvox.eu</td><td>dufay.smartvox.eu/conductor</td></tr><tr><td>9. Canons</td><td>canons.smartvox.eu</td><td>canons.smartvox.eu/conductor</td></tr></tbody></table>

server (see the top left of the figure), which can then be accessed by all the players by typing the server's IP address into their phone's browser. Figure 1 also highlights the polyphonic nature of the application: three players each receive different pitches (*do*, *mi*, *sol*), and the resulting chord is displayed on the classroom board.

## 2. CASE STUDIES

Since most smartphones can today run reliable browsers (such as Chrome, Safari or Firefox), this form of web-based distributed application is an extremely simple and cost-effective way to connect and synchronize all the devices present in the same room (or on the world-wide web, but it is less relevant in this particular case). *SmartVox* was originally designed for the rehearsal and performance of my own compositions. The cues provided by this application allow singers of all levels to perform long and sometimes challenging pieces in public concerts, wearing headphones and watching their score scrolling on the screen, thus highly improving their confidence and the quality of their performance. This participative aspect also allows collaboration between professional and amateur ensembles (see Section 2.3). In the meantime, since its conception in 2015, *SmartVox* quickly found a wide range of applications in pedagogical environments, from *solfège* or *formation musicale* in conservatoires (see Section 2.1 and Table 1, piece n°3: smartkids), to more advanced courses about Renaissance polyphony for 2nd year university students in musicology (see Section 2.2 and Table 1, pieces n°4-9).

### 2.1. *Solfège* in conservatoires: smartkids.smartvox.eu

The *SmartKids* piece was tested in several French conservatoires<fnref n="4" />, with children of different ages/grades, in instrumental, mixed, and *a capella* versions. For children, a distributed mobile application can be evocative of a multi-player game. This playful aspect helps to focus their attention on the demanding notions of music theory or *solfège* (see Figure 2). In a pedagogical piece composed for this system, the notation purposefully conveyed the same pitch information in four different ways:

<figure><img src="image_104.png" /><figcaption>**Figure 2.** A *SmartKids* reading session during a French conservatoire *formation musicale* lesson.</figcaption></figure>

* Sound frequency: a synthetic voice sings on a given pitch, e.g., A = 440 Hz (audio).

* Spoken words: the synthetic voice pronounces the corresponding phoneme ‘La’ (audio).

* Symbolic notation: the corresponding pitch is displayed on the musical stave (visual).

* Written text: the phoneme ‘La’ is written below the stave (visual).

The pitch content of the score was sight-readable and self-explanatory. The notation of time did not require any specific knowledge either, since it displayed a scrolling playhead in proportional notation<fnref n="5" />, thus bypassing the conventional ‘bars and beat’ rhythmic notation. At first sight, groups of ten to twenty children were able to sing in tune complex three-parts polyphonies.<fnref n="6" /> After a few run-throughs, the children had memorized elements of the polyphony, and the piece could be used as source material for written melodic dictations. These classroom experiments also seemed to prompt students to propose their own musical ideas, a process later leading to forms of collaborative composition. This potential creative output associated with the use of information and communication technology (ICT) resonates with studies by Reynolds [8] and Pitts-Kwami [7], which highlights a correlation between compositional skills and the use of ITC in primary and secondary schools.

<footnote n="4">⁴ Fontenay-aux-Roses, CRI. Sussy-en-Brie, CRI. Conservatoire du 5ème arrondissement, Paris. Vitry-sur-Seine, CRD.</footnote>

<footnote n="5">⁵ The scores were realized in *bach. roll* [1]. This object allows a refined control of synthesizers (i.e. vocal synthesizers), controlled via the metadata contained in each note of the object, and subsequently sent to Max in realtime when played, e.g.: https://youtu.be/EcsdBrQf6Jw</footnote>

<footnote n="6">⁶ Live recording of a *SmartKids* reading session: https://youtu.be/syBZ3D8Pnjo</footnote>
## 2.2. Renaissance Polyphony at AMU: tallis.smartvox.eu

The pieces n°4-9 of Table 1 were used extensively at Aix-Marseille University with 2nd year students in 'musique et musicologie' (Arts Department). In this course on Renaissance polyphony, *SmartVox* was used on a weekly basis in order to let the students sight-sing the pieces that were subsequently analyzed. This practice-based approach to musical analysis allowed the students to engage personally with pieces of extremely complex construction (such as Ockeghem's *Missa Prolationum* or Mouton's *Nescient Mater*, both available at www.canons.smartvox.eu). From a pedagogical point of view, having the full score projected on the classroom's board proved to be very instructive<fnref n="7" />: at any time in the piece, each student could see his own part on his phone, hear through headphones a piano sound prompting him the pitches he is asked to sing, with the resulting polyphony sung by his colleagues, and displayed on the board. With this exhaustive representation, the identification of imitations between voices, canons and cadences became very clear on the score, and was at the same time directly related to a practical musical experience. At the end of the semester, the web application was used again with the students in a church, in order to record in a relevant acoustic the pieces studied during this course.<fnref n="8" /> This form of computer-aided performance allowed us to superimpose the different takes of the recording, all perfectly in tune and in time with each other, thus making possible various cuts and edits.<fnref n="9" />

## 2.3. Productions

As well as a learning-aid used in a teaching environment, *SmartVox* is also used in diverse participative compositional experiments, which will now be discussed. These participative projects emerged from the observation that choral singing requires competencies such as vocal skills, intonation, music reading, and confidence in performance situation. This often restricts ancient and contemporary repertoire to a small group of specialists. The audio and visual guides provided by therefore seek to offer accessibility and exposure to works otherwise judged too difficult, for choirs of all levels.

### 2.3.1. *SmartVox, the piece*

The SmartVox piece/production<fnref n="10" />, for 5 soloists, choir, and tape, was premiered in Nantes in March 2017¹¹. Involving a local choir each time, this project has a participative aspect that makes it financially viable. SmartVox

was therefore performed again in Rouen in April 2018. The use of audiovisual notation for this piece was justified by its microtonal language, because of the confusion that the notation of such intervals may cause for some singers.

### 2.3.2. *Le temps des nuages*<fnref n="12" />

This piece (see Table 1, piece n°2), based on poems by French philosopher Michel Onfray, premiered in January 2018, used *SmartVox* on a very large scale for the first time. This piece was written for 5 singers (the *De Caelis* ensemble), 5 percussionists (the *Links* ensemble), 4 channels of electronics, and 75 junior high-school students, who were placed all around the audience. The setup required about 70 simultaneous connections. The size of the concert hall (600 seats) and the number of connexions required a powerful wifi network relying on several antennas placed where the singers stood. The recording of the piece (see footnote below) clearly manifests, in terms of pitch and timing, but also hearing the children's conviction and confidence, that such a degree of accuracy could not have been achieved in any other way.

## 3. CONCLUSION

Music technology is still hardly ever used at school. This reveals, according to Hitchcock: "the dichotomy between the ubiquity of music technology in the music world and technology's relative paucity in the school curriculum" [6]. Furthermore, smartphones are often considered as a parasite in the classroom environment: "most school's policies completely forbid mobile usage within lessons" [4]. Bridges between technology and music education, therefore, are often judged with mixed feelings, and yet, with digital-native generations, innovative solutions must be found to accompany a mutation which Georg Hajdu describes as a "slow but steady shift away from textualization in digital media" [5]. With such mutation, the classical score-based music-making apparatus, hitherto reserved to an elite, could be shared with a larger community. According to Wise, Greenwood and Davis, the challenge consists in "moving technology from its position as an *add-on* in the music curriculum to a position of being embedded within the curriculum" [10].

The originality of the present *setup* (the French term *dispositif*, is here of particular relevance) consists in turning mobile devices into a learning-aid fostering collective music singing improvement. With its strong focus on music reading, it hopes to convey among young students a revival of interest in music notation and thus benefit to the school curriculum. It constitutes an original contribution to the difficult questions raised by the use of technology in music education. Whether in conservatoires<fnref n="13" /> or uni-

<footnote n="7">⁷ The computer plugged to the beamer just connects to the server like the performers (unless it is running the server itself, in which case the address is, for instance, localhost:8000) and displays the *conducteur* part.</footnote>

<footnote n="8">⁸ Recording by the students with the help of *SmartVox*: https://www.youtube.com/watch?v=bofWvTCNNKI</footnote>

<footnote n="9">⁹ Editing process exemplified in *Reaper*: https://youtu.be/HExNA5Z7eFY?t=34</footnote>

<footnote n="10">¹⁰ Brief description of the project: http://www.decaelis.fr/fr/programmes/534</footnote>

<footnote n="11">¹¹ Live recording with animated full score of the piece: https://www.youtube.com/watch?v=8R4Twc1A7Ks</footnote>

<footnote n="12">¹² Live recording of the piece: https://youtu.be/SyFdR2HiF00</footnote>

<footnote n="13">¹³ Live recording of a *SmartKids* reading session: https://youtu.be/syBZ3D8Pnjo</footnote>
versities<fnref n="14" />, the use of *SmartVox* proved each time to be an invaluable tool for helping unexperienced music readers, thus disinclining non-readers to switch off, and putting 'on the same track' singers of different musical backgrounds.

4. REFERENCES

[1] A. Agostini and D. Ghisi. Bach: An environment for computer-aided composition in max. Ljubljana, Slovenia, 01 2012.

[2] J. Bell. Audio-scores, a resource for composition and computer-aided performance http://openaccess.city.ac.uk/17285/. 2016.

[3] J. Bell and B. Matuszewski. Smartvox. a web-based distributed media player as notation tool for choral practices. In H. L. PALMA, M. SOLOMON, E. TUCCI, and C. LAGE, editors, *Proceedings of the International Conference on Technologies for Music Notation and Representation - TENOR2017*, pages 99–104, A Coruña, Spain, 2017. Universidade da Coruña.

[4] M. Gall. *Technology in Music Education in England and across Europe*. Oxford University Press, aug 2017.

[5] G. Hajdu. Disposable music. *Computer Music Journal*, 40(1):25–34, 2016.

[6] M. Hitchcock. *Generating Intersections between Music and Technology*. Oxford University Press, aug 2017.

[7] A. Pitts and R. M. Kwami. Raising students' performance in music composition through the use of information and communications technology (ict): a survey of secondary schools in england. *British Journal of Music Education*, 19(1):61–71, 2002.

[8] N. Reynolds. *Technology and Computers in Music and Music Education*, pages 333–343. Springer Berlin Heidelberg, Berlin, Heidelberg, 2010.

[9] N. Schnell and S. Robaszkiewicz. Soundworks – A playground for artists and developers to create collaborative mobile web performances. In ‘Proceedings of the Web Audio Conference (WAC’15), Paris, France, 2015.

[10] S. Wise, J. Greenwood, and N. Davis. Teachers' use of digital technology in secondary music education: illustrations of changing classrooms. *British Journal of Music Education*, 28(2):117–134, 2011.

<footnote n="14">¹⁴ Recording by students of the Aix-Marseille University (AMU) music department: https://www.youtube.com/watch?v=bofWvTCNNKI</footnote>
# LEARNING GEOMETRY AND MUSIC THROUGH COMPUTER-AIDED MUSIC ANALYSIS AND COMPOSITION: A PEDAGOGICAL APPROACH

Sonia Cannas

Università di Pavia and IRMA/Université de Strasbourg

sonia.cannas01@universitadipavia.it

## RÉSUMÉ

In this paper we will focus on pedagogical approaches via HexaChord, a computer-aided music analysis environment based on spatial representation of musical objects inspired by the Tonnetz and other geometric models. We will report some past experiences with children and adolescents during two Festival of Science. We will also suggest future laboratories for children.

## 1. INTRODUCTION

The results of learning geometry through interactive geometry software (IGS) and dynamic geometry software (DGS) such as Cabri and GeoGebra are well known in mathematics education [7]. At the same time, the employment of the information technology (IT) in music education shows an increasing interest [1]. Could pedagogical approaches on learning music and geometry be developed together through the IT tools? The same abstract notions in different concrete settings are useful for the development of abstraction capabilities. Although there are studies and experiments on higher education [2], interdisciplinary pedagogical approaches among mathematics, music and computer science are often scarce in primary and secondary school. We will analyze some pedagogical aspects via HexaChord [3, 4], reporting experiences with children and adolescents, and we will suggest future pedagogical laboratories.

## 2. GEOMETRIC MODELS IN MUSIC

### 2.1. Musical graphs and simplicial complexes

Geometric structures such as graphs and simplicial complexes are music-analytical tools commonly used to visualize and describe parsimonious voice leading and relations among musical objects. In music theory two different kinds of graphs are used: note-based and chord-based graphs. In the first ones each vertex is labeled by a pitch-class, in the second ones, by contrast, each vertex is labeled by a chord. Chord-based graphs are associated with note-based graphs by duality.

The most famous example of note-based graph is the Tonnetz. It is a graph in which pitch classes of twelve-tone equal temperament are organized along intervals of fifth in the horizontal axis, major and minor thirds in the

diagonal axis. In this construction each triplet of distinct vertices, which are adjacent two by two, is a triangle representing a major or a minor triad. We can also define it as an infinite 2-dimensional simplicial complex, where 0-simplices represent pitch classes, and 2-simplices identify major and minor triads. The dual graph of the Tonnetz, known as *Chicken-wire torus* [6], is a chord-based graph in which vertices represent major and minor triads.

The edge-flips in the Tonnetz and the edges in the Chicken-wire torus represent the neo-Riemannian musical operations *P* (parallel), *R* (relative) and *L* (leading tone), commonly used to describe parsimonious voice leading [5].

<figure><img src="image_105.png" /><figcaption>**Figure 1.** The Tonnetz (above) and the Chicken-wire Torus (below)</figcaption></figure>

### 2.2. Circular geometric models in music

There are also two other well known geometric models in music: the *circle of fifths* and the *tone-clock*.

The first one is a circle in which the 12 major and minor scales, and their corresponding key signatures, are represented along a circle at a distance of fifth.
The *tone-clock*, also known as *musical-clock*, is a circular representation of the 12 pitch-classes at a distance of a semitone. Each pitch class is labeled with a number from 0 (in the position of the 12 in the clock) to 11, starting from $C = 0$ (see fig.3). It allows to represent chords: a 2-chord is a segment, a 3-chord a triangle, a *n*-chord a polygon of *n* vertices inscribed in a circle.

### 3. GEOMETRIC MODELS IN COMPUTATIONAL MUSIC ANALYSIS

There are several softwares in which musical graphs, simplicial complexes and other geometric models are integrated. One of them is HexaChord, a computer-aided musical analysis environment based on spatial representation of musical objects, developed by Louis Bigo [3] [4]. The main interface is simple and easy to use, and it is represented in fig. 2. The first block is used to play music files in MIDI format. Below it, there is a second block used to visualize geometric models in music: the *Tonnetz* as a simplicial complex or other simplicial complex isomorphic to it (button "display/hide complex"), the musical-clock (button "circle 1"), the circle of fifths (button "circle 5"), and the voice-leading space (button "display graph"). During the execution of the MIDI file, it is possible to visualize in real time each chord in the different geometric models. Clicking on "trace on" it is also possible to visualize in the Tonnetz the chord sequence of the musical piece as a trajectory in the space.

In the part below the latter there is the block "Vertical compactness", to compute the compactness of the trajectory related to the musical piece in the *Tonnetz*. In the lower part there is the block "Trajectory Transformation", used to apply a geometric transformation to the original simplicial complex. One of them is the discrete translation, that musically corresponds to a transposition.

<figure><img src="image_106.png" /><figcaption>**Figure 2.** HexaChord</figcaption></figure>

Moreover with Hexachord it is also possible to connect a piano keyboard and play/record musical pieces. All functionality are available also for the performance.

### 4. PEDAGOGICAL EXPERIENCES AND RESULTS

#### 4.1. Festival of Science in Strasbourg

During the *Festival of Science* (2017) at the Vaisseau of Strasbourg, an IT-mathemusical laboratory for children has been organized. Different materials were proposed which included: a computer with HexaChord, a piano keyboard connected to it, loudspeakers, a musical-clock made with a wooden model (see fig.3), another wooden model representing both the *Tonnetz* and the *Chicken-wire Torus* (see fig.4). Many children played with the wooden musical-

<figure><img src="image_107.png" /><figcaption>**Figure 3.** Wooden musical-clock. The chords are represented using a rubber band, and the twelve points are labeled with a number from 0 to 11 and the correspondent note</figcaption></figure>

geometric models, more than the children who tried to play the piano and to understand HexaChord. Their attention focused more on wooden models for several reasons. First of all, since all children have already had gaming experiences with geometric shapes and rubber bands, they had no difficulties to recognize it as an entertaining game. On the contrary, the piano keyboard and HexaChord were new for most of them, and they require a first phase of comprehension in order to be used correctly. During the absence of a guide to the piano and the computer, some children tried to play with the piano looking the geometric models represented on HexaChord at the screen. Especially the younger ones did not understand how the musical sequences were displayed, then they moved on the geometric wooden models, more familiar to already known games. Moreover this underlines the different levels of learning musical and mathematical skills. The mathematical skills required in the construction of chords on geometric models are easier than the musical ones. Listening, playing, and understanding how the musical sequence is represented on the geometric model require a musical awareness that children begin to have towards around the age of 9. Furthermore, the children have to perform various tests for learning the latter, therefore it is necessary that they try one by one. On the other hand, activities on geometrical models can be carried out by several children at the same time. In the moments when a guide explained the representation of the musical sequences through Hex-
<figure><img src="image_108.png" /><figcaption>Figure 4. Wooden Tonnetz</figcaption></figure>

aChord, the children showed interest and they understood very quickly its behavior. By testing them directly on the piano and observing the screen, their learning has become active. It is in fact well known that experiential learning is more efficient than passive learning such as reading or listening.

## 4.2. Festival of Science in Cagliari (Italy)

In the last edition of the *Festival of Science* in Cagliari (2017) I presented geometric models in music and their usefulness in music analysis through HexaChord. Most of the audience consisted of two classes of students belonging to the last year of a high school (19 years old) with a musical program. Thanks to their musical background, they easily understood the features of HexaChord and its utility for music analysis. During their musical studies they studied traditional music analysis, and their reactions to computational approaches to it based on geometric models were very positive. In addition to the surprise of knowing computer-aided music analysis, their greatest surprise was to discover that mathematics can also be a useful tool for music. Often, at school level, mathematics is taught and perceived as a set of many formulas and rules, whose meaning is unclear. Interdisciplinary learning can be an additional tool to overcome this misunderstanding of mathematics as an abstract subject without meaning. In conclusion, it was a very positive experience for the students: on the one hand they discovered a new type of musical analysis that brings together music, computer science and mathematics, on the other hand they discovered the beauty and utility of geometry.

# 5. FUTURE LABORATORIES FOR CHILDREN

The laboratories we are planning include some different activities, designed with different levels of difficulty. We want to propose game activities for children, in order to develop musical and geometric-spatial skills.

For all activities we need: a computer with which to use HexaChord, a piano keyboard connected to it, and a wooden musical-clock or a wooden Tonnetz. The aims of these activities are different. The children will become familiar

with the musical-geometric models and the representation of the notes on them through HexaChord. They will learn the correspondence between number of notes of a chord and number of vertices of the correspondent figure on the musical-clock. They will start to become aware of the musical meaning of chord. Moreover they will observe that in the musical-clock and in the piano keyboard the notes are repeated in the same way, therefore they will become aware of the fact that one can work using only one octave. They will also begin to become familiar with the piano keyboard.

## 5.1. Reconstruction of chords

These laboratories are useful for children at the age of 9 and up.

### 5.1.1. First activity

The first activity consists in listening to a single chord on HexaChord, observing its geometric shape in the musical-clock integrated in the software and reproducing the latter in the wooden musical-clock with the rubber band. One can choose whether to prepare various MIDI files of individual chords to be played, or play them directly on the piano keyboard during the activity.

After that, children can do the contrary. In the wooden musical-clock a plane geometric figure is represented with the rubber band, the children have to reproduce it using the piano keyboard. The visualization on the musical-clock of HexaChord will help to this scope.

### 5.1.2. Second activity

The aim of the second activity is the same as the first. The children have to reproduce a chord in the wooden musical-clock but, this time, they will visualize the representation of the chord on the *Tonnetz*. To reach the aim, children can use the piano keyboard and observe their chord reproduced on the Tonnetz. This activity can be proposed if the children have already some musical background, otherwise it is recommended to carry out the first activity.

## 5.2. Musical sequences

This laboratory is useful for children at the age of 7 and up.

The aim is to recognize that a musical sequence in the *Tonnetz* and its transpositions have trajectories with the same shape. The children will listen a musical phrase (played in real time or previously recorded) and they will see the trajectory on the Tonnetz integrated in HexaChord. They will have to sing it and to represent the trajectory in the wooden Tonnetz. Afterwards, the musical phrase will be transposed, and the children will have to sing it and to represent the new trajectory. After some examples, the children will have to represent the new trajectory without displaying it on HexaChord and having only the initial note.
6. REFERENCES

[1] A. Anatrini, *The state of the art on the educational software tools for electroacoustic composition*, Proceedings of SMC Conference 2016, 2016.

[2] M. Andreatta, C. Agon Amado, T. Noll, E. Amiot, *Towards Pedagogability of Mathematical Music Theory: Algebraic Models and Tiling Problems in computer-aided composition*, Proceedings Bridges. Mathematical Connections in Art, Music and Science, London, 2006, p. 277-284.

[3] L. Bigo, M. Andreatta, J. L. Giavitto, O. Michel, A. Spicher, *Computation and Visualization of Musical Structures in Chord-Based Simplicial Complexes*. In: Yust J., Wild J., Burgoyne J.A. (eds) Mathematics and Computation in Music. MCM 2013. Lecture Notes in Computer Science, vol 7937. Springer, Berlin, Heidelberg, 2013.

[4] L. Bigo, D. Ghisi, A. Spicher, M. Andreatta, *Spatial transformations in simplicial chord spaces*. In: Proceedings of the Joint International Computer Music Conference - Sound and Music Computing, Athens, 2014, pp. 1112-1119.

[5] R. Cohn, *Neo-Riemannian Operations, Parsimonious Trichords, and their "Tonnetz" Representation*, Journal of Music Theory, 1997.

[6] J. Douthett, P. Steinbach, *Parsimonious Graphs: A Study in Parsimony, Contextual Transformation, and Modes of Limited Transposition*, Journal of Music Theory, 42/2, 1998.

[7] R. Stäßer, *Cabri-Geometre: Does Dynamic Geometry Software (DGS) Change Geometry and Its Teaching and Learning?*, International Journal of Computers for Mathematical Learning, 6(3), 2001, pp. 319-333.
Bell, Jonathan, 139
Bevilacqua, Frédéric, 115
Bimbot, Frédéric, 5, 71, 81
Bonardi, Alain, 11, 105

Cannas, Sonia, 143
Carpentier, Thibaut, 35, 45
Chehab, Jean-Paul, 3
Clara, Sébastien, 53

de Paiva Santana, Charles, 97
Di Mauro, Emanuele, 135
Donat-Bouillud, Pierre, 25

Foscarin, Francesco, 87
Fournier-S'Niehotta, Raphaël, 87

Galleron, Philippe, 105
Guichaoua, Corentin, 71
Guigue, Didier, 97
Guillot, Pierre, 15

Jacquemard, Florent, 87

Larrieu, Maxence, 63
Lemouton, Serge, 11
Libermann, Nathan, 81

Maestri, Eric, 105
Malt, Mikhail, 121
Mihalic, Alexander, 121
Millot, Jean, 105

Pachet, François, 7
Paris, Eliott, 105
Pottier, Laurent, 11

Rigaux, Philippe, 87
Scurto, Hugo, 115

Vincent, Emmanuel, 81
Vulliard, Pierre-Henri, 131

Warnier, Jacques, 11