…à la recherche d’un environnement de travail sonore “en direct”

introduction : du besoin d’immédiateté

Depuis toujours, j’ai conçu la création sonore indépendamment de la pratique instrumentale; profitant de l’ubiquité de l’ordinateur¹, j’ai abordé la musique électronique par les trackers², puis par les “stations de travail audio-numériques”. À ces éléments se sont ensuite adjoints de nombreux autres logiciels de génération ou de transformation, mais toujours, la table de montage numérique³ est restée le pilier de mon travail.

Cette table de montage est un outil merveilleux, néanmoins j’ai commencé à ressentir le besoin de pouvoir fabriquer et modeler de la matière sonore en temps-réel. N’ayant aucune envie d’abandonner la souplesse des ordinateurs, mais souhaitant une interaction plus élaborée que le pointeur de souris, j’ai recherché une interface physique qui pourrait épouser des usages multiples et, pourquoi pas, simultanés.

(image monome)

En parcourant une vieille liste de marque-pages, je suis retombé sur un contrôleur qui m’avait intrigué par le passé, mais était, lors de cette première approche, en rupture de stock. Et pour cause, les “grilles” monome⁴ sont fabriquées en petites séries, et ont un succès certain. Elles ont d’ailleurs été largement reprises dans leur principe par des produits aujourd’hui omniprésents dans les musiques électroniques.

Le minimalisme du monome correspondait à mon besoin de flexibilité; j’en ai donc fait le premier élément de mon environnement de création. Le fonctionnement du monome est simple : il se relie en USB à un ordinateur, sur lequel tourne un petit programme⁵ qui convertit le protocole série en messages OSC⁶. Quand on presse ou relâche un bouton, un message est envoyé. On peut également envoyer des messages pour allumer ou éteindre la diode présente sous chaque bouton.

On peut ainsi l’utiliser pour communiquer avec une application, et bénéficier d’un retour visuel de celle-ci. Il existe de nombreuses applications conçues pour être utilisées avec le monome: la plupart sont fabriquées sous Max/MSP, mais n’importe quel langage avec une bibliothèque OSC peut être utilisé.

En voulant créer un environnement de travail, je voulais aussi qu’il soit unique et en correspondance avec mes attentes et préoccupations. Pour cette raison, je n’ai utilisé aucune des applications pré-existantes, et je me suis lancé dans la conception ex-nihilo.

dans le terrier du lapin : description générale

les fondations pour interagir

Mon choix de langage s’est porté sur ChucK: après en avoir essayé rapidement plusieurs autres, c’est celui qui m’a le plus parlé, notamment grâce à sa gestion explicite du temps.

La première étape a été d’écrire une classe pour interagir avec serialosc. Ensuite, comme je voulais avoir la possibilité de jongler entre plusieurs applications, j’ai fabriqué un intermédiaire (Pager.ck) servant à conserver l’état de chaque application en mémoire et à passer de l’une à l’autre facilement.

(video pager)

Parallèlement, j’ai écrit une classe mère pour chaque application destinée à être utilisée avec le “pager”. Chaque application hérite ainsi des fonctionnalités et méthodes de base nécessaires pour s’intégrer dans l’environnement.

Parmi les difficultés rencontrées, il a fallu éditer le code source de ChucK pour lui permettre de manipuler un plus grand nombre de messages OSC que ce qui avait été prévu par le programmeur⁷.

générer et transformer le son

Après une période de tâtonnements, liés à mon inexpérience en matière de programmation et de structuration du code, j’ai adopté un principe de séparation des fonctionnalités, inspiré par le monde des synthétiseurs modulaires : le rôle des applications Monome+ChucK sera donc de générer des commandes (gate, CVs…) envoyés par OSC à des modules de synthèse ou de transformation.

Pour ce rôle, ce sont des patches Csound invoqués depuis Pure Data qui seront utilisés. L’usage de trois langages différents est sans doute inutilement complexe, pour autant cela a du sens dans mon contexte. Il s’agit d’utiliser chacun dans le domaine où il sera le plus simple et le plus efficace à mettre en œuvre : ChucK avec sa gestion du temps, Pure Data et sa facilité à réaliser des connections audio entre divers objets, et Csound pour son efficience et ses vastes possibilités sonores.

retrouver ses propres traces

Dans ce cas d’un développement amené à se faire sur le long terme, il est important d’avoir un suivi et une documentation corrects. Tout est donc réalisé dans un dépôt Git avec une copie distante en guise de sauvegarde. Les applications, en particulier leurs interfaces utilisateur, font l’objet d’un document détaillant leur mode d’emploi et la nature des communications.

Étant donné la nature hautement mouvante de ce travail en cours, ce dépôt est privé. Il est vraisemblable que je rendrai public une partie du code à un moment dans le futur, lorsque les parties principales seront stabilisées.