OSC-bridge — un pont déclaratif vers 849 synthétiseurs

Donner une surface unique et nommée à un parc d’instruments — et la confier à un agent

Un agent IA qui se souvient et qui cherche, c’est utile. Un agent qui agit sur le monde physique, c’est autre chose.

Le problème : 849 dialectes

Un synthétiseur — qu’il soit un appareil physique ou un logiciel — doit bien recevoir des ordres de quelque part. Le problème, c’est que chacun parle son propre dialecte, et qu’aucun de ces dialectes n’est pensé pour un humain.

Pour piloter un synthé, il faut souvent :

  • connaître des numéros de CC (Control Change) — « le numéro 74, sur cet appareil, c’est la fréquence de coupure du filtre » — cryptiques et différents d’un modèle à l’autre ;
  • ou composer à la main des trames de SysEx (System Exclusive) — des suites d’octets bruts, au format inventé par chaque fabricant ;
  • et, dans tous les cas, deviner ce que l’appareil sait actuellement de son propre état, car il ne le dit pas spontanément.

Multipliez par le nombre d’instruments d’un studio, et piloter ce parc depuis un script, un logiciel de musique, un environnement de live coding ou un agent IA devient un travail d’archéologue.

Trois protocoles, en clair

Trois mots reviennent sans cesse ; autant les poser.

MIDI (Musical Instrument Digital Interface) est le standard de communication entre instruments numériques. Il date de 1983 — et il a remarquablement bien vieilli, au point d’être encore aujourd’hui la langue commune de la musique numérique. Mais c’est une langue minimale : elle transporte « note jouée », « molette tournée », sans dire ce que la molette signifie.

SysEx est la rallonge ouverte de MIDI : un espace laissé libre où chaque fabricant met ce qu’il veut, sous forme de suites d’octets brutes. C’est puissant et c’est l’enfer — il n’y a pas de norme à l’intérieur de SysEx, chaque appareil a son propre format.

OSC (Open Sound Control) est le protocole moderne. Sa bonne idée : les messages sont des adresses nommées, lisibles, organisées en arborescence — comme des chemins de fichiers. /filtre/coupure 0.65 se comprend tout seul. Là où MIDI dit « numéro 74 : valeur 95 », OSC dit « coupure du filtre : 65 % ».

Le motif du pont

L’idée d’osc-bridge tient en une image. Plutôt que de demander à chaque client (un script, un logiciel, un agent) d’apprendre le dialecte de chaque appareil — ce qui fait N × M traductions à écrire — on place un pont au milieu.

Le pont donne à chaque synthétiseur une surface OSC propre et nommée. Côté client, on n’écrit plus des octets de SysEx ni des numéros de CC : on envoie des messages lisibles.

 

/minilab3/pad/0/color 127 0 0      → allume le premier pad en rouge
/minilab3/knob/3/cc_number 64      → reconfigure la molette 3
/minilab3/display/text "Bonjour"   → écrit sur l'écran de l'appareil

 

Le pont, lui, traduit ces messages clairs dans le dialecte exact de l’appareil de destination. Et il le fait dans les deux sens : quand on tourne une molette sur l’appareil physique, le pont ré-émet l’événement sous forme d’OSC nommé. C’est ce qu’on appelle le motif du pont (ou de l’adaptateur) : un point de traduction unique entre des mondes qui, sinon, devraient tous se connaître mutuellement.

Déclaratif vs impératif : la connaissance comme donnée

Voici le choix de conception le plus intéressant du projet, et le plus transposable.

Comment le pont sait-il traduire pour un Prophet, un Oberheim, un Matrixbrute ? On pourrait écrire, pour chaque appareil, du code spécialisé — c’est l’approche impérative : « voici, étape par étape, comment parler à cet appareil ». Le défaut : ajouter un instrument demande de programmer, de recompiler, de redéployer.

osc-bridge fait le choix déclaratif : chaque appareil est décrit par un seul fichier de données — une trentaine de lignes qui énoncent ce qu’est l’appareil (ses numéros de CC, ses gabarits de trames SysEx, sa table de paramètres). Pas de code, pas de compilation. Le pont lit ce fichier au démarrage et en déduit la traduction.

La conséquence est spectaculaire. La connaissance d’un appareil n’est plus enfouie dans du code : c’est une donnée, qu’on peut lire, vérifier, partager, corriger sans être programmeur. C’est ce qui permet au projet de couvrir 849 appareils de 187 fabricants — la quasi-totalité du catalogue des synthétiseurs courants — là où une approche impérative se serait essoufflée à la dizaine. Ajouter le vôtre, c’est un fichier, pas un correctif de code.

Le même principe étend le pont au-delà du matériel : les logiciels de musique et de live coding — Ableton, Bitwig, Reaper, SuperCollider (I3), Pure Data — sont décrits par les mêmes fichiers et reçoivent la même surface nommée.

La provenance honnête

Un détail du projet mérite d’être souligné, parce qu’il relève d’une rigueur qu’on voit rarement.

Décrire 849 appareils, c’est forcément agréger des informations de qualité inégale. Certaines correspondances ont été vérifiées sur l’appareil physique ; d’autres sont recopiées d’une fiche technique du fabricant — théoriquement justes, mais jamais testées ; d’autres encore proviennent de bibliothèques communautaires.

Plutôt que de masquer cette inégalité, chaque fichier d’appareil déclare sa source : vérifié-matériel, vérifié-logiciel, dérivé-de-documentation, dérivé-de-preset-communautaire. L’utilisateur sait toujours s’il s’appuie sur une mesure ou sur une promesse. C’est l’équivalent, pour un catalogue technique, de la distinction entre un résultat reproduit et une affirmation non vérifiée — une honnêteté de méthode qui devrait être la norme et qui ne l’est pas.

Quand le déclaratif ne suffit pas — appareils avec sommes de contrôle, mises à l’échelle biscornues, protocoles à état — une trappe de sortie existe : de petits scripts exécutés dans un bac à sable strict. Ils sont utilisés avec parcimonie, et l’outil signale chaque recours. Le cœur reste déclaratif ; l’exception reste l’exception.

L’angle MCP : confier le parc à un agent

Reste la facette qui rattache cet article à la série. osc-bridge embarque un serveur MCP — le standard qui permet à un agent IA de découvrir et d’appeler des outils externes (voir A1).

Concrètement : un agent IA peut découvrir le catalogue des 849 appareils, lire la surface OSC d’un appareil donné, et lui envoyer des messages — le tout via cinq outils simples, sans code de colle. Dans une conversation, cela donne :

« Que peut faire le Matrixbrute ? Fais un balayage de la fréquence de coupure de son filtre. »

L’agent appelle l’outil qui liste les commandes de l’appareil, comprend quelle adresse OSC correspond à la coupure du filtre, et envoie la séquence de messages. Il a agi sur un objet physique.

C’est la facette « agir » de la série. RTFM donne une mémoire, NotebookLM donne de quoi chercher — mais ni l’un ni l’autre ne touche au monde extérieur. osc-bridge montre le troisième manque : un agent n’est vraiment équipé que s’il peut aussi faire, et le faire à travers une surface assez propre et assez nommée pour qu’il ne s’y perde pas. La même qualité d’interface qui rend le pont agréable pour un humain est exactement ce qui le rend exploitable par un agent.

Une remarque sur la genèse

Le projet n’a pas commencé grand. Il est né d’un seul besoin : piloter un synthétiseur Matrixbrute en OSC, son format de patch ayant été reconstitué par rétro-ingénierie à partir d’outils communautaires. Ce n’est qu’une fois la logique du fabricant Arturia devenue claire que le besoin d’un pont générique s’est imposé — et que le choix déclaratif a transformé un pilote unique en catalogue de 849 appareils. C’est un trajet fréquent : l’outil général n’est pas conçu d’emblée, il émerge quand on refuse de réécrire dix fois le cas particulier.

Ce qu’il faut retenir

  1. Chaque synthétiseur parle un dialecte propre et cryptique (CC, NRPN, SysEx). Piloter un parc devient un travail d’archéologue.
  2. MIDI (1983), SysEx, OSC. MIDI est minimal et increvable, SysEx est un espace libre sans norme interne, OSC apporte des adresses nommées et lisibles.
  3. Le motif du pont place un point de traduction unique entre des mondes qui, sinon, devraient tous se connaître — N + M traductions au lieu de N × M.
  4. Le choix déclaratif transforme la connaissance d’un appareil en simple donnée : un fichier, pas du code. C’est ce qui permet de couvrir 849 appareils.
  5. La provenance honnête. Chaque fichier déclare si sa correspondance a été testée ou seulement recopiée d’une fiche technique.
  6. L’agent qui agit. Une surface assez propre et nommée pour un humain est exactement ce qui la rend exploitable par un agent IA via MCP.

Glossaire

  • MIDI (Musical Instrument Digital Interface) : standard de communication entre instruments numériques, créé en 1983, toujours universel.
  • CC (Control Change) : message MIDI qui transporte une valeur de réglage, désignée par un numéro dont le sens varie selon l’appareil.
  • SysEx (System Exclusive) : extension ouverte de MIDI, suite d’octets bruts dont le format est propre à chaque fabricant.
  • OSC (Open Sound Control) : protocole moderne où les messages sont des adresses nommées et lisibles, organisées en arborescence.
  • Pont / adaptateur : motif de conception où un point de traduction unique relie des systèmes hétérogènes, leur évitant de se connaître mutuellement.
  • Déclaratif : approche où l’on décrit ce qu’est une chose (une donnée) plutôt que comment la traiter (du code) — par opposition à impératif.
  • Live coding : pratique consistant à écrire et modifier du code musical en direct, devant un public.

Pour aller plus loin

Dans cette série

  1. A1 — RTFM : rendre la mémoire à votre agent IA
  2. A2 — NotebookLM piloté : quand l’automatisation devient une API
  3. osc-bridge — un pont déclaratif vers 849 synthétiseurs ← vous êtes ici

Prérequis : A1 conseillé (notion de MCP)
Temps de lecture : 12 min
Tags : #MCP #osc-bridge #MIDI #OSC #déclaratif #musique

roomi-fields — vulgarisation à l’intersection des outils, des formalismes et de l’intelligence augmentée.

← Retour à l’index