RTP MIDI

En 2004, John Lazzaro et John Wawrzynek, de l'université UC Berkeley, firent une présentation devant l'AES nommée "An RTP payload for MIDI"[1]. En 2006, le document a été soumis à l'IETF et a reçu le numéro RFC4695[2]. En parallèle, un autre document fut écrit par Lazzaro et Wawrzynek pour donner les détails à propos de l'implémentation pratique du protocole RTP-MIDI, notamment le mécanisme de journalisation[3].

RFC4695 a été rendue obsolète par RFC6295 en 2011 (le protocole entre les deux documents n'a pas été modifié. La seconde version contient juste la correction des erreurs trouvées dans RFC4695)[4]

Le MMA (MIDI Manufacturers Association), qui centralise toutes les normes et recommandations liées aux implémentations ouvertes du système MIDI, a créé une page sur son site destinée à fournir les informations de base liées au protocole RTP-MIDI[5]. Un site central d'informations (visant les utilisateurs comme les programmeurs) a également été créé afin de répondre plus en détail aux questions liées à RTP-MIDI[6].

Apple Computers a introduit RTP-MIDI directement dans son système d'exploitation Mac OS X v10.4 en 2005. Le pilote RTP-MIDI est accessible à travers l'icône Réseau MIDI dans l'outil Configuration MIDI/Audio (dans le dossier Utilitaires). L'implémentation Apple suit strictement la spécification RFC4695/RFC6295 pour la charge RTP et le système de journalisation, mais utilise un système différent pour la gestion de protocole. Ce protocole est décodé dans Wireshark sous le nom "AppleMIDI".

Apple a également créé une classe spécifique dans leur implémentation mDNS (connue sous le nom "Bonjour"). Les appareils conformes à cette classe apparaissent automatiquement dans le panneau de configuration RTP-MIDI d'Apple, sous la forme d'un répertoire de participants, rendant ainsi le système AppleMIDI entièrement "Plug & Play". Il est toutefois possible d'entrer directement des adresses IP et des numéros de ports dans ce répertoire, afin de connecter des appareils qui ne supportent pas Bonjour.

Apple a également implémenté RTP-MIDI dans iOS4 et les versions suivantes, mais les appareils utilisant ce système d'exploitation ne peuvent pas devenir des initiateurs de sessions. Ils nécessitent donc un appareil ou un logiciel externe implémentant la fonction "Initiateur de session".

Le pilote RTP-MIDI d'Apple crée des ports MIDI virtuels (appelés "Sessions") qui deviennent disponibles comme une paire de port MIDI IN / MIDI OUT standards dans n'importe quel logiciel utilisant CoreMIDI (comme des séquenceurs ou des instruments virtuels), comme n'importe quel autre port MIDI 1.0 ou USB.

En 2006, la société néerlandaise KissBox a présenté les premières implémentations embarquées de RTP-MIDI, dans des produits comme des interfaces MIDI ou LTC[7]. Un pilote de périphériques propriétaires pour Windows XP avait été développé par la société, mais ce pilote limitait la communication avec leurs appareils (il n'était pas possible de connecter un PC avec un Mac par exemple en utilisant ce pilote). Néanmoins, les appareils eux-mêmes sont totalement conformes à l'implémentation AppleMIDI (utilisation du même protocole de gestion de sessions), et peuvent être utilisés avec les pilotes Apple sous Mac OS-X et rtpMIDI sous Windows. À la suite de la mise à disposition du pilote ouvert rtpMIDI de Tobias Erichsen, le support du pilote propriétaire a été abandonné, afin de développer une plateforme totalement homogène.

KissBox a annoncé en mai 2012 le développement d'un logiciel nommé "RTP-MIDI Editor", destiné à gérer dynamiquement les sessions entre les appareils et logiciels RTP-MIDI d'un réseau depuis un point central. Cette annonce a été suivie du lancement d'une nouvelle CPU (nommée « V3 »), capable de devenir un initiateur de session, permettant d'établir une connexion avec d'autres appareils sans nécessiter la présence d'un ordinateur. Cette possibilité permet notamment d'utiliser la CPU en tant qu'interface MIDI pour les appareils sous iOS qui ne disposent pas de la capacité de devenir des initiateurs de session.

Durant le NAMM 2013, la société iConnectivity (Canada) a présenté une interface de 4 ports MIDI In/Out avec connexion réseau Ethernet basée sur RTP-MIDI[8].

Le constructeur américain Mackie propose une famille de tables de mixages dont l'interface utilisateur est réalisée par un iPad[9]. Ces tables de mixage intègrent une liaison RTP-MIDI sur Ethernet, permettant d'utiliser jusque 10 iPad en réseau Wi-Fi pour la commande à distance.

Tobias Erichsen a mis sur le marché en 2010 une version pour Windows du pilote RTP-MIDI d'Apple[10]. Ce pilote fonctionne sous Windows XP, Windows Vista, Windows Seven et Windows 8, pour les versions 32 et 64 bits. Ce pilote utilise un panneau de configuration similaire à celui d'Apple, et est totalement compatible avec l'implémentation Apple. Il peut donc être utilisé pour connecter une machine Windows avec un ordinateur Macintosh ou des systèmes RTP-MIDI embarqués (claviers, synthétiseurs, consoles de mixage, etc.) Comme son homologue d'Apple, le pilote Windows crée des ports MIDI virtuels, qui deviennent disponibles pour n'importe quel logiciel fonctionnant sur le PC (l'accès se faisant au travers de la couche logicielle mmsystem, comme pour n'importe quel autre port MIDI sous Windows).

Les premiers travaux de portage du protocole RTP-MIDI sous Linux ont été réalisés par Nicolas Falquet et Dominique Fober, de l'institut GRAME[11] - [12]. Ces travaux visaient initialement la création d'un pilote système OSS. Une implémentation complète (y compris le système de journalisation) de RTP-MIDI est disponible sur la distribution Ubuntu dans la suite logicielle Scenic[13]. Un daemon RTP-MIDI pour le serveur JACK, appelé jackrtpmidid et spécifiquement compilé pour Linux, est annoncé pour le synthétiseur Open Source Zynthian[14].

Une implémentation du protocole RTP-MIDI sous Javascript a été mise en ligne sur Github par J.Dachtera en juin 2013[15]. Cette implémentation utilise le protocole de session décrit par Apple, et peut agir en tant que "Session initiator" et en tant que "Session listener"

La bibliothèque NMJ[16] permet une implémentation multiplateformes de RTP-MIDI sous Java.

Le projet WinRTP-MIDI[17] propose une implémentation open-source de la pile de protocole RTP-MIDI sous Windows. Initialement prévue pour être portable sous les différentes versions de Windows, la bibliothèque est maintenant optimisée pour être utilisée sous WinRT en vue de simplifier le développement d'applications pour le Windows Store.

En décembre 2013, deux membres de la communauté MIDIBox ont commencé à travailler sur l'intégration du protocole RTP-MIDI dans une nouvelle version du logiciel MIOS (MIDIBox Operating System), à travers un lien SPI (Serial Peripheral Interconnect) rapide. Afin de simplifier l'intégration, il a été décidé d'utiliser une carte de communication réseau externe chargée de la pile de protocole complète. Une première version "beta" a été diffusée début janvier 2014[18]. La première version officielle du logiciel a été diffusée durant la première semaine de mars 2014.

Le protocole utilisé sur le lien SPI entre le processeur MIOS et le processeur réseau est basé sur le même format que les télégrammes MIDI sur USB (utilisation de mots 32 bits contenant un message MIDI complet) et a été proposé comme standard ouvert pour la communication entre processeurs réseaux et carte d'applications MIDI.

RTP-MIDI a été inclus dans la plateforme ouverte Arduino en novembre 2013 (sous le nom "AppleMIDI library")[19]. Le module logiciel peut fonctionner sur les cartes Arduino disposant d'une interface Ethernet native, ou à travers le "Shield Ethernet" (un "shield" est une carte d'extension dans la terminologie Arduino). La bibliothèque RTP-MIDI ne nécessite pas un "shield" spécialisé, contrairement aux protocoles propriétaires.
Une autre solution pour la communauté Arduino a été présentée dans une note d'application publiée par la société KissBox pour leur module RTP-MIDI OEM. Cette solution est similaire à celle utilisée par la communauté MIDIBox (processeur externe de communication, connecté via un bus SPI rapide). Cette solution permet l'utilisation de cartes Arduino avec une quantité de RAM très limitée, telles que l'Arduino Uno, et permet de libérer complètement le processeur local pour l'utilisateur, car le module externe implémente l'intégralité de la pile de communication et agit comme tampon mémoire de stockage entre le réseau et l'Arduino.

La communication RTP-MIDI est également disponible pour le synthétiseur matériel Axoloti à travers le bloc logiciel "Axoloti-RTP"[20]. La carte Axoloti peut également être équipée d'un coprocesseur de communication RTP-MIDI via le bus SPI disponible sur le connecteur d'extension, selon le même principe que la solution disponible sur les plateformes Arduino et MIDIBox.

Comme RTP-MIDI est basée sur la pile de protocole standard UDP/IP, n'importe quelle application peut implémenter le protocole directement sans nécessiter un pilote de couche basse. Ces pilotes ne sont en fait nécessaires que lorsque l'on veut faire apparaître les ports MIDI du réseau RTP-MIDI comme des ports MIDI standards dans des logiciels. Des objets (« Externals ») pour Max/MSP et des plugins VST ont été développés suivant cette méthode et sont disponibles depuis le milieu de l'année 2012.

AVB est un ensemble de normes techniques qui définissent les spécifications pour la diffusion de flux audio/vidéo (« streaming ») sur réseau Ethernet avec des latences extrêmement faibles. Les réseaux AVB sont capables de tenir des latences aussi faibles qu'un seul échantillon audio (soit 20 microsecondes pour des flux audio à 48kHz) sur l'ensemble du réseau.

RTP-MIDI est compatible d'office avec n'importe quel réseau AVB, car les commutateurs réseau AVB (également connus sous le nom de « commutateurs IEEE802.1 ») gèrent automatiquement les priorités entre les flux audio/vidéo temps-réel et le trafic IP.

Toutefois, le protocole RTP-MIDI peut également bénéficier des possibilités temps-réel d'AVB si l'appareil implémente les messages RTCP décrits dans le document IEEE-1733[21]. Les applications RTP-MIDI peuvent alors corréler l'horloge de « présentation » (fournie par l'horloge Maître IEEE-802.1) avec l'indicateur temporel RTP, garantissant une distribution précise à l'échantillon près des messages MIDI.

Les documents RFC4695/RFC6295 découpent le système RTP-MIDI en différents sous-éléments. Le seul élément obligatoire (qui définit la conformité en tant que telle au protocole) est le format de la charge utile du télégramme. Le système de journalisation est optionnel (mais les messages RTP-MIDI doivent indiquer dans tous les cas qu'ils contiennent un journal, qui sera alors vide si la journalisation n'est pas activée) La partie liée au contrôle/gestion des sessions est quant à elle purement informative (et n'a d'ailleurs pas été utilisée par Apple, qui a créé son propre protocole de gestion de sessions)

Le document RFC6295 propose l'utilisation des protocoles SDP (Session Description Protocol) et SIP (Session Initiation Protocol) pour l'établissement et la gestion des sessions entre partenaires RTP-MIDI. Néanmoins, ces deux protocoles sont relativement lourds à implémenter sur les petits systèmes, d'autant qu'ils n'imposent aucune contrainte au niveau des paramètres énumérés dans la description de session (notamment la fréquence d'échantillonnage de laquelle dépendent tous les champs relatifs aux informations temporelles tant au niveau de l'en-tête RTP que de la charge RTP-MIDI). De plus, le document RFC6295 se limite à une proposition de protocole, autorisant l'utilisation de tout autre protocole, amenant à autant de situations potentielles d'incompatibilité entre fournisseurs.

Apple a donc décidé de créer son propre protocole de session, en imposant les paramètres relatifs à la synchronisation, notamment la fréquence d'échantillonnage. Ce protocole de session est appelé "AppleMIDI" dans le logiciel Wireshark. La gestion des sessions avec le protocole AppleMIDI nécessite deux ports UDP, l'un appelé "Port de contrôle", l'autre appelé "Port de données". Dans le cas d'une implémentation multi-threads, seul le port de données nécessite un thread à caractéristique temps-réel, l'autre port peut être géré par un thread de priorité plus faible. Ces deux ports doivent être placés sur deux numéros de ports consécutifs (n / n+1), le premier d'entre eux pouvant utiliser n'importe lequel des 65536 ports possibles d'une machine.

Il n'existe aucune contrainte quant au nombre de sessions pouvant être ouvertes simultanément sur un couple de ports UDP pour le protocole AppleMIDI. On peut donc soit créer autant de couples de ports qu'il y aura de gestionnaires de session dans un système, soit utiliser un couple unique pour plusieurs sessions (ce qui limitera d'autant l'empreinte mémoire dans un système). Dans ce dernier cas, la pile IP permet d'identifier le partenaire à partir de son adresse IP et de ses numéros de port (cette fonction est appelée "réutilisation des sockets" et est disponible dans la plupart des implémentations IP actuelles)

Tous les messages du protocole AppleMIDI utilisent une structure commune formée de 4 mots de 32 bits, dont l'en-tête contient deux octets contenant tous deux la valeur 255, suivi de deux octets représentant la fonction désirée:

Ces différents messages commandent une machine d'état propre à chaque session (cette machine d'état interdit par exemple l'échange de données MIDI tant qu'une session n'est pas passée en état "ouvert")

La préoccupation la plus fréquente concernant RTP-MIDI est la latence (et qui est d'ailleurs le sujet de discussion le plus fréquent dès lors que l'on parle des stations de travail audionumériques modernes), principalement en raison de l'utilisation des piles logicielles IP des ordinateurs. Il est toutefois très facile de démontrer qu'un logiciel RTP-MIDI (application ou pilote) ne produit pas plus de latence qu'une autre méthode de communication.

Qui plus est, le protocole RTP-MIDI tel que décrit dans RFC6295 comporte un mécanisme de compensation de la latence. Un système similaire existe dans la plupart des plugins audionumériques, qui peuvent informer leur hôte de la latence qu'ils ajoutent sur le chemin du signal audio. L'hôte peut alors envoyer les échantillons au plugin en avance, de façon que ceux-ci soient prêts et disponibles de façon synchrone avec les autres flux audio. Le mécanisme décrit dans RFC6295 utilise un système de marquage temporel (timestamp) relatif, basé sur le système MIDI appelé « deltatime » (tel que décrit dans[22]). Chaque événement MIDI transporté dans le message RTP comporte un champ de marquage temporel, dont la référence est donnée par le champ « Timestamp » de l'en-tête RTP.

Chaque événement MIDI transporté sur RTP-MIDI peut donc être précisément synchronisé avec l'horloge globale. La précision de la synchronisation dépend directement de la source d'horloge définie lors de l'ouverture de la session RTP-MIDI. Le document RFC6295 donne plusieurs exemples basés sur une horloge d'échantillonnage audio, afin d'obtenir une précision à l'échantillon près de chaque événement MIDI. L'implémentation d'Apple (ainsi que toutes celles qui en sont dérivées comme le pilote rtpMIDI pour Windows ou les systèmes KissBox) utilisent une horloge à une fréquence fixe de 10 kHz plutôt qu'une fréquence d'échantillonnage audio. La précision temporelle de tous les événements MIDI est donc de 100 microsecondes pour ces implémentations. Les horloges des émetteurs et récepteurs sont synchronisées lors de l'ouverture de la session, et sont maintenus synchronisés de façon cyclique par les initiateurs de sessions. Ce mécanisme a la capacité de compenser n'importe quelle latence, de quelques centaines de microsecondes (comme sur les applications LAN) jusque plusieurs secondes (ce qui le rend capable de compenser des latences telles que rencontrées sur Internet, rendant ainsi possible l'exécution en temps réel de morceaux de musique entre deux machines connectées via Internet)

Ce mécanisme est toutefois principalement conçu pour les flux MIDI pré-enregistrés, tels que ceux produits par une piste de séquenceur. Quand RTP-MIDI est utilisé pour les applications temps-réel, (par exemple, pour contrôler des appareils depuis un clavier de commande compatible RTP-MIDI[23]), le champ « deltatime » est le plus souvent mis à 0, ce qui indique que l'événement MIDI qui lui est attaché doit être interprété dès qu'il a été reçu. Le système de compensation de latence décrit ci-dessus ne peut alors pas être utilisé.

La latence obtenue pour ces applications temps-réel est directement dépendante des différents éléments logiciels et matériels du réseau qui se trouvent sur le chemin entre les appareils RTP-MIDI, à savoir:

• temps de traitement du logiciel MIDI
• temps de traitement de la pile logicielle IP
• temps de propagation à travers les routeurs/commutateurs réseau (« switches »)

La seconde préoccupation la plus fréquente concernant RTP-MIDI est le processus de configuration, car la connexion physique d'un appareil à un réseau n'est pas suffisante pour assurer une communication avec un autre appareil connecté au même réseau. Comme RTP-MIDI est basé sur une pile de protocole IP, les différentes couches impliquées dans le processus de communication doivent être configurées (configuration de l'adresse IP et des ports UDP à minima). Afin de simplifier cette étape, différentes solutions ont été proposées, la plus connue étant le groupe de technologies "Zero Configuration", également connue sous le nom "Zeroconf".

Le document RFC3927[25] décrit une technique répandue d'assignation automatique d'adresse IP, utilisée par la plupart des appareils compatibles RTP-MIDI sur le marché. Une fois connecté au réseau, un tel appareil est capable de s'attribuer seul une adresse IP, avec résolution automatique des éventuels conflits d'adresses. Si le même appareil suit les recommandations de la spécification RTP quant au choix des numéros de port UDP, il devient totalement "Plug&Play" du point de vue du réseau. Il est alors possible de créer un réseau RTP-MIDI sans avoir à définir les adresses IP et/ou les numéros de ports UDP. Il faut cependant souligner que ces méthodes sont souvent réservées aux petites installations. L'automatisation complète de la configuration est souvent évitée sur les grosses installations, car la localisation physique des appareils peut devenir complexe (pour le dépannage par exemple), par suite de l'absence de corrélation entre l'adresse sélectionnée automatiquement et la position réelle des appareils. Une configuration « à minima » serait alors d'assigner un repère ou un nom à l'appareil avant de le connecter au réseau, entrainant de fait la suppression du caractère « Plug&Play » de l'installation dans ce cas.

Il faut également noter que le concept « Zéro Configuration » se limite aux couches de communication. Il est techniquement impossible de réaliser l'installation complète d'un appareil connecté à un réseau (qu'il soit lié au MIDI ou non) juste par abstraction de la couche d'adressage. Un exemple pratique qui démontre cette limitation serait un générateur de sons contrôlé à distance par un clavier maître connecté à une interface MIDI sur réseau. Même si le générateur de sons et l'interface MIDI intègrent des services "Zero Configuration", ils sont incapables de déterminer par eux-mêmes qu'ils doivent établir une session commune pour échanger des données MIDI, car les services de configuration automatique n'agissent pas sur le niveau applicatif. Tout système MIDI basé sur un réseau, quel que soit le protocole utilisé pour échanger les données MIDI (qu'il soit compatible RTP-MIDI ou non) impose l'utilisation d'un outil de configuration afin de définir les échanges qui devront avoir lieu entre les appareils après leur connexion au réseau. Cet outil de configuration pourra être un logiciel externe qui s'exécute sur un ordinateur chargé de la gestion de l'installation, ou être directement intégré au logiciel applicatif d'un appareil (par exemple, sous la forme d'un menu accessible par l'interface Homme-Machine).

• Apple Computers (Pilote RTP-MIDI intégré dans Mac OS X et iOS pour l'ensemble de leurs produits) - RTP-MIDI sur Ethernet et Wi-Fi
• Yamaha (Synthétiseurs Motif, applications iOS de commande à distance[26], adaptateur Wi-Fi UD-WL01[27])
• Behringer (Surface de contrôle XTouch)[28]
• KissBox (Interfaces RTP-MIDI pour systèmes MIDI 1.0, LTC, Entrées/Sorties et DMX, plugins VST pour commande à distance de synthétiseurs matériels)
• Tobias Erichsen (Utilitaires et pilote RTP-MIDI pour Windows)
• GRAME (pilote pour Linux)
• HRS (Distribution de code temporel MIDI sur Ethernet / Logiciels de synchronisation)
• iConnectivity (interfaces MIDI)
• Zivix PUC (Interface MIDI sans fil pour iOS)[29]
• Mackie (Tables de mixage DL1608/DL806 pilotées par iPad)
• Arduino[30]
• MIDIBox[31]
• Cinara (Interface MIDI USB/RTP-MIDI)[32]
• BEB Digital Audio (Applications iOS compatibles RTP-MIDI)[33]
• Axoloti (Synthétiseur "patchable" open source)[34]
• Zynthian ("Open Synth Platform")[35] - [14]

L'association MMA (MIDI Manufacturers Association) a annoncé en Janvier 2019 qu'une évolution majeure du protocole MIDI, appelée MIDI 2.0 entrait en phase de prototypage[36].

MIDI 2.0 s'appuie sur l'extension MIDI-CI (officialisée en Janvier 2018), qui est utilisée pour la négociation du protocole (identification des appareils MIDI 1.0 et MIDI 2.0 pour permettre le choix entre les deux protocoles). RTP-MIDI est entièrement compatible nativement avec le protocole MIDI-CI, ce dernier utilisant le protocole System Exclusive basé sur MIDI 1.0, même sur les appareils MIDI 2.0.

Une évolution du protocole RTP-MIDI pour inclure les paquets propres à MIDI 2.0 a été présentée au MMA pour être évaluée par les membres du groupe de travail. Le protocole évolué permet l'échange simultané des données au format MIDI 1.0 et MIDI 2.0 (MIDI 2.0 utilise des paquets formés de mots de 32 bits, alors que MIDI 1.0 utilise des paquets codés sur la base d'un octet)

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « RTP MIDI » (voir la liste des auteurs).