OSC, c'est quoi ? Wikipedia l'explique assez bien (en), et le site officiel vous fournira peut-être tous les détails complémentaires.
Il y a déja quelques mois que j'expérimente des trucs dans ce contexte. La première idée qui m'est venue est l'interfaçage d'un joystick, puisque j'ai déja pratiqué ça dans le passé. Ensuite, puisque il y a sound dans OSC, j'ai vaguement regardé ce que l'on peut faire avec Chuck piloté par osc.
Tous le code est dans le ZIP, avec des morceaux qui ne sont pas très aboutis. Coté dépendances, il y a du classique (ncurses pour gérer l'écran, libasound pour l'interface avec ALSA), et du plus spécifique (liblo pour causer OSC). Une page spaciale pour les détails crades, le format des messages que j'utilise, et de quoi l'avenir sera-t-il fait ?
Contrairement au MIDI, au langage très formel, le format des messages OSC propose une très grande souplesse, au détriment de la frugalité lexicale.
| chemin | type(s) | c'est quoi ? |
|---|---|---|
| /joystick/xy | i i | deux coordonnées entre -32768 et 32767 |
| /joystick/b | i i | numéro du bouton (0 à 255) enfoncement 1, relachement 0 |
| /joystick/id | s | texte d'identification du baton. |
Il y a une collection de fonctions prédéfinies pour gérer l'envoi de ces messages.
Pour commencer simple, j'ai choisi de traiter uniquement les deux premières valeurs analogiques, mais tous les boutons. C'est simple à faire, l'interface est bien documentée. Ensuite j'ai envisagé de visualiser toutes ces données. Dans un xterm. C'est à ce moment que j'ai compris. D'un coté, il y a les producteurs d'informations, et de l'autre coté, juste un peu en face, les (je n'arrive pas à trouver le terme exact, parce que « consommateur » est trop galvaudé de nos jours.) interpréteurs d'information.
La première partie (osc-joy) a été vite construite, en me basant sur joymidi. Elle envoie trois types de message : les coordonnées xy des deux premiers axes, la pression sur un bouton (on/off), et un identifiant texte modifiable. Le mode d'emploi est simple :
~/Essais/OSC/Poc-OSC $ ./osc-joy -h
* joystick -> osc Dec 27 2017 *
-r remote host (localhost)
-p remote UDP port (9000)
-j joystick device (/dev/input/js0)
-o offset added to button number
-v increase verbosity
-I change text id ("suck my stick")
Pour chaque joystick, la numérotation des boutons commence à 0. Le paramètre -o permet d'ajouter un offset aux numéros de boutons envoyés sur le fil. Ça a son importance dans certains cas d'utilisation, que nous allons bientôt voir. Vous pouvez maintenant lancer osc-joy, er regarder ce qu'il envoie avec l'indispendable oscdump, livré avec l'indispensable liblo.
~/Essais/OSC/Poc-OSC $ oscdump 9000 /joystick/id s "suck my stick" /joystick/xy ii 0 -32767 /joystick/xy ii 0 0 /joystick/b ii 5 1 /joystick/b ii 5 0 /joystick/xy ii -32767 0 /joystick/xy ii 0 0 /joystick/b ii 5 1 /joystick/b ii 4 1
Deuxième étape : tenter de visualiser les données émises par le baton de joie. Bien entendu, j'ai choisi d'utiliser ncurses(3X), parce que bon, voilà. La capture d'écran vous montre bien que ça peut être absolument choupi.
Là aussi les options de lancement sont simples, et (en principe) permettent de voir directement ce qui se passe en mode oscilloscope xy.
~/Essais/OSC/Poc-OSC $ ./osc2cursor -h
* osc2cursor Dec 27 2017 *
-p listening UDP port (9000)
-v increase verbosity
-E erasing button number (0)
-C drawing character (NA)
C'est donc muni de ces deux extrémités de la chaine évoquée plus haut (controleur-effecteur) que je réalise l'intérêt de ce protocole. Il est temps de passer au point suivant : faire du son. Comme toujours, j'ai trouvé une solution à base de lignes de code : Chuck, qui va pouvoir interpréter les changements d'état des boutons de la manette.
Mais avant de passer au son, une petite digression technique : pour un port UDP donné, il ne peut y avoir qu'un seul processus à l'écoute : c'est oscdump ou osc2cursor. Dans certains cas, c'est génant. Solution rapide : écrire un relais UDP qui peut renvoyer les messages vers plusieurs destinataires. Un petit bout de Python (oui, je sais :) qui lit un fichier de destinataires,
~/Essais/OSC/Poc-OSC $ cat destinations.liste
localhost:9000
localhost:7778
localhost:7777
10.20.0.22:9000
~/Essais/OSC/Poc-OSC $ ./relay.py
listening port : 5005
-> ('localhost', 9000)
-> ('localhost', 7778)
-> ('localhost', 7777)
-> ('10.20.0.22', 9000)
Et voilà nos messages dupliqués vers plusieurs endroits, et ce, sans le MOINDRE DPI, ce script ne sais même pas qu'il duplique de l'OSC. Une solution simple et efficace dans notre contexte de bricoleur. Mais revenons à notre mouton, le son.
Vous ne connaissez pas Chuck, mais ça n'est pas un souci, il y a des examples. Il suffit d'écrire des lignes de code, et d'interpréter les données OSC.
/joystick/b ii 0 1 /joystick/b ii 0 0 /joystick/b ii 5 1 /joystick/b ii 4 1 /joystick/b ii 5 0
Voir le script pouet.ck dans l'archive.
127 numéros de controles MIDI, 127 valeurs. Une source, un visualiseur. Ma première source est un Korg Nanokontrol. La programmation ALSA, c'est pas du flan, c'est pour ça que ce truc n'est pas fini.
Des sinusoïdales, des Lissajous, des courbes ésotériques... Peut-être même, si vous êtes sages, un peu de marche de l'ivrogne. Il y a deux examples dans le zip : lissajous.pl et moresinus.pl. En fait, c'est simple.
On s'adresse à un écran très grand : 65536 x 65536, taille encore assez improbable dans son salon. Ceci dit, avec une bonne (ou mauvaise, en fait) interpolation, on arrive à faire quelques trucs. Un de ces jours je tenterais un essai avec Processing.
Certains d'entre eux sont écrits en Perl, et ne servent pas à grand chose.
Last project of 2017 year, et celui-ci, je vais me le faire avec un vieux truc que j'aime bien : un synthétiseur d'évènement (coucou Barzi) pour rester interactif au delà du réel.
Du coté de Myrys, il y a aussi beaucoup d'effervescence dans des domaines proches, avec en projet une résidence autour de la lutherie électronique d'ici quelques mois.
Cette page a été mise à jour le 27 décembre 2017, mais le code continue d'avancer. stay tuned, film at 11, take your sixpack.