Un DJ charge un morceau sur la platine B. Le titre change à l’écran. Sauf que le public entend encore la platine A.

C’est un détail minuscule. C’est aussi exactement le genre de détail qui sépare une interface qui affiche l’état du logiciel d’une interface qui décrit ce qui est réellement en train de se passer.

PonAir est né de cette différence.1 Le petit outil open source, publié le 11 août, récupère les informations de rekordbox et les envoie dans une source navigateur d’OBS. Mais son idée intéressante n’est pas d’afficher le nom d’un morceau. Des outils savent déjà le faire. Son idée est de laisser les faders décider quel morceau mérite le statut « maintenant à l’antenne ».2

Cela paraît évident une fois formulé. Dans un mix, charger n’est pas jouer.

Le mauvais événement peut être techniquement parfait

La manière la plus simple de construire un affichage « now playing » consiste à écouter l’événement le plus facile à récupérer : un nouveau morceau vient d’être chargé, son titre est connu, on l’affiche.

Techniquement, tout fonctionne.

Sémantiquement, l’information peut être fausse pendant toute la transition.

Le DJ peut préparer la piste suivante longtemps à l’avance. Il peut la préécouter au casque. Il peut lancer le morceau avec son fader fermé. Il peut faire entrer la nouvelle piste progressivement, revenir à l’ancienne, couper brutalement ou rester un moment avec les deux decks audibles.

PonAir part donc d’une autre question : qu’est-ce que le public entend ?

Le programme observe le crossfader et les faders de canaux. Son README décrit une courbe de puissance et une hystérésis avec deux seuils, 0,55 et 0,45, pour éviter que le titre oscille lorsque le mix reste près du centre.1 Un délai de confirmation optionnel peut aussi ignorer une coupure très brève, utile pour certains styles de jeu où le fader bouge comme s’il avait quelque chose à prouver.

Ce n’est pas seulement un raffinement de DJ. C’est un principe d’interface assez général : le meilleur signal n’est pas toujours celui qui est le plus facile à lire dans le logiciel.

Une application peut savoir qu’un fichier est ouvert sans savoir lequel est regardé. Un outil de montage peut savoir qu’un clip est sélectionné sans savoir lequel contribue à l’image finale. Un logiciel musical peut savoir qu’une piste est chargée sans savoir ce qui sort réellement du master.

PonAir choisit l’événement qui correspond au sens humain de l’information, pas simplement au premier état disponible.

Le plus étrange : la donnée vient de l’accessibilité

Le projet ne capture pas l’audio. Il n’utilise pas de reconnaissance musicale. Il ne photographie pas non plus la fenêtre pour faire de l’OCR.

Il lit l’arbre d’accessibilité de rekordbox.

Sous Windows, le bridge utilise UI Automation. Sous macOS, il utilise l’API Accessibility d’Apple. Ces interfaces existent d’abord pour permettre aux technologies d’assistance de comprendre les éléments d’une interface : textes, contrôles, valeurs, rôles et hiérarchie.4 5

Autrement dit, l’application possède déjà une représentation machine de ce que son interface montre aux humains. PonAir s’en sert comme d’une petite API locale non officielle.

C’est une idée beaucoup plus large que rekordbox.

Depuis des années, les développeurs utilisent les arbres d’accessibilité pour les lecteurs d’écran et les tests automatisés. Microsoft documente explicitement UI Automation comme une infrastructure donnant un accès programmatique à la plupart des éléments de l’interface du bureau, notamment pour les technologies d’assistance et l’automatisation de tests.4 Apple expose de la même manière les éléments accessibles d’une application via AXUIElement.5

Avec les agents, cette couche prend une nouvelle importance. Quand une application n’a pas d’API, trois options reviennent souvent : manipuler des pixels, injecter quelque chose dans le programme, ou utiliser la représentation structurée que l’interface expose déjà.

L’accessibilité est parfois cette troisième voie.

Elle est moins élégante qu’une API publique et plus fragile qu’un protocole documenté. Mais elle peut être infiniment plus précise qu’un screenshot suivi d’une prière.

Une API fantôme, avec les défauts d’une API fantôme

Il ne faut pas transformer l’astuce en recette universelle.

Le README de PonAir prévient qu’une mise à jour de rekordbox peut modifier l’interface et casser le bridge à tout moment.1 C’est la conséquence directe de son architecture : AlphaTheta n’a pas promis que cet arbre d’accessibilité constituerait une API stable pour les outils tiers.

Le projet doit donc reconnaître les bons éléments, leurs valeurs et la disposition du mixer. Il documente actuellement rekordbox 7.x, Windows et macOS, les interfaces japonaise et anglaise, et le layout horizontal à deux decks. Le support quatre decks n’est pas encore là.1

Il y a une autre limite intéressante. PonAir ne prétend pas lire ce que l’arbre ne donne pas. Sur Windows, le niveau audio n’est pas exposé de la manière nécessaire. Le README dit donc simplement : pas de vu-mètre, pas de contournement prévu.1

C’est une décision saine. Un hack devient rapidement une usine à gaz lorsqu’il commence à inventer une seconde technique de capture pour chaque donnée manquante.

OBS devient juste le dernier centimètre

Une fois l’état déterminé, l’intégration avec OBS est presque banale.

PonAir envoie son état à un petit helper local, puis une page web transparente reçoit les changements par Server-Sent Events. OBS sait charger cette page directement grâce à Browser Source, son navigateur embarqué prévu pour les overlays, alertes, chats et autres interfaces web.3

Cette architecture sépare trois problèmes : lire rekordbox, décider quel deck est réellement actif, afficher le résultat.

Le projet prévoit même le cas où rekordbox et OBS tournent sur deux machines. Seul l’endpoint nécessaire à la réception du morceau est alors exposé sur le réseau local, tandis que le reste demeure sur localhost.1

Là encore, la bonne idée n’est pas spectaculaire. Elle consiste à ne pas transformer un overlay de texte en système distribué ayant soudainement besoin de Kubernetes pour afficher « Burial » en bas à gauche.

Le geste comme source de vérité

Ce qui rend PonAir intéressant pour IRZ n’est finalement ni Python, ni OBS, ni même rekordbox.

C’est la manière dont le projet définit sa source de vérité.

Le logiciel possède plusieurs états possibles : morceau chargé, morceau lancé, position du crossfader, position des faders de canaux. PonAir choisit celui qui correspond le mieux au geste du DJ et à l’expérience du public.

C’est une petite forme de design centré sur le travail réel.

On peut appliquer la même question à beaucoup d’outils créatifs : est-ce que notre interface décrit ce que le programme croit faire, ou ce que la personne est effectivement en train de produire ?

Les deux coïncident souvent. Les bons petits outils apparaissent précisément aux endroits où ils ne coïncident pas.

Et l’accessibilité devient une surface de création

Il y a enfin quelque chose d’assez beau dans le détournement lui-même.

Les métadonnées utilisées par PonAir existent parce qu’une interface doit pouvoir être comprise autrement que par ses pixels. Cette couche, conçue pour rendre le logiciel plus accessible, devient ici une surface d’interopérabilité pour un outil créatif.

Ce n’est pas une raison pour traiter l’accessibilité comme une API gratuite et oublier sa fonction première. C’est plutôt l’inverse : une interface correctement structurée devient plus lisible par davantage de formes d’outils.

Lecteurs d’écran, tests automatisés, utilitaires personnels, agents et petits bridges peuvent tous bénéficier d’une application qui sait nommer ses propres boutons, sliders et textes.

PonAir est encore minuscule. Au moment de notre vérification, le dépôt venait d’être créé et n’avait ni stars ni forks. Il n’existe donc aucune raison de le présenter comme un standard émergent.1

Mais comme expérience, il montre déjà quelque chose de plus durable : parfois, la meilleure API d’un logiciel fermé est la structure qu’il a dû exposer pour que son interface puisse être comprise sans la regarder.