LE PROJET Q-LIVE
Pierre Michaud
Université de Montréal
p.michaud@umontreal.ca

Olivier Bélanger
Université de Montréal
olivier.belanger@umontreal.ca

RÉSUMÉ
Cet article présentera l’état des recherches et dudéveloppement de Q-Live : un nouveau logiciel pour lamusique mixte développé à la Faculté de musique del’Université de Montréal depuis l’été 2014. Ce projet acomme buts principaux :1. De proposer une solution au problèmed’obsolescence technologique en musique mixte,
2. De faciliter le développement d’une pédagogie
heuristique de la musique mixte pour lesinterprètes et les compositeurs.
Q-Live est un logiciel open source conçu par Pierre
Michaud qui sera développé sur trois ans par Olivier
Bélanger et Lucas Paris grâce au soutien du Fonds derecherche du Québec sur la société et la culture (FRQSC).
Le logiciel sera disponible pour OSX, Windows et Linux.

1.

GENESE DE Q-LIVE : REFLEXIONSPRELIMINAIRES

La musique mixte1 existe depuis trois quarts de siècle2 etsoulève toujours de nombreuses questions. Les possibilitésd’interactions entre un interprète et un ordinateur sur scène
se sont démultipliées depuis la fin des années 1980 [4], en
grande partie grâce aux logiciels d’algorithmie musicale(Max, Pure Data, SuperCollider, etc.). Ces logiciels deprogrammation graphique ou textuel font désormais partie
des cursus de composition et d’informatique musicale dansde nombreux pays. Nous pensons que ce changement deparadigme vers le numérique a permis un certain
décloisonnement de la profession de compositeur en y
greffant les métiers de réalisateur en informatiquemusicale, de soudeur ou de luthier dans le cas du physical1
Pour cet article, nous entendons comme musique mixte (au singulier),
une œuvre musicale intégrant simultanément une composanteélectroacoustique (fichiers sonores, traitements en temps réel) et une
composante acoustique (interprétation sur scène), le tout accompagnéd’une partition. Nous reconnaissons qu’il existe, bien évidemment,
d’autres formes de musiques mixtes (art performatif, robotique, musiquesvisuelles, etc.), mais nous nous intéressons particulièrement à laproblématique de pérennité des œuvres mixtes avec partitions.
2
En considérant Imaginary Landscape No.1 (1939) de John Cage (19121992) comme une des premières œuvres mixtes dans l’histoire de lamusique.

Lucas Paris
Université de Montréal
lucas.paris@umontreal.ca

computing, etc. Les vertus pédagogiques d'un tel
enseignement sont inestimables.
Cependant, nous constatons également que ce changementa apporté son lot de nouveaux problèmes. Parmi les plus
importants mentionnons : l’obsolescence technologique(plus particulièrement des logiciels), et l’investissement entemps nécessaire à la maîtrise des rudiments deprogrammation musicale. Q-Live compte justement
aborder ces deux problématiques comme prémisses dedépart pour l’élaboration de la conception logicielle.
Après 25 ans de création avec ces outils de programmationgraphique, existe-t-il un savoir faire, des stratégies et desméthodes pour l’élaboration de la composanteinformatique ? Serait-ce possible d’imaginer un autre
paradigme pour l’élaboration et la mise en forme de lacomposante électronique des œuvres mixtes ? Serait-ce
possible de sauvegarder automatiquement les données
nécessaires à la reconstitution complète de la composanteélectronique d’une œuvre mixte ?
1.1. La question de la pérennité et le niveau neutre
Commençons par le commencement. Q-Live est un
logiciel conçu, d’abord et avant tout, pour la musique
mixte avec partition. Le problème de pérennité ne se posepas tant pour le volet instrumental de cette discipline si
nous restons dans le paradigme des partitions imprimées
sur papier. En proposant une certaine représentationgraphique d’une certaine pratique musicale, Guido
D’Arezzo3 a donné aux compositeurs le pouvoir detransmission d’une intention musicale aux interprètes.
Cette écriture, comme toute écriture, est dépendante d’unepédagogie qui lui est adaptée. Cette écriture, comme touteécriture, a inspiré un corpus théorique qui définit sonorganisation, ses comportements, son intégration, sa
transmission. Nous pouvons aussi affirmer, sans l’ombred’un doute, que la pérennité d’une écriture est directement
dépendante de la transmission et de l’utilisation courante
de celle-ci.
3

Système de notation sur portée inventé par Guido d’Arezzo (992-1050),
célèbre pour sa contribution à la transmission et à la préservation d’une
intention musicale.

Dans la tripartition sémiologique de Nattiez [3], lapartition musicale est considérée comme étant le niveau
neutre, ou l’ensemble des configurations du texte musical.
Les deux autres niveaux sont :1.

2.

Le poïétique, ou niveau de la création. Niveau lié
à l’expérience du compositeur, à son inspiration,
aux processus de création.
L’esthésique, ou niveau du ressenti, de laperception.

Force est de constater que la venue des musiquesélectroacoustiques, le siècle dernier, bouleverse cettethéorie, le niveau neutre étant beaucoup plus difficile àdéfinir. Peut-on, à l’écoute seule d’une œuvre
acousmatique, par exemple, saisir l’ensemble desconfigurations du texte musical ?

mixte est le patch de concert (avec l’aide des indications
dans la partition musicale). Les standards actuellement
dans la pratique pour l’élaboration de ces patchs sont lesenvironnements de programmation graphique Max ou Pure
Data (Figure 2.).
Au niveau poïétique, ces environnements de travail
peuvent présenter un avantage, même s’il s’agit
d’environnementsderelativementbas
niveaucomparativement aux logiciels de type séquenceur oud’édition musicale. Le compositeur peut, par exemple,
comprendre par une étape de formalisation lefonctionnement de certains traitements ou créer desprototypes à condition d’être formé en informatiquemusicale et en traitement de signal.

Or, dans la musique mixte avec partition, le niveau neutre
est bel et bien présent, mais est incomplet dans la majoritédes cas. Comme le démontre l’exemple plus bas (Figure1.), la partie interprétée de la composante électronique serésume à appuyer sur la touche Mi grave d’un clavier
MIDI. Cette touche active une réverbération sur la notechantée par le soprano (Sol#) et déclenche un fichiersonore avec un texte enregistré (« warum ichbehaupte,… »). Les chiffres en haut de la portée décriventla spatialisation sonore. Quelle est la durée de laréverbération ? Quel est le type de réverbération utilisé ?
La partition ne nous dévoile pas ces détails. La description
morphologique sert de repère pour la chanteuse et pour lechef.
Figure 2. Exemple d’un patch Pure Data.
Ceci dit, en considérant la personne qui devra, un jour ou
l’autre, reconstituer la programmation dans une œuvre
mixte, cette approche est loin d’être idéale ou, du moins,
semble incomplète du point de vue du niveau neutre.

Figure 1. Extrait de Constat d’une métamorphose(2006/2008) de Pierre Michaud pour soprano, 13
musiciens et électronique [2].

La partie MIDI écrite dans la partition et la description
morphologique pourraient être considérées comme étant
suffisamment complètes dans le contexte d’une partition
musicale de musique instrumentale ou vocale. La partition
sert l’interprète, mais transmet-elle l’intention musicale ducompositeur ? Pas complètement, d’où le problème.

Est-il possible de reproduire à l’identique le résultat sonore
d’un traitement ou d’un processus présent dans une œuvre
s’il est programmé dans un autre environnement ? Dansl’éventualité d’un ou plusieurs objets externes (ou internes)
Max désuets, comment les reconstituer si l’ensemble desconfigurations du « texte » de programmation est
incomplet ou difficilement retraçable ? Il y aura donc unepart de traduction de l’intention musicale du compositeur(ou du RIM dans certains cas) en ce qui a trait à lacomposante électronique d’une œuvre qui doit être migrée.
Considérons donc l’acte de migration technologique4,
comme un acte de traduction.
4

Pour l’instant, la seule « partition » permettant dereconstituer une composante électronique dans une œuvre

Migration technologique inévitable en musique mixte considérant lacourte durée de vie des versions de logiciels et des systèmes
opérationnels.

Cet interprète-informaticien sera, plus souvent que non, un
compositeur ou un Réalisateur en informatique musicale(RIM) selon le milieu et le contexte culturel ou socioéconomique.
En ce qui concerne le Québec, et pour la majeure partie del’Amérique du Nord et de l’Amérique du Sud, le RIM n’apas le statut que nous retrouvons en France [7]. Nous
pouvons donc sous-entendre, compte tenu des formations
qui sont actuellement offertes dans nos universités et nos
conservatoires, et compte tenu du financement disponible
dans le cadre des programmes de commandes d’œuvres
financés par les Conseil des arts du Canada ou du Conseil
des arts et des lettres du Québec, que cet interprèteinformaticien risque d’être un compositeur de formation. À
quoi pourrait donc ressembler une « partition » qui luipermettrait de reconstituer la composante électroniqueobsolète d’une œuvre ? Quelles sont les informations qui
devraient s’y trouver ?

2.

DESCRIPTION DE Q-LIVE

2.1. Q-Live – prémisses de départ
Le logiciel développé dans le cadre de ce projet doit
répondre à un certain nombre d'exigences. Il doit êtresimple d'utilisation, c'est-à-dire offrir une courbe
d'apprentissage rapide, tout en étant le plus flexible
possible, afin de répondre aux besoins de mise en forme etde standardisation de la notation électronique. Ce logiciel
n'est pas destiné à des programmeurs ou à desinformaticiens, mais bien aux compositeurs et aux
interprètes, dans le but de leur offrir un environnement detravail unifié. Pendant la création de l’œuvre, lecompositeur doit avoir la pensée libre de toute composantetechnique afin de se consacrer pleinement à l'écriture de lamusique, instrumentale et électronique. Nous considérons
donc que le logiciel doit être une aide et un support aucréateur et non un fardeau dont il faut sans cesse maîtriser
les rudiments. De même, pour l'interprète, le logiciel sedoit d'être suffisamment simple d'intégration pour êtreutilisé sur scène sans le recours à un technicien.
Plusieurs raisons ont guidé le choix de l'environnement dedéveloppement pour l'écriture de Q-Live. Premièrement,
afin d'assurer une longue vie au logiciel, il est impératif detravailler avec un langage de programmation mature,largement utilisé et en développement actif. Ainsi, malgrél'évolution des technologies, il est raisonnable de penser
qu'un tel langage sera supporté encore plusieurs années.
Ensuite, dans le but d'offrir ces nouvelles fonctionnalitésau plus grand nombre possible, l'environnement doit
fonctionner sous tous les systèmes d'exploitation majeurs(Mac OS, Windows, Linux). En éliminant le clivage enfonction de l'ordinateur disponible, nous augmentons laportabilité et la diffusion des œuvres musicales.
Finalement, comme la pérennité d'un logiciel est en partie
soumise à son accessibilité et à la possibilité d'êtreamélioré, ou adapté, par des tiers, la licence dedéploiement assurera sa gratuité et la disponibilité de soncode source.
Les composantes utilisées pour ledéveloppement de l'application seront donc :1 – Le langage de programmation Python. Deuxième
langage le plus utilisé à ce jour, il est multiplateformes,
gratuit et possède une immense bibliothèque de librairies
permettant le développement en tout genre.
2 – La librairie WxPython. Librairie dédiée à la créationd'interface graphique. Elle offre l'avantage que le mêmecode fonctionnera de façon native sous tous les systèmes.
L'aspect visuel du logiciel s'adaptera donc aux styles enplace sur le système où il sera utilisé.
3 – Le moteur audio pyo. Environnement de synthèse et detraitement du son dédié au langage Python, pyo est
développé ici même à l'Université de Montréal. Le module
offre tous les outils nécessaires à la création musicale, dutraitement de signal à la composition algorithmique, en
passant par la gestion temporelle des évènements.
2.2. Pyo
La création du module Python « pyo », par Olivier
Bélanger, a débuté suite à une réflexion issue de ses
expériences de programmeur d'applications audio. Après
plusieurs années à développer des logiciels sonores alliant
le langage python pour la gestion de l'interface et Csoundcomme moteur audio [5] parmi lesquels figure Ounk [1]l'ancêtre de pyo, le besoin d'un environnement deprogrammation unifié devint manifeste.
L'idée de départ était d'éliminer la séparation existanteentre l'engin audio et l'interface de contrôle. Un
environnement de développement qui intégrerait à la fois
le moteur audio et le langage de programmation
permettrait de créer des interactions plus sophistiquéesentre les structures de contrôle et les processus sonores. Un
langage de programmation générale, tel que Python, offre
une panoplie de fonctionnalités, des mathématiques
complexes aux librairies d'interface graphique en passantpar la programmation de base de données, qui sontgénéralement
absentesdans
les
langagesdeprogrammation dédiés au son. Dans le cadre dudéveloppement d'un logiciel autonome, ces fonctionnalités
peuvent parfois s'avérer cruciales. Et si, parmi ces
spécialités, séparées en modules distincts, il en existait unequi soit dédié au traitement de signal ?

Le module « pyo » permet de créer le pont entre le langage
servant à construire la structure du logiciel, c'est-à-dire lescontrôles de paramètres, et la génération des algorithmes
sonores. En évoluant à l'intérieur du même environnement
de programmation, la communication entre les éléments
d'interface, ou les structures génératives, et les processus
audio est grandement simplifiée puisque les objets ont unaccès direct les uns aux autres. Le moteur audio devient
donc un module spécialisé parmi des centaines d'autres
modules disponibles, chacun étant optimisé pour effectuer
une tâche particulière.
Les composantes audio de pyo étant des objets Python
standards, la communication avec une interface graphiquepeut s'effectuer sans intermédiaire car les deux modules
existent dans le même espace mémoire d'une application
unique. Il n'est plus nécessaire d'utiliser un canal detransmission de donnés externe, tel que le protocole decommunication OSC [6] pour transmettre les données del'interface au moteur audio. L'exemple suivant (Figure 3)
illustre l'utilisation de la librairie wxPython pour créer uneinterface graphique (Figure 4) et communiquer les donnéesde contrôle aux objets audio. Comme le serveur et lesynthétiseur audio sont créés à l'intérieur de la mêmeclasse que le bouton et le potentiomètre, les fonctions
appelées par ces derniers n'ont rien d'autre à faire que detransférer directement les valeurs aux variables «self.server » et « self.synth » pour opérer des changements
dynamiques du résultat sonore.

Q-Live étant construit à l'aide d'une structure modulaire,
toutes les composantes audio du programme seront crééesde façon dynamique, lorsqu'un effet est ajouté sur une
piste par exemple. Le module de traitement de signal ainsi
que l'élément d'interface graphique qui lui est rattachéseront donc créés de pair et automatiquement connectés.
L'aspect modulaire du logiciel permettra notamment à
l'utilisateur d'ajouter ses propres algorithmes de traitement
à l'application en insérant des scripts Python dans lachaîne d'effets sonores d'une piste. De nos jours, lescripting est régulièrement utilisé pour modifier lecomportement d'un logiciel (personnalisation desraccourcis, automatisation des tâches) mais rarement pourcréer des processus audio de façon dynamique. La
combinaison Python-pyo simplifie grandement lescripting audio.

2.3. Q-Live GUI
À partir des prémisses de départ de Q-Live, nous avons
constitué une architecture logicielle et une interface
graphique. Grâce à l’efficacité du langage python et àl’expertise acquise à la faculté de musique de l’Universitéde Montréal en création d’interfaces graphiques avec
wxpython pour les logiciels Cecilia 5 et Soundgrain, ledéveloppement d’un prototype fonctionnel a pu se faire en
trois mois.
La partie centrale du logiciel est la section d’effets
audionumériques. Celle-ci permet de charger des modules
d’effets dans un tableau, d'accéder à une fenêtre flottantecontenant les paramètres d’un effet et des options
d’automations pour ces paramètres (breakpoint function,
modulation par suivi d’amplitude, contrôle MIDI et OSC),de créer des connexions entre les effets, et de choisir desentrées audio.

Figure 2. Exemple de code.

Figure 3. Interface graphique.

Ensuite vient la section de gestion des événements. Cette
section cues permet la création et la sélection de nouveauxcues. Après avoir sélectionné un événement on peut
modifier l’ensemble des paramètres de la section d’effet et
ils seront automatiquement enregistrés dans ce cue. À lasélection d’un autre cue une interpolation a lieu entre lesanciennes et les nouvelles valeurs des paramètres. La durée
de cette interpolation peut être ajustée de manière
indépendante pour chaque module d’effet et pour chaqueparamètre.
L’interface principale est complétée par une section
mixeur. Cette section permet d’ajuster les signaux d’entréeavant qu’ils ne parviennent à la section d’effet. Il seraégalement possible d'appliquer des traitements dans cettesection tels que le filtrage, l’égalisation et la compression
qui ne seront pas enregistrés dans les cues. Les deux

exemples suivants (Figures 5 et 6) démontrent la structure
du GUI en phase de développement.

Figure 5. Capture d’écran de Q-Live (Décembre 2014).

Malgré la complexité apparente de la programmationgraphique, un patch de concert peut se résumer, plus
souvent que non, comme étant une organisationd’évènements (traitements, fichiers sonores, automations,processus, etc.) à déclencher physiquement (contrôleur
MIDI, clavier d’ordinateur, etc.) ou automatiquement dansle temps (suivi de hauteur, suivi d’amplitude, timeline,etc.). Les effets audionumériques sont eux aussi, plus
souvent que non, limités aux catégories génériques
existantes(réverbérations,filtres,
harmonizers,
granulation, déphasages, délais, etc.). Quels seraient doncles éléments de base nécessaires pour la reconstitutiond’une œuvre mixte ?
2.4.1.

Légende des effets audionumériques

En premier lieu, il serait importun d’intégrer au document
les descriptifs des effets audionumériques utilisés dansl’œuvre de manière automatique. Compte tenu descatégories génériques d’effets existants5 et de l’information
librement accessible pour une reconstitution de ces effets,
nous croyons qu’une description textuelle suffirait dans lamajorité des cas. La description des effets devrait inclure
l’ensemble des paramètres ainsi que leur ambitus. Dans lecas d’effets non-conventionnels, un exemple del’algorithme pourrait être inclus.
Figure 6. Capture d’écran de Q-Live (Mai 2015).
Finalement, on pourra accéder à une deuxième interface
pleinement dédiée à la sauvegarde d’archive. Celle-ci
permettra au compositeur de compléter l’archive avec desfichiers qui ne sont pas inclus dans le logiciel, tels que desenregistrements vidéo d’une performance, une partition, ou
des commentaires. Cette partie de l’interface sera présentée
comme un formulaire et pourra aussi être utilisée
indépendamment du reste de Q-Live. Même si unutilisateur utilise un autre environnement audionumérique,
il peut tout de même profiter de ce formulaire qui générera
une archive dans un format standard.

2.4.2.

La mise en forme invoquée dans la description du GUI
nous permet d’envisager quelle forme prendra ledocument. Une description des évènements comprendrait
une liste des réglages des paramètres et des instructions
d’automation en format de listes.
2.4.3.

Concernant l’obsolescence technologique, nous avons cru
bon d’intégrer une sauvegarde d’archive efficacecomplètement indépendante du logiciel. Cette sauvegarde
comprendra une description générée automatiquement enformat .txt des effets utilisés (type d’effet, algorithmes sinécessaire) et une description des évènements déclenchés
dans une œuvre mixte (paramètres, automations,descriptions). Le choix d’utiliser la librairie Pyo développépar Olivier Bélanger s’est imposé.

Liste des fichiers sonores

Un dossier sera créé avec l’ensemble des fichiers sonoresd’une pièce. Q-Live assignera automatiquement un préfixe
standardisé aux noms des fichiers sonores pour assurerl’ordre des déclenchements.
2.4.4.

2.4. Le format de sauvegarde automatique de Q-Live

Description des cues

Captures d’écran

Nous croyons l’interface graphique de Q-Live
suffisamment claire pour instaurer une fonction decaptures d’écrans automatiques de chacun des événements.
Cette information visuelle sera complémentaire à ladescription des évènements et permettra de visualiser
rapidement le data flow.

5

Par exemple : Délais, distorsions, filtres, dynamique, EQ, spatialisation,
modulations, pitch, réverbérations, etc.

2.4.5.

Enregistrements d’archive

Il sera possible de sauvegarder une performance à mêmeQ-Live et de l’intégrer à la sauvegarde d’archive. Il serapossible d’enregistrer la performance de l’interprète (oudes interprètes) dans un fichier séparé et de l’œuvre, dansson entièreté (performance de l’interprète avec traitementset « bandes »), dans un autre fichier sonore.
2.4.6.

Commentaires du compositeur

Finalement, un petit éditeur de texte sera intégré au logiciel
pour que le compositeur puisse ajouter des commentaires
qui faciliteront la migration de l’électronique de sonœuvre.
L’arborescence des dossiers créés par Q-Live (Figure 7) etle contenu de ces dossiers pourront bien évidemment êtremodifiés par le compositeur s’il souhaite ajouter d’autres
informations.

Figure 7. Proposition d’arborescence de dossiers pour lasauvegarde d’archive dans Q-Live

3.

CONCLUSION

Sans vouloir prétendre solutionner tous les problèmes dela musique mixte, Q-Live propose une approchecomplémentaire à l’algorithmie musicale. Cette approche
est particulièrement adaptée à l’écosystème de la Facultéde musique de l’Université de Montréal où nous
retrouvons compositeurs, interprètes et musicologues
oeuvrant à la fois en création, en recherche-création et en
recherche. Le logiciel Q-Live sera intégré, par exemple,
dans le séminaire de Pierre Michaud intitulé « Composer
et interpréter la musique mixte » et dans les cours decomposition mixte dès 2015-2016. Le temps nous dira si
l’interface graphique et le workflow simplifié répondront
réellement aux besoins des compositeurs et des interprètes
et si l’information compilée dans le format de sauvegarde
automatique sera suffisante pour assurer la migrationd’œuvres mixtes créées en Q-Live.

4.

REFERENCES[1] Bélanger O. « Ounk - an audio scripting environment
for signal processing and music composition. » In
International computer music conference (icmc),
p.
399-402.
Belfast,Ireland,2008.
[2] Michaud, P., Constat d’une métamorphose. Centre demusique canadienne, Montréal, 2008.
[3] Molino, J. et Nattiez, J.-J., Musicologie générale etsémiologie. Christian Bourgeois Éditeur, Paris, 1987.
[4] Puckette, M. « The Patcher », ICMC Proceedings(1988), http://msp.ucsd.edu/Publications/icmc88.pdf[5] Vercoe B. L., Ellis D. « Real-time csound: Software
synthesis with sensing and control. » In International
computermusic
conference(icmc),
p. 209-211. Glasgow, 1990.
[6] Wright M., Freed A., Momeni A. « Opensoundcontrol: State of the art 2003. » In Conference on new
interfaces for musical expression (nime-03). Montréal,
Canada, 2003.
[7] Zattra, L., « Les origines du nom de RIM (réalisateur
en informatique musicale)», Actes des Journéesd’informatiquemusicale2013,
http://www.mshparisnord.fr/JIM2013/actes/jim2013_1
4.pdf