Sommaire | Services Pro | Musiques | Publications | Connectique | Electronique | Logiciels | Divers | Contacts | Liens | Glossaire | Historique

Electronique > Théorie > La norme MIDI

Dernière mise à jour : 19/01/2020

Présentation

Il existe ici et là quantité d'informations concernant la norme MIDI, voici ma petite contribution ;-).


Brochage des prises MIDI

Le câblage des prises MIDI concerne plutôt la réalisation pratique des interfaces MIDI, pas besoin d'en connaître le détail si vous achetez vos interfaces et câbles tout fait.


midi_din_cablage_001

Câblage valable pour les prises MIDI IN, MIDI OUT et MIDI THRU. La borne 2 est reliée à la masse au niveau des sorties (OUT et THRU) mais pas au niveau des entrées, pour éviter toute boucle de masse entre équipements. Le câblage s'effectue entre les deux broches 4 et 5, selon détail suivant :

interfaces_midi_out_001a interfaces_midi_in_001a


Différence entre MIDI THRU et MIDI OUT

Il s'agit de deux prises MIDI de sortie mais qui ne jouent pas le même rôle.

Exemple avec un clavier synthétiseur doté des trois prises MIDI IN, MIDI THRU et MIDI OUT :

Remarque : à cause des temps de montée et de descente parfois élevés des optocoupleurs, il n'est pas conseillé de multiplier à outrance le chaînage MIDI THRU vers MIDI IN. On estime qu'il vaut mieux ne pas dépasser trois ou quatre "ponts".


Un jack TRS 2,5 mm en remplacement de la prise DIN 5 points ?

La norme MIDI 2 prévoit de pouvoir utiliser un mini-jack TRS (Tip-Ring-Sleeve) en lieu et place de la prise DIN-5, pour les appareils où la place est réduite. Fort heureusement, la réalisation d'un adaptateur DIN-5 vers Jack TRS est très simple :

- broche 2 du connecteur MIDI sur le manchon (Sleeve) du jack
- broche 4 du connecteur MIDI sur l'anneau (Ring) du jack
- broche 5 du connecteur MIDI sur la pointe (Tip) du jack

Principe général des liaisons MIDI

Les liaisons MIDI sont des liaisons de type série : on y transmet des informations binaires - informatiques - sur un "fil" unique (par rapport toutefois à un autre fil qui sert de référence). Afin d'éviter tout rebouclage de masse entre deux équipements reliés d'une part par un câble audio et d'autre part par un câble MIDI, ce dernier est branché sur une interface électriquement isolée du reste de la circuiterie de l'équipement (pour ce qui est de la partie électronique des prises MIDI, merci de vous reporter à la page Interfaces MIDI). 

Les données sont envoyées de façon asynchrone, c'est à dire qu'elles sont véhiculées de l'émetteur vers le récepteur sans être accompagné d'une horloge de "référence" permettant de savoir quand lire les données qui arrivent, comme c'est le cas avec les liaisons de type I2C et des liaisons entre clavier PS2 et ordinateur (un fil DATA et un fil CLOCK dans les deux cas). C'est aussi de cette façon que fonctionnent les liaisons série de type RS232, appelée COMx (COM1, COM2, etc). N'utiliser qu'un seul fil pour transmettre des informations permet d'économiser sur le câblage physique, mais demande en retour une grande rigueur, une grande qualité des données émises et notemment une bonne précision du rythme avec lequel les données sont transmises. Car le circuit récepteur, qui ne reçoit que les données et aucune information d'horloge, ne peut qu'être informé de la vitesse théorique sous laquelle les données vont arriver, et cherche à synchroniser sa propre horloge interne sur le rythme des données arrivantes. Bien sûr, on ne peut pas certifier à 100 % que les données émises vont l'être exactement à telle ou telle vitesse, il y a forcement une imprécision, une certaine tolérance, et le récepteur doit être en mesure de s'accomoder de petits écarts entre la vitesse théorique (par exemple 31250 bits par secondes) et la vitesse réellement constatée (par exemple 31200 bits par secondes). Comme ces écarts ne doivent pas être trop importants, il est nécessaire que l'émetteur qui envoie les données le fasse à un rythme le plus stable possible et le plus proche de celui attendu. Si ce point n'est pas respecté, le récepteur peut "décrocher" et ne plus reconnaitre du tout les données qui arrivent.


Transport des données

Dans le monde informatique, il est fréquent de travailler avec des nombres, catégorisés selon leur grandeur (on parle aussi de longueur). Ainsi, on peut travailler avec un nombre qui ne peut prendre que deux valeurs comme le bit, tout comme on peut travailler avec des nombres qui peuvent prendre 256 valeurs différentes comme l'octet (byte en angalis, à ne pas confondre avec bit). D'un point de vue machine, tous les nombres sont décrits par un nombre plus ou moins important de bits, mais un bit ne peut jamais prendre plus de deux valeurs différentes, qui seront toujours 0 ou 1. Pour plus de détails, voir page Informatique et nombres. S'il est facile de véhiculer sur un seul fil un nombre qui peut prendre deux valeurs (on envoie une tension ou on n'envoie rien du tout), il n'est pas facile d'envoyer en une seule fois un nombre qui peut prendre plus de deux valeurs, sachant que l'on reste dans le monde du numérique et que les valeurs intérmédiaires (entre 0 et 1) ne sont pas autorisées. On peut envoyer plusieurs informations en même temps en recourant à des procédés de modulation (porteuses et sous-porteuses), mais cela complique singulièrement la fabrication des circuits émetteurs et récepteurs, et en augmente le coût dans des proportions importantes. Il est bien plus simple et bien moins couteux d'envoyer les données les unes après les autres, à la queue-leu-leu, mais cela prend évidement plus de temps. Si cependant la quantité de données à envoyer n'est pas trop importante, et si le temps mis pour envoyer le tout n'est pas excessif, c'est une solution qui convient parfaitement. Et c'est ainsi que la norme RS232 et la norme MIDI travaillent, et de façon fort correcte quand les précautions élementaires - telles que qualité et longueur des câbles adaptées à l'usage, et notamment à la vitesse - sont respectées. 

Le principe de base est fort simple, nous allons le voir avec un exemple pratique. Supposons que nous ayons à transporter le nombre 45 d'un point à un autre, et qu'on ne dispose que d'un seul fil pour assurer le transport de cette information. Il va falloir décomposer ce nombre 45 en informations élementaires que sont les bits. Comme le nombre 45 est inférieur à 256, il rentre dans la catégorie des octets, codés sur 8 bits (rappel). Cela signifie que l'on peut envoyer à la que-leu-leu huit informations distinctes que sont les 8 bits de l'octet, pour véhiculer la valeur 45. Il ne reste au récepteur qu'à savoir qu'à quel moment, telle valeur reçue (0 ou 1) correspond à tel ou tel bit parmi les huit attendus. Bien sûr il ne faut pas qu'il se trompe car le moindre bit lu à la place d'un autre a de grandes chances de rendre la valeur reçue invalide. Le travail de récupération des bits reçus n'est pas aussi simple qu'il peut en paraitre, et c'est pourquoi des fabricants proposent ce qu'on appelle des UART, qui sont des composants spécialisés dans ce genre de travail. Un UART peut très bien être un composant électronique à part entière (un circuit qui ne fait que ce travail précis), tout comme il peut être intégré dans un autre composant tel un microcontrôleur. Pour simplifier, nous pouvons dire que côté émetteur on envoie (on écrit) les 8 bits de l'octet les uns après les autres, ce qui est équivalent à une conversion parallèle (8 fils) / série (1 fil). Et que côté récepteur, on lit les 8 bits de l'octet les uns après les autres et on les regroupe pour retrouver le nombre d'un seul bloc, composé de tous ses bits, ce qui est équivalent à une conversion série (1 fil) / parallèle (8 fils).


midi_liaison_serie_ps_sp_001a


En bas du synoptique ci-devant, nous voyons que chaque bit est transmis sur un seul fil après conversion parallèle / série, en commençant par le bit_0 et en terminant par le bit_7 (mais on pourrait aussi fort bien transmettre le bit de poids fort en premier et terminer avec le bit de poids faible). Le transfert de chaque bit est cadencé à une certaine vitesse, qui est celle de l'horloge CLK (CLK vient du mot CLOCK qui en anglais veut dire horloge) : le bit_0 est transmis au temps T0, le bit_1 est transmis au temps T1, etc., pour terminer avec le bit_7 transmis au temps T7. L'exemple est donné pour un nombre tenant sur 8 bits, mais le principe est rigoureusement le même pour des données tenant sur un nombre plus grand ou moins grand de bits. Disons qu'il est plus commun de trouver des informations de 8 bits ou des informations multiples de ce nombre, qui peuvent donc être décomposées en paquets de 8 bits (un octet). Par exemple, si on veut transmettre un nombre tenant sur 32 bits, on peut dire qu'on envoie un seul "double mot" (DWord) de 32 bits, ou que l'on envoie 2 mots (word) de 16 bits chacun, ou encore que l'on envoie 4 octets (byte) de 8 bits chacun. Dans tous les cas, ce sont bien 32 informations séparées (32 bits) qui sont transmises.
Pour les données MIDI, ce n'est pas plus compliqué : on envoie dans un fil électrique, un certain nombre d'octets (paquets de 8 bits) pour former un message. Et comme les besoins dans le domaine musical peuvent être variés, plusieurs types de messages ont été pensés, allant du message simple qui commande l'exécution ou l'arrêt d'une note, au message de type "exclusif" dont le contenu peut correspondre à la totalité des paramètres utilisateur d'un synthétiseur.

Messages MIDI

Comme cela vient d'être dit, il existe plusieurs types de messages MIDI, d'une longueur plus ou moins importante. Les messages les plus utilisés sont sans doute les messages de type NoteOn et NoteOff, qui indiquent à un instrument de musique électronique quand il faut jouer une note (NoteOn) et quand il faut cesser de la jouer (NoteOff). On peut trouver dans les messages MIDI deux catégories d'octets, qui sont les octets de Statut (Status) et les octets de Donnée (Data). Dans le texte qui suit, nous allons parfois parler en octets et parfois parler en bits - selon la circonstance, avec toujours en tête qu'un octet comporte 8 bits. Ce qui veut dire par exemple que s'il est indiqué qu'il faut envoyer 3 octets pour un message MIDI donné, cela correspond à l'envoi de 24 bits de données consécutifs. 

Attention cependant, envoyer 24 bits de données utiles ne signifie pas qu'il n'y aura en tout que 24 bits dans le message complet ! Chaque octet sera en effet encadré par un bit de Start, et par un bit de Stop. Pour un octet utile, nous avons donc 10 bits de données à transmettre, ce qui conduit à l'envoi de 30 bits si le message MIDI comporte 3 octets. La durée pendant laquelle chaque bit est transmis est de 32 us (microsecondes), ce qui revient à dire qu'un octet utile avec ses deux bits de Start et de Stop occupe un temps de 320 us. Un rythme de période 32 us correspond à une vitesse de 31,250 KHz (1 / 0.000032), ou encore 31,250 Kbauds (le baud exprime simplement le nombre de bits transmis en une seconde, il est donc équivalent à la fréquence de transmission).


Scission des octets

Si les messages MIDI sont composés de plusieurs octets, il est important de noter dès maintenant que certains octets peuvent se partager la place pour diffuser plusieurs types d'informations. Un octet comporte en effet 8 bits, et rien n'interdit d'utiliser 4 bits de cet octet pour transmettre une information, et d'utiliser les 4 autres bits pour transmettre une autre information, complètement indépendante de la première. Il serait en effet dommage de gaspiller des ressources, en s'octroyant un octet qui ne représentera jamais une valeur supérieure à 15 et qui pourrait tenir sur 4 bits. S'il faut transmettre deux valeurs qui chacune ne dépassent jamais la valeur 15, autant les faire entrer toutes deux dans un seul octet. Bien sûr, la méthode de "lecture" des bits n'est plus tout à fait la même, mais le principe reste le même. Prenons un exemple pratique pour voir ça de plus près. Dans la page Les nombres en informatique, nous voyons comment chaque bit d'un octet peut avoir un poids différent, le premier bit avec sa valeur de 1 et le huitième bit avec sa valeur de 128.


informatique_nombres_001db

Si on veut utiliser les 8 bits d'un octet pour véhiculer deux informations différentes tenant chacune sur 4 bits, il suffit de voir les choses de la façon suivante, avec les 4 bits "de gauche" à pied d'égalité (en terme de poids) avec les 4 bits de "droite". Au lieu d'additionner la valeur des bits positionnés à 1 parmi les 8 disponibles, on additionne d'abords la valeur des bits positionnés à 1 parmi les quatres premiers pour obtenir la première valeur, et ensuite on additionne la valeur des bits positionnés à 1 parmi les quatres derniers pour obtenir la deuxième valeur.

informatique_nombres_001fa

Sur ce dernier exemple, on dispose d'une première information correspondant au nombre 12 stockée sur les quatre bits de poids fort, et d'une seconde information correspondant au nombre 2 stockée sur les quatre bits de poids faible. Et devinez le meilleur : cette façon de faire permet d'écrire la valeur d'un octet avec deux caractère alphanumériques compris entre 0 et 9 ou entre A et F. Pour l'exemple précédent, on peut écrire l'octet sous la forme hexadécimale "C2", où le caractère 2 représente la valeur des quatres premiers bits (ceux de poids faibles, à droite), et où le caractère C représente la valeur des quatres derniers bits (ceux de poids fort, à gauche). Bien sûr, la correspondance entre valeur hexa et valeur décimale est plus évidente à établir quand on sait que A = 10, B = 11, C = 12, D = 13, E = 14 et F = 15. Voici quelques exemples de conversion binaire / hexa pour se faire la main :

00000000 = 00h = $00
11110000 = F0h = $F0
11111111 = FFh = $FF
00000011 = 03h = $03
00110000 = 30h = $30
00110011 = 33h = $33
01010101 = 55h = $55
10101010 = AAh = $AA

Remarque : une valeur héxadécimale peut être notée sous la forme XXd ou sous la forme $XX.

Types de messages

Tous les messages MIDI sont composés de plusieurs octets, et le premier permet de déterminer le type de message. Nous avons vu qu'il existe des messages de Statut et des messages de Donnée. Un octet peut prendre une valeur décimale comprise entre 0 (00000000 en binaire, $00 en hexa) et 255 (11111111 en binaire, $FF en hexa). Si la valeur du premier octet est comprise entre 0 et 127 (premier caractère du code hexa compris entre 0 et 7) alors nous avons affaire à un octet de Donnée. Si la valeur du premier octet est comprise entre 128 et 255 (premier caractère du code hexa compris entre 8 et F) alors nous avons affaire à un octet de Statut :

- de $00 à $7F (de 0 à 127 en décimal) : octet de donnée
- de $80 à $FF (de 128 à 255 en décimal) : octet de statut

Exemples :

00011011 = $1B = octet de donnée
01010000 = $50 = octet de donnée
11000000 = $C0 = octet de statut
11100001 = $D1 = octet de statut

Nota : le bit le plus à gauche (celui de poids fort) est forcement à 0 pour les octets de donnée et forcement à 1 pour les octets de statut.

Dans un message MIDI, on peut avoir un octet Statut suivi d'un octet Donnée. L'octet Donnée peut par exemple représenter une valeur quelconque, et l'octet Statut peut indiquer à quel paramètre de l'instrument donner la valeur de l'octet Donnée. En pratique, un message MIDI commence toujours par un octet de type Statut, qui indique précisement ce qui suit. Les messages de Statut servent généralement à :

- indiquer le type de données véhiculées dans la suite du message;
- indiquer un numéro de canal, utile pour savoir si l'instrument récepteur doit traiter les données qui suivent ou les ignorer.

Il est à noter que les octets Statut ne sont pas forcement suivi d'octet Donnée, c'est le cas par exemple des messages Système Temps réel.


Messages "Voix" et "Mode"

Les messages de type Voix peuvent englober les informations liées aux notes elles-même (hauteur note et force de frappe par exemple) ou permettre de modifier la configuration de l'appareil MIDI qui les reçoit (changement d'instrument ou des paramètres du son à jouer, par exemple). 

Le type (et le rôle) d'un message "Voix" est défini (ou se reconnaît) par les quatre premiers bits du premier octet qui le compose (en gras dans le tableau qui suit). Les quatre bits suivants du premier octet correspondent au numéro de canal MIDI (nnnn, de 0 à 15 pour canaux MIDI de 1 à 16). La longueur du message dépend de son type, elle peut être de 2 ou 3 octets.


Messages Voix et Mode Début Octet #1 Octet #2 Octet #3
NoteOff
(message voix)		 $8n 1000nnnn 0kkkkkkk
0-127		 0vvvvvvv
0-127
NoteOn
(message voix)		 $9n 1001nnnn 0kkkkkkk
0-127		 0vvvvvvv
0-127
After Touch polyphonique
(message voix)		 $An 1010nnnn 0kkkkkkk
0-127		 0vvvvvvv
0-127
Control Change (1)
(message voix)		 $Bn 1011nnnn 0ccccccc
0-119		 0vvvvvvv
0-127
Control Change (2)
(message mode)		 $Bn 1011nnnn 0ccccccc
120-127		 0vvvvvvv
0-127
Program Change
(message voix)		 $Cn 1100nnnn 0ppppppp
0-127		 -
After Touch de canal
(message voix)		 $Dn 1101nnnn 0vvvvvvv
0-127		 -
Pitch Bend (pitch wheel)
(message voix)		 $En 1110nnnn 0lllllll
0-127 (LSB)		 0mmmmmmm
0-127 (MSB)
 
nnnn = numéro de canal MIDI

A noter la particularité du message Control Change :

Messages Mode
Control Change (2)		 Début Octet #1 Octet #2 Octet #3
All Sound Off $Bn 1011nnnn 120 0
Reset All Controllers $Bn 1011nnnn 121 0
(sauf spécificité)
Local Control $Bn 1011nnnn 122 0 = Local Control Off
127 = Local Control On
All Notes Off $Bn 1011nnnn 123 0
Omni Mode Off $Bn 1011nnnn 124 0
Omni Mode On $Bn 1011nnnn 125 0
Mono / Poly Mode
(Mono Mode On = Poly Off)		 $Bn 1011nnnn 126 nombre de canaux
0 = Omni On
m = nombre de canaux (Omni Off)
Poly Mode
(Poly Mode On = Mono Off)		 $Bn 1011nnnn 127 0 = Poly Mode On (Mono Mode Off)
 
nnnn = numéro de canal MIDI

Message Notes (NoteOn, NoteOff)

Un message de type NoteOn est envoyé au moment où on appuie sur la touche d'un clavier. Tant que cette touche est maintenue enfoncée, il ne se passe rien du tout (le message NoteOn est parti une fois, et n'est pas répété). Un message de type NoteOff est émis quand on relâche la touche qui était enfoncée. Ces deux types de message NoteOn et NoteOff comportent chacune 3 octets. Ces trois octets comportent les informations suivantes :

- Type de message (première moitié de l'octet #1, bits 7..4)
- Numéro de canal MIDI (seconde moitié de l'octet #1, bits 3..0)
- Numéro de note jouée (octet #2)
- Force de frappe / vélocité (octet #3)

Le premier octet est un octet de statut, et les deux suivants sont des octets de donnée.


Numéro de canal MIDI

On peut disposer de 16 canaux MIDI sur une même liaison MIDI, pour faire jouer 16 sons d'instruments musicaux différents, par exemple. Les canaux MIDI sont numérotés de 1 à 16, et leur nombre informatique correspondant est compris entre 0 et 15. Cela signifie que la réception d'un code canal 10 correspond en fait au canal MIDI numéro 11. Toujours ce décalage infernal de une unité entre nombres traités en informatique (qui commencent par 0) et nombres traités par les gens normaux (qui commencent par 1). Tout comme l'information de type de message, le numéro de canal n'occupe que 4 bits. 

$x0 = canal MIDI numéro 1
$x1 = canal MIDI numéro 2
...
$xE = canal MIDI numéro 15
$xF = canal MIDI numéro 16

Et c'est ainsi qu'eut lieu le mariage entre type de message (4 bits) et numéro de canal (4 bits), tous deux ne formant plus qu'un seul octet (8 bits) :

$90 = NoteOn (9) sur canal MIDI numéro 1 (0)
$93 = NoteOn (9) sur canal MIDI numéro 4 (3)
$80 = NoteOff (8) sur canal MIDI numéro 1 (0)
$8F = NoteOff (8) sur canal MIDI numéro 16 (F)

Numéro de note

A chaque note à faire jouer par l'instrument de musique (do, ré, mi, etc) correspond un nombre compris entre 0 et 127. Au fameux LA3 (diapason ou tonalité du téléphone) correspond ainsi le nombre décimal 69 ($45 en héxa). A chaque fois qu'on veut descendre d'un demi-ton, on retranche 1 à cette valeur. Et à chaque fois qu'on veut monter d'un demi-ton, on ajoute 1 à cette valeur. Exemples :

DO-2 = 0d = $00
....
SOL3 = 67d = $43
SOL#3 = 68d = $44
LA3 = 69d = $45
LA#3 = 70d = $46
SI3 = 71d = $47
...
SOL8 = 127d = $7F

Comment se rappeler de ces correspondances ? Vous allez sans doute me trouver un peu coquin, mais on pourrait dire que deux personnes en position 69 sont au diapason (La)... Voici tout de même un petit tableau récapitulatif (valeur des notes en décimal, de 0 à 127) :

Octave
( -2 à 8
ou -1 à 9)		 Do Do# Re Re# Mi Fa Fa# Sol Sol# La La# Si
C C# D D# E F F# G G# A A# B
-2 (ou -1) 0 1 2 3 4 5 6 7 8 9 10 11
-1 (ou 0) 12 13 14 15 16 17 18 19 20 21 22 23
0 (ou 1) 24 25 26 27 28 29 30 31 32 33 34 35
1 (ou 2) 36 37 38 39 40 41 42 43 44 45 46 47
2 (ou 3) 48 49 50 51 52 53 54 55 56 57 58 59
3 (ou 4) 60 61 62 63 64 65 66 67 68 69 70 71
4 (ou 5) 72 73 74 75 76 77 78 79 80 81 82 83
5 (ou 6) 84 85 86 87 88 89 90 91 92 93 94 95
6 (ou 7) 96 97 98 99 100 101 102 103 104 105 106 107
7 (ou 8) 108 109 110 111 112 113 114 115 116 117 118 119
8 (ou 9) 120 121 122 123 124 125 126 127 - - - -

Force de frappe / Vélocité

La force de frappe est liée à la vélocité de la frappe de la touche : plus on tape fort et plus ça frappe vite. La vélocité est représentée par un nombre compris entre 1 (ppp / pianissimo, force de frappe minimale) et 127 (fff / fortissimo, force de frappe maximale). La valeur $40 (64 en décimal) est donnée comme valeur centrale par défaut (mp-mf / mezzo-forte). Cette information est bien sûr parlante pour un instrument de musique dynamique, qui sait faire entendre une différence sonore (autre que le volume) selon la force de frappe sur ses touches (attention aux sons d'orgue, qui généralement ne sont pas assujetis aux variations de vélocité).

Remarque : l'arrêt d'une note peut être commandée par la réception d'un message de type NoteOff, ou par la réception d'un message de type NoteOn associé à une vélocité de 0 (zéro). La valeur 0 ne doit donc pas être utilisée pour une info de type NoteOn si on veut jouer la note.

Quelques exemples de NoteOn et NoteOff

En résumé, 4 informations différentes sont transmises dans 3 octets :

[1sssnnnn] [0xxxxxxx] [0xxxxxxx]
 Statut     Donnée 1   Donnée 2

sss = type de message (001 pour Note On et 000 pour NoteOff)
nnnn = numéro de canal MIDI (compris entre 0 et 15)
xxxxxxx = valeur des données (compris entre 0 et 127)
Donnée 1 = hauteur de la note (69d pour le LA3, un exemple entre autres)
Donnée 2 = vélocité de la note (comprise entre 0 et 127, généralement $40 - soit 64 en décimal - pour un clavier non dynamique)

Exemple 1 : Démarrage note LA3 avec vélocité de $64 (100 en décimal)

[10010000] [01000101] [01100100]
 $90        $45        $64
 Statut     Donnée 1   Donnée 2
 NoteOn     LA3        100

Exemple 2 : Démarrage note DO1 avec vélocité de $75 (117 en décimal)

[10010000] [00100100] [01110101]
 $90        $24        $75
 Statut     Donnée 1   Donnée 2
 NoteOn     DO1        117

Exemple 3 : Arrêt note LA3 

[10000000] [01000101] [00000000]
 $80        $45        $00
 Statut     Donnée 1   Donnée 2
 NoteOff    LA3        0

Pour ce troisième exemple, une information de type NoteOn avec vélocité de 0 est aussi interprété en tant que NoteOff.

Messages Système

Les messages Système sont des messages qui ne servent pas à jouer des notes, mais à transmettre des informations de natures diverses, dont la priorité est plus ou moins forte. Un message système commence par un octet dont la valeur est comprise entre $F0 et $FF. Ces octets peuvent être transmis seuls (cas des messages temps réel) ou être suivis de plusieurs octets de donnée.


Messages de type SysEx (SYStem EXclusive)

Ce type de message ne s'adresse qu'à une seule marque d'instrument ou même à un seul modèle. C'est typiquement le genre de message que l'on utilise pour le transfert de grosses quantités d'informations, comme les "dump" d'une mémoire complète ou d'un son individuel. La construction d'un tel message doit répondre à quelques impératifs si on ne veut pas qu'un message adressé à un modèle d'instrument particulier soit reconnu par un autre modèle. Il est en particulier nécessaire d'inclure en début de message, un code qui est propre au constructeur et un autre code propre au modèle d'instrument. Heureusement, chaque marque a son code, et ne doit utiliser que le sien, ce qui en théorie interdit tout conflit entre marques différentes. Bien entendu, de tels messages peuvent être acceptés par un ordinateur équipé d'un séquenceur universel ou d'un éditeur / gestionnaire de blibliothèques sonores. Un message SYSEX commence par un octet de valeur $F0 et se termine par un octet de valeur $F7 (EOX). Hormis ces deux octets de début et de fin de trame, on dispose de quelques autres valeurs d'octet permettant par exemple d'indiquer la position en cours dans un morceau ($F2, pointeur de position).


Messages Temps réel

Ces messages sont prioritaires sur tous les autres car leur rôle est de donner des informations fortement dépendentes du jeu temps réel (live). Ces messages sont les plus brefs que l'on peut rencontrer dans la norme MIDI, ils sont composés d'un seul octet de Statut et ne sont suivi d'aucun octet de donnée. Tous les messages temps réel ont une valeur comprise entre $F8 et $FF.

Le message $F8 - horloge MIDI - est émis tous les 1/24 de noire, il s'agit d'une synchronisation appelée 24 PPQN (Pulses Per Quarter Note, pulsations par quart de note). Mon indicateur de tempo MIDI 004 extrait ce type d'information d'une liaison MIDI pour afficher en temps réel le tempo d'un morceau en cours de jeu.


Synchronisation entre équipements MIDI

Quand on veut synchroniser un équipement esclave (slave) sur un équipement maître (master) en passant par une liaison MIDI, il faut que le maître envoie régulièrement à l'esclave des informations lui permettant de savoir à quel endroit du morceau en cours de jeu on se trouve. Pour cela, le maître peut envoyer deux sortes de messages : MIDI Clock ou MTC (MIDI Time Code).


MIDI Clock

Le MIDI Clock est une horloge basée sur la mesure (beat) et le tempo d'un morceau en cours de jeu. Il est composé de 24 impulsions par quart de note (24 PPQN, Pulses Per Quarter Note), un quart de note représentant ici une noire sur la partition. Sur une signature rythmique binaire de 4:4, on compte 24 messages par seconde si le tempo est de 60 BPM (la mesure avec ses quatre noires se joue en 4 secondes), on en compte 48 par seconde pour un tempo de 120 BPM (la mesure avec ses quatre noires se joue en 2 secondes).

Comme le nombre de messages MIDI Clock transmis en une seconde dépend du tempo de l'appareil maître qui joue, l'appareil esclave peut suivre ses variations et donc ralentir ou accélérer. Le MIDI Clock permet à l'appareil esclave de suivre les ordres de marche-arrêt, de connaître le tempo, et s'il est bien conçu de savoir à quel endroit du morceau on se trouve (tous sont capables de cela en théorie, mais en pratique on note parfois des décalages lors de la reprise d'un morceau arrêté en plein milieu... et même parfois en cours de jeu, simplement à cause d'une perte de synchronisation). Les apareils récents gèrent désormais tous le pointeur de position (Song Pointer) qui permet si tout va bien de redémarrer le morceau n'importe où sans problème de synchronisation.

Remarques


SPP (Song Position Pointer)

Le pointeur de position SPP indique le nombre de 1/16è de notes écoulées depuis le début d'un morceau et s'utilise conjointement au MIDI Clock. Il permet de mettre au bon endroit un morceau qui a été arrêté et dont le curseur de position a éventuellement été déplacé pendant l'arrêt, c'est donc une bonne alternative au MTC (MIDI Time Code) quand ce dernier n'est pas implémenté. La valeur du message pointeur de position comporte 3 octets, un octet de statut $F2 et deux octets de données (tenant sur 14 bits, valeur maximale = $3FFF).


Exemple : pour une valeur de SPP égale à $F2 $00 $08 (valeur décimale 8), cela correspond à la position [8-1 * 1/16è de note], soit [1.75 Quarter Note]. En effet, le 1er pointeur de position (SPP 1) démarre au tout début du morceau (au 1er quart de note de la mesure 0).

midi_spp_midiclock_001a

MTC (MIDI Time Code)

Un message MTC (MIDI Time Code) comporte une information temporelle exprimée au format hh:mm:ss:ff (hours:minutes:seconds:frames, heures:minutes:secondes:trames), tout comme le code temporel SMPTE utilisé dans le monde audiovisuel professionnel. Non seulement il permet un positionnement plus précis de l'appareil esclave, mais en plus il permet de savoir précisément où l'on se trouve quand le morceau est stoppé puis repris en plein milieu. En cas de perte de synchronisation de faible durée, le retour à la normale est beaucoup moins problématique et passe même souvent inaperçu.


Quel type de synchronisation choisir ?

Le MTC (MIDI Time Code) est souvent préféré pour sa précision et sa bonne implémentation dans les appareils audiovisuels capables de se synchroniser sur une horloge MIDI. Aux débuts du MIDI (années 80), le MIDI Time Code était trop complexe et trop coûteux pour l'intégrer systématiquement dans les machines MIDI les plus "simples", lesquelles se contentaient alors du MIDI Clock bien plus simple à traiter. Mais le MIDI Clock peut aussi être très stable et ne poser aucun problème de synchronisation, surtout avec les appareils récents. En résumé :

Remarque : des messages MIDI Clock peuvent être dérivés de messages MIDI Time Code (l'inverse est possible, mais plus compliqué).


Transmission sans fil de données MIDI

Certaines utilisations scéniques empêchent l'utilisation de câbles classique et imposent l'emploi d'un couple [émetteur + récepteur] pour assurer la liaison MIDI entre deux points distants. Dans la pratique, un grand nombre d'émetteurs / récepteurs peuvent convenir pour cet usage, en passant par les infrarouges et par les ondes HF. On trouve d'ailleurs sur le marché des équipements annoncés spécialement conçus pour cette fonction, la majorité étant sur une base HF (433 MHz ou 2,4 GHz par exemple) pour permettre une plus grande liberté de mouvement (les infrarouges sont efficaces - même pour des distances supérieures à 10 m - mais impliquent une liaison en vue directe entre émetteur et récepteur). 

Bien qu'il soit possible de réaliser soi-même les deux élements d'une liaison HF avec des composants classiques, je préconise aux amateurs qui ne possèdent aucun appareils de mesure l'emploi de modules HF tout faits et préréglés. Parmi ces derniers, vous devez en choisir qui supportent le transport de données et écarter ceux conçus pour des applications purement audio. Pour une utilisation scénique et donc dans un environnement potentiellemnt perturbé par les accessoires annexes (gradateurs de puissance mal ou pas filtrés, autres sytèmes sans fil basé sur Wifi), mieux vaut utiliser un système de transmission éprouvé, qui de préférence permet de sélectionner un canal (une fréquence) d'émission. Cette "option" peut s'avérer fort pratique, surtout si plusieurs liaisons MIDI HF doivent être mises en oeuvre (brouillage assuré si équipements similaires proches et réglés sur des fréquences identiques). A noter à ce sujet qu'il existe des systèmes de transmission multi-canaux qui moyennant un seul couple [émetteur + récepteur] permettent plusieurs liaisons MIDI simultanées (pratique, mais sans grand intéret pour utilisation par plusieurs musiciens qui veulent garder leur autonomie). 

Dans le tout fait prêt à l'emploi, on trouve plusieurs solutions, dont l'ensemble MidAir de M-Audio (un peu limite côté portée avec ses 8 mètres) ou MidiStream de Kenton (plus pro mais plus cher) pour ne citer qu'eux. Certains modèles sérieux envoient systématiquement des informations MIDI de type "All Note Off" ou "Master Reset" lorsque le récepteur ne reçoit plus de signal HF, ce qui évite les Note On maintenues indéfiniment. 

On trouve aussi des systèmes de type "diversity" (deux antennes et deux circuits HF dans le même boîtier récepteur) fonctionnant selon le même principe que les système diversity employés pour les microphones sans fil. D'autres vont même jusqu'à proposer une liaison bi-directionnelle où le récepteur indique à l'émetteur la bonne réception des données (accusé de réception) pour que l'émetteur renvoie une nouvelle fois tous paquets non reçus (MidiWave de Innovel par exemple). Un must mais qui évidement se paie !


Deux instruments MIDI et une seule entrée MIDI ? Oups !

Si la sommation passive ou active de deux signaux audio analogique est simple, il en est tout autrement des données MIDI qui sont des signaux informatiques (numériques). Pour pouvoir amener sur une unique entrée MIDI des données provenant de plusieurs sources (sorties) MIDI, il faut un appareil spécial appelé "merger MIDI" et qui possède au moins deux entrées MIDI et une sortie MIDI. Cet appareil peut être "bête" et supporter un seul flux de données à la fois (une seule entrée MIDI peut recevoir des données à un instant précis) ou être "intelligent" et dans ce cas il accèpte la réception de plusieurs flux en simultané et gère les priorités. 

Dans la majorité des cas, mieux vaut utiliser un modèle intelligent, construit sur la base d'un microcontrôleur. Mais si pour une application précise vous savez qu'il n'y aura jamais deux sources MIDI actives en même temps, alors un merger simple sans microcontrôleur (juste quelques portes logiques) suffit. Exemple d'un merger MIDI simple. Faire soi-même un merger MIDI intelligent ? C'est possible, plein de personnes l'ont déjà fait, avec des microcontrôleurs basiques ou évolués (16F628, 16F88, 16F876, 18F452, Arduino et autres). Moi-même en ai élaboré un : MIDI merger 003.


Des interfaces MIDI auto-alimentées par la prise MIDI OUT ?

On trouve sur le marché des boîtiers spécifiques MIDI (distributeurs MIDI, mergeurs MIDI, etc) qui sont dits "passifs" et ne nécessitent aucune alimentation externe. Pourtant, ces boîtiers comportent de l'électronique, voire de l'intelligence (microcontrôleur). Comment donc alors se passer d'une alimentation externe ? La réponse est simple : il suffit d'utiliser la source de tension +5 V normalement présente sur la broche 4 d'une prise MIDI OUT (au travers d'une résistance de 220 ohms qui se trouve déjà à l'intérieur de l'équipement), et d'utiliser la broche centrale 2 qui est la plupart du temps connectée à la masse. Pour que cela fonctionne, il faut que les deux points suivants soient respectés :

Le schéma qui suit donne l'exemple d'un tel repiquage d'alim qu'on pourrait presque qualifier de "phantom".


midi_alim_auto_base

L'appareil "MIDI-alimenté" (noté UC sur le schéma précédent) doit consommer peu pour garantir son bon fonctionnement et aussi pour ne pas perturber le fonctionnement de l'appareil sur lequel il travaille "en parasite". Un fabricant connu de petits joujous MIDI indique que ses appareils (qui sont alimentés selon ce principe) fonctionnent encore avec une alimentation de 3,5 V. Un simple calcul nous dit que leur consommation max est de quelques mA (6,8 mA max pour être précis si la reprise d'alim est directe, sans diode série). En cas de court-circuit entre broche 4 et masse, le courant max (de court-circuit) est limité à quelque 22 mA par la résistance de 220 ohms en série avec le +5 V. La dissipation de puissance dans cette résistance est dans ce cas d'un peu plus de 100 mW, une résistance "normale" de 1/4 W tiendra le coup. Tout ça pour dire que vous pouvez expérimenter sans trop de crainte concernant votre appareil "source".

Quid de l'isolation galvanique (isolation électrique en courant continu) ?

On peut avec effroi se demander comment permettre une telle astuce, sachant que ce type de repiquage d'alimentation impose une recombinaison de la masse de l'équipement MIDI émetteur avec celle de l'équipement MIDI récepteur. Si on y regarde de plus près, cela n'est pas si gênant que ça, tant que l'équipement qui fait usage de ce repiquage ne possède pas d'autre liaison de masse en commun avec d'autres équipement. Dans le cas par exemple d'un filtre MIDI doté d'une seule entrée MIDI et d'une seule sortie MIDI, l'équipement reste "flottant" par rapport au reste de l'installation et cela ne porte nullement à conséquence. Il en est de même avec un merger MIDI à deux entrées MIDI (ou plus), tant qu'une seule entrée MIDI reste reliée à la masse (la ou les autres entrées restent isolées par l'optocoupleur et la sortie MIDI le sera aussi via l'optocoupleur de l'équipement qui fait suite).


Interface MIDI "USB-HOST" ?

Pour raccorder un instrument doté de prises MIDI sur un ordinateur, il faut intercaler entre les deux une interface MIDI-USB (prise MIDI mâle de l'interface à raccorder sur l'instrument MIDI, et connecteur USB de l'interface à raccorder sur l'ordinateur). Une telle interface MIDI-USB est un périphérique USB, très répendu et généralement peu coûteux. 

Là où cela se corse, c'est quand on veut raccorder un instrument "MIDI" doté uniquement d'un connecteur USB (normalement prévu pour être directement raccordé à un port USB d'ordinateur) à un appareil MIDI doté de prises MIDI. Dans ce cas de figure en effet, la prise USB de l'instrument s'attend à dialoguer avec un hôte (ordinateur) qu'il ne peut pas trouver. 

Pour solutionner ce problème, il faut utiliser une interface MIDI "USB-HOST" dont la section USB joue le rôle que jouerait un ordinateur, à savoir celui de gérer un périphérique USB (qui dans notre cas est l'instrument "MIDI" doté de son connecteur USB). A sa charge de convertir les données "MIDI over USB" en données MIDI traditionnelles. Exemples : Kenton Midi USB Host, Miditech USB MIDI Host.


Ouvrage de référence MIDI qui m'a servi bien souvent...

Un livre pas bien épais mais vraiment très bien écrit (je ne sais pas où le trouver désormais).


interfaces_midi_livre_midi_pratique
Le MIDI pratique - Jean-Paul Verpaux