Magento, son et lumière : WebMIDI et DMX

Le but de cet article est de présenter deux types de technologies que l'on ne rencontre que rarement dans l'E-Commerce : le WebMIDI et le DMX... Et pourtant... On va tout d'abord voir qu'il peut être intéressant à plus d'un titre d'interfacer Magento avec ces technologies, avant de voir quelques détails d'expérimentation.

Aspects fonctionnels

Interfacer un e-commerce avec des technologies "Son et lumière" peut présenter plusieurs aspects fonctionnels :

  • tout d'abord, il faut considérer que le protocole MIDI est un protocole qui est spécialisé initialement dans le monde de la musique, mais dispose néanmoins également de contrôles génériques qui sont laissés à la discrétion des constructeurs. En d'autres termes, on peut donc voir le protocole MIDI également comme un protocole de signalisation, au point où MIDI a prévu une spécification de MIDI Show Control, qui permettrait théoriquement de piloter divers équipements.
    En ce qui concerne les périphériques MIDI existants, il y a non seulement les synthétiseurs, mais d'autres périphériques également, comme des boutons poussoirs, des afficheurs… De ce fait, on pourrait éventuellement également penser à des utilisations non standards du MIDI, en utilisant dans d’autres milieux les périphériques MIDI (par exemple en milieu industriel, pour des usages spécifiques)
  • Ensuite, vient effectivement l’utilisation traditionnelle du MIDI pour faire passer des indications sonores. Comme le MIDI encode des informations de volume, de notes, on peut encoder des informations à destination des utilisateurs, soit en utilisant des sons de notes différents, soit en utilisant des instruments différents, ou même en utilisant les rythmes sur une même note ; un précédent connu est d’ailleurs les bips émis par le BIOS des ordinateurs
  • Vient ensuite le DMX au niveau de la lumière : on va pouvoir piloter via ce protocole un ou plusieurs projecteurs lumineux, par exemple, pour signifier l’état d’un système (pourquoi pas un système de feu tricolore rouge orange vert). Cependant, on peut piloter plus que la couleur elle-même, en fonction des modèles, ou également utiliser une entrée DMX pour récupérer des contrôles tels que des gradateurs. Il ne faut d’ailleurs pas sous-estimer les équipements DMX, car ils permettent des représentations visuelles, et peuvent contribuer au développement d’outils pour des méthodologies relativement visuelles telles que Kanban

WebMIDI

Le WebMIDI est une extension du protocole MIDI, qui permet surtout d’accéder aux interfaces (IN tout comme OUT) MIDI disponibles sur l’ordinateur depuis un navigateur, via du javascript. Ceci suppose donc de pouvoir comprendre les messages MIDI, ce qui a été facilité par la publication gratuite de la spécification de MIDI de 1996 par la MIDI Association (www.midi.org). Il suffit de s’enregistrer sur le site pour pouvoir y avoir accès.

Pour pouvoir tester le MIDI, on peut donc brancher l’ordinateur à un périphérique MIDI via un contrôleur sur USB par exemple (on en trouve à des prix abordables) - pour autant qu’on ait déjà un périphérique MIDI, tel qu’un orgue électronique ou un synthétiseur. Une autre solution est l’emploi de périphériques MIDI virtuels, comme par exemple FluidSynth, un synthétiseur midi logiciel, que l’on associera à VPMK, un clavier midi virtuel.

Par exemple, pour lancer fluidsynth et charger une fonte sonore en même temps, on pourra utiliser la commande :


fluidsynth -a alsa -m alsa_seq /usr/share/sounds/sf2/FluidR3_GM.sf2

Et ensuite, on peut lancer vmpk et le configurer pour faire transiter les signaux midi vers fluidsynth.

Avant :


jm@midi:~$ aconnect -i -l
client 0: 'System' [type=noyau]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=noyau]
0 'Midi Through Port-0'
client 129: 'VMPK Output' [type=utilisateur]
0 'VMPK Output '
jm@midi:~$ aconnect -o -l
client 14: 'Midi Through' [type=noyau]
0 'Midi Through Port-0'
client 128: 'FLUID Synth (2071)' [type=utilisateur]
0 'Synth input port (2071:0)'
client 130: 'VMPK Input' [type=utilisateur]
0 'VMPK Input

Connexion :


jm@midi:~$ aconnect 129:0 128:0

Après :


jm@midi:~$ aconnect -i -l
client 0: 'System' [type=noyau]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=noyau]
0 'Midi Through Port-0'
client 129: 'VMPK Output' [type=utilisateur]
0 'VMPK Output '
Connexion À: 128:0
jm@midi:~$ aconnect -o -l
client 14: 'Midi Through' [type=noyau]
0 'Midi Through Port-0'
client 128: 'FLUID Synth (2071)' [type=utilisateur]
0 'Synth input port (2071:0)'
Connecté Depuis: 129:0
client 130: 'VMPK Input' [type=utilisateur]
0 'VMPK Input '

On peut alors tester le clavier et le synthétiseur virtuels et entendre (si tout va bien) la musique.

Ceci permet de valider au minimum qu’on a une entrée et une sortie MIDI fonctionnelles. Il va s’agir maintenant de connecter d’une part le clavier midi virtuel et d’autre part le synthétiseur au navigateur, pour pouvoir justement récupérer et envoyer des messages MIDI. Pour résumer en quelques mots le fonctionnement de l’API (des explications détaillées se trouvent facilement sur le Net), on vérifie si l’API est disponible, on liste les entrées et les sorties MIDI, on écoute via de l’évènementiel les sorties MIDI (ce qui est en input) et on envoie les message MIDI sur les sorties sous forme de tableaux : ce sont donc des messages MIDI “bruts” qui transitent.

J’ai réalisé un petit développement d’une page me permettant simplement de bridger via WebMIDI vmpk et fluidsynth, ce qui permet d’exploiter (pour de l’affichage) les messages MIDI, ce qui valide au passage dans les deux sens le bon fonctionnement du MIDI.

webmidi

DMX

Le DMX, ou plus précisément DMX512 est une spécification plus simple que le MIDI : elle prévoit d’adresser jusqu’à 512 adresses avec l’allocation d’un octet pour chaque adresse dans ce qu’on appelle une “trame DMX”. Ce protocole est utilisé notamment pour gérer les éclairages lumineux. On trouve par exemple des contrôleurs DMX qui se branchent en USB sur un ordinateur, contrôleurs que l’on peut ensuite utiliser à travers des API. On trouve également des contrôleurs DMX avec des stacks réseaux intégrées. Pour ma part, j’ai pu acquérir pour un coût raisonnable un contrôleur qui se branche en USB et qui dispose d’une API utilisable sous linux - API qui se présente sous la forme d’une librairie et de fichiers de headers utilisables en C. De même j’ai acheté un simple projecteur DMX, qui permet notamment de spécifier quelle est l’adresse de base à utiliser, et sur lequel sont simplement envoyées sur 3 adresses contiguës les niveaux de rouge, vert et bleu à afficher. Le principe d’utilisation est assez simple, puisqu’il s’agit en gros, lorsqu’on veut émettre des ordres, de simplement transmettre l’équivalent de la trame DMX (dans mon cas, un tableau d’unsigned char) à l’API, après l’avoir initialisée.

montage dmx

Sur la photo, on arrive à deviner que l’indication utilisée par le projecteur est A001. Il est piloté par le DMX. J’ai utilisé une couleur avec du bleu à 255 à cause de la distance de convergence (plus importante que la profondeur du carton employé). En premier plan, le contrôleur DMX, avec le branchement XLR vers le projecteur.

Interconnection des systèmes : RabbitMQ

C’est là qu’on voit apparaître une difficulté de communication entre les différents participants. Avec le WebMIDI, on pouvait aisément considérer que de toute manière, on se retrouve à manipuler une API Javascript d’un navigateur, ce qui signifie qu’on peut par exemple communiquer simplement avec un serveur via des requêtes AJAX. Là, je me suis retrouvé à avoir trois environnements logiciels différents que j’ai voulu interfacer :

  • l’environnement représenté par le contrôleur DMX, pilotable avec du code en C
  • un navigateur web, pour pouvoir piloter un périphérique DMX depuis du javascript
  • les aspects serveurs de Magento, qui sont en PHP.

Dans ce genre de situation, la solution la plus simple est d’utiliser un middleware qui se laisse attaquer depuis tous les environnements requis. Dans mon cas, puisque Magento 2 EE prévoit l’utilisation de files de messages au travers de RabbitMQ, j’ai décidé justement d’utiliser RabbitMQ pour assurer la communication entre les environnements. J'ai souhaité faire simple, et j’ai donc utilisé le message proprement dit pour véhiculer les informations, ce qui nécessite donc également la mise en place d’une norme commune d’encodage des données - qui a été lors de mon expérimentation le JSON, disponible nativement dans les navigateurs et en php, et par exemple via la librairie jansson en C. Au niveau des files de messages, j’ai constaté que j’avais le nécessaire :

  • La librabbitmq pour le C : le consommateur de messages qui va agir sur le contrôleur DMX
  • Stomp.js pour le Javascript : la particularité de stomp est d’utiliser un connecteur différent des autres : le connecteur websocket (les autres utilisant le connecteur amqp)
  • Php-amqplib pour le PHP, qui s’installe dans Magento via l’utilisation de Composer. On pourra par exemple personnaliser l’installation de la librairie de sorte qu’elle se place dans lib en changeant la variable d’environnement COMPOSER_VENDOR_DIR avant de faire le composer install.

La logique est sensiblement la même dans tous les cas : il s’agit d’abord de se connecter au serveur, de créer un channel, et enfin de publier ou de consommer un message. Si l’on n’a pas configuré au préalable une file de message, il est également possible de la configurer depuis le code.

stomp_crop

En conclusion, on a pu voir que cet article a présenté une possibilité d’interaction “Son et Lumière” avec Magento, qui a surtout été l’occasion de mettre en évidence le rôle fondamental que peuvent jouer les middlewares dans certains systèmes, comme l’a été ici la gestion de files de messages. On constate avec les files de messages que l’interprétation du message lui-même est restée à la charge du niveau applicatif : le message transféré est une simple chaîne d’octets. Certes, il serait aussi envisageable d’utiliser les propriétés du message pour transférer l’information de manière plus structurée, mais cela reste encore loin des capacités (et de la complexité) d’autres types de middleware tels que RMI ou CORBA, qui permettent de proxifier des objets distants et de les utiliser à travers d’interfaces. L’interfaçage de tels middlewares avec PHP et Magento pourrait être un bon sujet pour un futur article.

Enregistrer

Enregistrer

Un commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *