Le protocole MIDI :
messages et running status

Structure des messages MIDI

Une belle image expliquant la structure des messages Midi se trouve dans "Le livre d'or de la norme MIDI" (Christian Braut, Sybex). Un message Midi est presenté comme un petit train, avec une locomotive et des wagons. Les rails représentent le câble midi support de l'information.

La locomotive est l'octet d'en-tête. Dans le cas qui nous intéresse, les messages Control Change et Note On, elle est suivie de deux wagons transportant l'information, chacun ayant un ròle spécifique. Ils ne sont pas interchangeables. Le premier représente le numéro de la note ou du contròleur, le second représente la valeur ou la vélocité.

Pour faire passer plus d'informations, il n'est pas nécessaire de répéter les locomotives (en-têtes) qui ont la même destination : on peut accrocher à la suite tous les wagons en respectant l'alternance numéro-valeur. Cela permet d'économiser un tiers de bande passante, ce qui n'est pas négligeable et d'atteindre les 1500 informations par secondes. C'est ce qu'on appelle le running status, chaque système devant garder en mémoire quel était le type de locomotive.

En revanche, cette particularité de la norme Midi peut poser problème, dans le cas où la locomotive n'a pas été vue.

Conséquences du running status Midi sur les actionneurs

En particulier, une carte qui démarre ou une carte qui a subi un débranchement/rebranchement du cable Midi n'a pas forcément vu passer l'en-tète. Par sécurité, elle se met en attente d'un nouvel en-tète pour réussir à interpréter correctement les informations qui circulent. Tant qu'elle n'a pas eu d'en-tète, elle laisse défiler l'information sans l'exploiter, elle ne peut mème pas différencier un numéro d'une valeur, elle ne sait pas si elle a affaire à un Note On ou à un Control Change, ...

Des logiciels comme Max MSP ou Pure-Data utilisent à fond la notion de running status. Cela peut provoquer des problèmes avec les cartes actionneurs. On observe parfois comme un dialogue de sourd : le logiciel envoie bien les informations, sans répéter l'en-tète, le cable Midi est bon, l'interface Midi-USB clignote, tout semble correctement branché, sauf que... la carte ne répond pas. En effet, à cause d'un démarrage tardif ou d'un débranchement/rebranchement à chaud, elle attend un nouvel en-tète pour se sentir concernée par les données.

La solution est toutefois simple : il suffit de forcer l'envoi d'un nouvel en-tète, ce qui peut se faire ponctuellement ou régulièrement. Pour cela, on envoie un message d'un autre type, non utilisé par la carte (par exemple un Pitch Bend ou un Poly After Touch), qui force le logiciel à envoyer un en-tète pour ce message différent ponctuel puis un nouvel en-tète pour les messages de commande qui nous intéresse. La carte, recevant cet en-tète, se resynchronise immédiatement et obéit ensuite au running status dépendant de ce nouvel en-tète.

Si vous êtes amené à beaucoup interrompre les alimentations des cartes actionneurs au cours du développement d'un projet, nous vous suggérons d'insérer un envoi récurrent de ce type de message dans vos patchs, avec un metronome (par exemple, voir patch).

Protocole Midi

Norme Midi et électricité