OSC INTÉGRAL

OSC naît en 1997 au CNMAT, le Center for New Music and Audio Technologies de l'Université de Californie à Berkeley. Matt Wright et Adrian Freed le présentent à la conférence ICMC sous un titre programmatique : Open Sound Control: A New Protocol for Communicating with Sound Synthesizers.

Le contexte est précis. Les synthétiseurs de recherche du CNMAT tournent sur des stations de travail en réseau, pilotées par des gestes captés, des analyses temps réel, des contrôleurs expérimentaux. MIDI, conçu en 1983 pour relier des claviers par un câble série à 31 250 bauds, ne suit plus. Sa résolution de 7 bits écrase les nuances, son vocabulaire figé, note, vélocité, control change numéroté, ne sait pas nommer un paramètre de synthèse arbitraire, et son transport série ignore le réseau.

OSC répond par trois ruptures. D'abord, les données ne sont plus des entiers 7 bits mais des types machine complets : entiers 32 bits, flottants, chaînes, blobs binaires. Ensuite, un message n'est plus un statut opaque mais une adresse lisible, organisée en arborescence comme un chemin de système de fichiers : `/voices/3/filter/cutoff`. Enfin, OSC ne définit aucun transport propre. Il décrit un format de paquet, et laisse UDP, TCP ou tout autre canal binaire le véhiculer.

Cette dernière décision est la plus radicale. MIDI est un câble autant qu'un format ; il définit jusqu'à la tension électrique sur la prise DIN. OSC n'est qu'un format. Il hérite gratuitement de tout ce que le réseau sait faire : adressage IP, multicast, faible latence de l'UDP, fiabilité du TCP, traversée de l'internet. Un geste capté à Marseille peut piloter un synthé à Tokyo sans rien changer au protocole.

Un message OSC est une suite d'octets structurée en trois zones consécutives, toutes alignées sur des frontières de 4 octets.

La première zone est l'OSC Address Pattern : une chaîne ASCII commençant par `/`, terminée par un octet nul, complétée par des octets nuls jusqu'au prochain multiple de 4. C'est l'adresse de destination, par exemple `/synth/freq`.

La deuxième zone est l'OSC Type Tag String : une chaîne commençant par une virgule `,`, suivie d'un caractère par argument, décrivant le type de chacun. `,f` annonce un flottant ; `,if` un entier puis un flottant. Elle aussi se termine par un nul, complétée à un multiple de 4. Cette zone est la clé du décodage : sans elle, le récepteur ne saurait pas comment lire les octets qui suivent.

La troisième zone contient les arguments, encodés en binaire dans l'ordre annoncé par le type tag, chacun aligné sur 4 octets, en big-endian, l'octet de poids fort en premier.

L'alignement systématique sur 4 octets n'est pas décoratif. Il garantit que chaque champ tombe sur une frontière de mot mémoire, ce qui rend le décodage rapide et prévisible, sans recopie ni recalage. Le big-endian est le network byte order, la convention des protocoles réseau de longue date.

Prends `/synth/freq` avec la valeur flottante `440.0`. L'adresse fait 11 caractères ; on ajoute un nul et on complète à 12 octets. Le type tag `,f` fait 2 caractères, nul et complément à 4. Le flottant 440.0 occupe 4 octets. Le message entier fait 20 octets, sans aucun séparateur explicite : la structure se lit par les longueurs et les nuls de fin.

C'est ici qu'OSC se sépare le plus nettement de MIDI. Un control change MIDI s'adresse par un numéro de 0 à 127 dont le sens dépend entièrement de l'appareil qui le reçoit. Un message OSC s'adresse par un chemin lisible : `/synth/osc1/freq`, `/mixer/track/3/gain`, `/sensor/hand/left/x`.

Ce chemin est un OSC Address Pattern, organisé en arborescence par les `/`, exactement comme un système de fichiers. Chaque segment est un container ; la dernière feuille est une OSC Method, le point réel où une valeur agit. Le récepteur expose un address space, l'ensemble des adresses qu'il comprend, et chaque message vient frapper une ou plusieurs de ses méthodes.

Un ou plusieurs : car l'adresse d'un message n'est pas forcément littérale. C'est un pattern, qui peut contenir des jokers et frapper plusieurs méthodes d'un coup.

- `` remplace n'importe quelle séquence de caractères : `/synth//freq` frappe la fréquence de tous les sous-modules.
- `?` remplace un caractère unique : `/synth/osc?/freq` vise `osc1`, `osc2`, mais pas `osc10`.
- `[ ]` définit un ensemble ou un intervalle de caractères : `/synth/osc[1-3]/freq`.
- `{ }` liste des alternatives entières : `/synth/{osc1,lfo2}/freq`.

Le matching se fait côté serveur, au moment de la réception. Un seul message `/synth/*/level 0.0` peut couper toutes les voix d'un synthé. Cette adressabilité sémantique transforme le protocole : au lieu d'un dictionnaire de numéros à mémoriser, on lit une structure. Le namespace devient une documentation vivante de ce que la machine sait faire.

OSC ne suppose jamais le type d'une valeur. Chaque argument est précédé, dans le type tag string, d'un caractère qui le décrit. Quatre types forment le socle, présent dans toute implémentation.

- `i` : entier signé 32 bits, big-endian.
- `f` : flottant 32 bits IEEE 754.
- `s` : OSC-string, ASCII terminée par un nul et complétée à un multiple de 4.
- `b` : OSC-blob, données binaires arbitraires précédées d'un compte de 4 octets, puis complétées à un multiple de 4.

La spec 1.0 prévoit aussi des types optionnels, que les implémentations adoptent diversement. Les plus utiles portent une valeur :

- `h` : entier 64 bits. `t` : OSC-timetag 64 bits. `d` : flottant double 64 bits. `S` : symbole, comme une string mais sémantiquement distinct. `c` : caractère ASCII sur 32 bits. `r` : couleur RGBA sur 32 bits. `m` : message MIDI sur 4 octets, port, statut, data1, data2, soit MIDI encapsulé dans OSC.

Quatre types ne portent aucun octet d'argument. Leur valeur est le type lui-même.

- `T` : vrai. `F` : faux. `N` : nil, l'absence de valeur. `I` : infinitum, souvent utilisé comme impulse, un déclencheur sans donnée.

Ce dernier groupe est élégant. Envoyer `/gate ,T` transmet un booléen vrai sans consommer un seul octet d'argument : l'information tient entière dans le type tag. Un déclencheur d'événement, `/trigger ,I`, ne transporte rien d'autre que le fait d'avoir eu lieu.

Le typage explicite a une conséquence directe sur la précision. Là où MIDI plie toute valeur continue dans 7 bits, soit 128 paliers, un `f` OSC porte un flottant complet. Une fréquence de coupure, une position de fader, une coordonnée de geste gardent leur résolution native du capteur jusqu'au moteur sonore.

MIDI joue les messages dès qu'ils arrivent ; le tempo et la synchro vivent ailleurs, dans l'horloge MIDI. OSC règle la question à l'intérieur du protocole, avec les bundles.

Un bundle est un conteneur qui groupe plusieurs messages OSC, ou d'autres bundles, sous une seule estampille temporelle. Sa structure est stricte : la chaîne `#bundle` terminée par un nul sur 8 octets, puis une OSC Time Tag sur 8 octets, puis une succession d'éléments, chacun précédé de sa taille sur 4 octets.

Le timetag suit le format NTP : 32 bits pour les secondes écoulées depuis le 1er janvier 1900, puis 32 bits pour la partie fractionnaire de la seconde. La fraction sur 32 bits donne une résolution théorique d'environ 200 picosecondes. Le sens est sans ambiguïté : le récepteur ne joue pas le bundle à la réception, il le joue à l'instant indiqué par le timetag. Si l'instant est déjà passé, il le joue immédiatement.

Une valeur de timetag est réservée : `0x0000000000000001`, c'est-à-dire 63 bits à zéro et un bit de poids faible à un. Elle signifie immédiatement, joue tout de suite. C'est la seule valeur sentinelle du protocole, et la valeur par défaut de la plupart des messages simples qui ne sont pas emballés dans un bundle daté.

Deux propriétés découlent de ce mécanisme. D'abord l'ordonnancement : un émetteur peut envoyer en avance une rafale d'événements datés, et le récepteur les jouera au bon moment, ce qui absorbe la gigue du réseau. Ensuite l'atomicité : tous les messages d'un même bundle partagent le même instant et doivent être traités comme un groupe indivisible, ce qui évite qu'un accord arrive note après note.

OSC décrit un paquet, pas un canal. La spec parle de OSC packets portés par un mécanisme de transport quelconque, et n'en impose aucun. C'est ce qui rend OSC à la fois souple et parfois déroutant : deux implémentations correctes peuvent ne pas se parler si elles ne partagent pas le même transport.

L'UDP est le choix par défaut, presque universel en pratique. Un datagramme UDP a une frontière nette, et un paquet OSC y tient en entier : un datagramme égale un paquet, sans ambiguïté. UDP ne garantit ni la livraison ni l'ordre, mais sa latence est minimale et sans poignée de main. Pour du contrôle temps réel, où un message perdu est aussitôt remplacé par le suivant, ce compromis est presque toujours le bon.

Le TCP apporte la fiabilité et l'ordre, au prix d'une latence supérieure et d'une connexion à maintenir. Mais TCP est un flux continu d'octets, sans frontières de message. Il faut donc encadrer chaque paquet OSC. Deux méthodes coexistent : préfixer chaque paquet par sa taille sur 4 octets, ou employer l'encodage SLIP (RFC 1055), qui délimite les paquets par un octet marqueur dédoublé en cas de collision. La question du framing sur flux est précisément ce que la proposition OSC 1.1 a voulu standardiser en 2010, sans jamais être ratifiée ; la plupart des implémentations sont restées en 1.0 et gèrent le framing à leur façon.

Le WebSocket transporte OSC jusque dans le navigateur, ce qui ouvre les interfaces web temps réel ; le runner Raspberry Pi de RNBO l'utilise nativement, en parallèle de l'UDP. Le multicast enfin permet à un émetteur d'adresser un groupe de récepteurs d'un seul envoi, sur une adresse de groupe, utile pour synchroniser plusieurs machines sur scène.

Le choix du transport est un curseur entre latence et fiabilité. UDP pour le geste et le flux continu, où la fraîcheur prime sur l'exhaustivité ; TCP pour les commandes critiques qui ne doivent pas se perdre, un chargement de preset, un changement d'état.

OSC a un angle mort. Pour piloter une machine, il faut connaître ses adresses d'avance. Le protocole ne dit rien de la découverte : aucun message standard ne demande « quelles adresses comprends-tu, et de quel type ? ». En 1997, on lisait la doc du synthé et on tapait les chemins à la main.

OSCQuery comble ce vide. Proposé vers 2017 par Vidvox, éditeur de VDMX, avec d'autres acteurs de la performance temps réel, c'est une extension, pas une modification d'OSC. L'idée : un serveur expose son address space complet via HTTP, sous forme d'un document JSON. Une simple requête GET renvoie l'arbre des adresses, et pour chacune le type OSC, la valeur courante, l'intervalle autorisé, l'unité, l'accès en lecture ou écriture, parfois une description.

Le protocole fonctionne donc sur deux canaux. Le HTTP/JSON sert à la description et à la découverte, hors du chemin temps réel. L'OSC classique, sur UDP ou WebSocket, sert au contrôle réel, sur le chemin rapide. On interroge une fois pour savoir quoi envoyer, puis on envoie en OSC pur. La découverte sur réseau local s'appuie sur mDNS, le mécanisme Bonjour : les serveurs s'annoncent, les clients les listent sans configuration.

L'exemple le plus net aujourd'hui vient de Cycling '74. Quand un patch RNBO est exporté vers un Raspberry Pi, le runner OSCQuery génère automatiquement le namespace à partir des paramètres nommés et des inports et outports du patch. Le résultat est immédiatement browsable : `http://c74rpi.local:5678` renvoie le JSON complet, et le contrôle se fait sur `osc.udp://...:1234`. Tu exportes un patch, et tu obtiens un synthé matériel auto-décrit, sans écrire une ligne de mapping réseau.

Max 9 généralise la même logique côté desktop. Son OSC intégré expose automatiquement tous les objets à paramètre du patch, adressables en OSC sans câblage manuel. VDMX joue les deux rôles, serveur et client, et publie même une interface web auto-générée pour chaque surface de contrôle. La parenté conceptuelle avec MIDI 2.0 est nette : la Property Exchange de MIDI-CI poursuit le même but, rendre un appareil introspectable, mais par un chemin différent. Voir la fiche MIDI INTÉGRAL.

OSC n'a pas remplacé MIDI, et ce n'était pas le but réel. Les deux protocoles coexistent parce qu'ils répondent à des questions différentes. MIDI règne là où l'événement musical est discret et le clavier central : notes, vélocités, séquence, intégration dans une DAW. OSC règne là où le contrôle est continu, nommé, distribué : le geste, le réseau, l'installation, la haute résolution.

Le geste est le terrain naturel d'OSC. Un accéléromètre, une centrale inertielle, un suivi de caméra, une captation de mouvement produisent des flux de flottants à haute cadence. MIDI ne peut pas porter un mouvement lisse dans ses 7 bits ; un `f` OSC le transporte sans perte, sous une adresse parlante comme `/dancer/hand/left/accel/x`. La danse, le mocap, les installations interactives, les capteurs scéniques parlent OSC pour cette raison.

Côté scène et image, l'écosystème est dense. TouchDesigner et Notch consomment et émettent de l'OSC pour le mapping vidéo génératif. Resolume Arena et Avenue exposent un namespace OSC complet pour le pilotage de clips et d'effets. Les consoles d'éclairage de la famille ETC EOS publient une OSC Implementation, devenue un standard de fait dans le théâtre. TouchOSC, de Hexler, transforme une tablette en surface de contrôle OSC sur mesure. Côté DAW, Bitwig se pilote en OSC via des scripts contrôleur de son API, notamment ceux de la suite DrivenByMoss. Notable par son absence : Ableton Live n'a pas d'OSC natif ; on y accède par des ponts Max for Live, comme AbletonOSC, ou via le MIDI OSCQuery Helper qui publie un Live Set en OSC.

Sous tout cela, des librairies dans presque chaque langage. En C, liblo (Steve Harris, LGPL) est le standard de fait, socle de nombreux autres outils. En C++, oscpack (Ross Bencina) est compact et multiplateforme. Sur microcontrôleur, la librairie CNMAT OSC pour Arduino est écrite par Adrian Freed lui-même, coauteur d'OSC, ce qui la rend canonique pour le hardware. En art numérique, ofxOsc est l'addon OSC de openFrameworks, et oscP5 d'Andreas Schlegel celui de Processing. En Python, python-osc est pur et maintenu. En JavaScript, osc.js de Colin Clark gère UDP et WebSocket, ce dernier ouvrant le navigateur. Sur Swift, OSCKit est moderne et asynchrone. Dans Unity, extOSC pour l'usage général et OscJack de Keijiro Takahashi pour le temps réel exigeant. Ailleurs, JavaOSC sur la JVM, rosc en Rust.

Le partage est clair, et il faut le lire sans dogme. MIDI pour la note et le studio ; OSC pour le geste, le réseau, la scène et la haute résolution. Beaucoup de dispositifs parlent les deux, et les passerelles abondent. Voir la fiche MIDI INTÉGRAL pour l'autre versant de cette frontière.