|
|
|
|
|
|
|
Après les applications de type séquenceur et les extensions à la synchronisation MIDI/audio-vidéo, la seconde grande famille d'applications MIDI concerne la gestion et l'édition des mémoires des instruments.
Ces textes sont en grande partie extrait du manuel de référence MIDI de Christian BRAUT: "Le livre d'or de la norme MIDI" - Edition SYBEX.
Voici le sommaire de cette page:
|
|
|
 |
Pour revenir en haut de cette page, double-cliquez n'importe où dans celle-ci.
|
|
Les données stockées dans les appareils MIDI s'éditent et s'échangent avec l'extérieur par l'intermédiaire des messages exclusifs. Ces messages sont à la base du fonctionnement de différents types de logiciels, dont les utilitaires de dump, les bibliothécaires et les éditeurs.
Structure et contenu de la mémoire
Structure de la mémoire
Le cas de figure le plus simple est celui d'un synthétiseur programmable possédant un certain nombre de sons (par exemple 128). Sa mémoire est alors divisée en autant de cases que de sons (de programmes), chaque case étant constituée du nombre d' octets nécessaire à la mémorisation de l'ensemble des paramètres d'un son. Ce synthétiseur est dit programmable dès l'instant où ces paramètres sont mémorisables, et par conséquent stockés dans une mémoire à lecture et écriture (RAM). En admettant que l'ensemble des paramètres d'un son occupe 64 octets, la capacité totale de la mémoire sera de 8 192 octets (128 x 64).
Sur certains synthétiseurs, une partie des sons est programmée d' origine en mémoire morte (ROM), ce qui signifie que l'utilisateur se verra dans l'impossibilité de les éditer. Nous pourrions parfaitement imaginer qu'ici la mémoire est divisée en deux blocs de 4 096 octets (64 x 64), le premier en ROM (64 sons non programmables) et le second en RAM (64 sons programmables). Toutefois, rien n'empêche de sélectionner un son en ROM, de le modifier à volonté et d'en stocker la version éditée en RAM. L'avantage de la ROM est de procurer au musicien un certain nombre de sons supplémentaires pour un coût négligeable.
En réalité, qu'il réside en ROM ou en RAM, lorsqu'un son est sélectionné sur un synthétiseur ou sur un expandeur, soit directement du panneau avant, soit par l'intermédiaire d'un message MIDI de changement de programme, le contenu de la case mémoire correspondante est immédiatement transféré dans une mémoire supplémentaire appelée buffer d'édition. Ce n'est qu'à travers ce buffer, ou mémoire tampon, que le synthétiseur est capable de produire un son et que l'utilisateur a la possibilité de le programmer. Ainsi, l'édition des paramètres se répercute en temps réel dans cette mémoire temporaire qu'est le buffer d'édition. Une fois le son édité, il ne reste plus qu'à le stocker définitivement en le renvoyant dans l'une des cases de la mémoire RAM. Il s'agit de l'opération d'écriture. Tous les synthétiseurs ne sont pas capables de conserver en mémoire les données du buffer d'édition à la mise hors tension. Certains se réinitialisent systématiquement à l'allumage avec le premier son de la mémoire.
En résumé, lorsqu'un son est sélectionné depuis le panneau avant de l'appareil, ou par l'intermédiaire d' un message du changement de programme, il est immédiatement transféré dans le buffer à travers lequel l'instrument est capable de le jouer, et l'utilisateur de le programmer.
Dans la majorité des systèmes, il existe en réalité deux buffers d'édition, ou plus exactement un buffer de stockage et un buffer d' édition. Comme précédemment, dès la sélection d'un son, le buffer de stockage en reçoit le contenu afin que l'instrument soit en mesure de le jouer. Par contre, à partir du moment où l'utilisateur tente d'éditer le son en question, ce buffer de stockage est copié dans le buffer d' édition, qui devient alors le buffer de jeu, et dans lequel se répercutent toutes les modifications apportées. Généralement, l'écran LCD de l'instrument prévient l'utilisateur, par un moyen ou par un autre (affichage d' un point, étoile, lettre(s) clignotante(s), etc.), que le son courant vient d'être altéré.
En alternant entre ces deux buffers à l'aide d'une touche spécifique (compare, edit/recall, etc.), il est aisé de comparer à tout moment l'original au son édité, ou, pourquoi pas, le son édité à un nouveau son sélectionné (et par conséquent transféré dans le buffer de stockage). Dès l'instant où le résultat de l'édition semble satisfaisant, il ne reste plus qu'à l'écrire en mémoire pour qu'il remplisse de nouveau le buffer. Cette méthode présente l'avantage d'autoriser l'édition d'un son par étapes successives en sachant qu'à chaque instant il sera possible de faire marche arrière et de revenir au point de validation précédent (correspondant au dernier stockage du son édité). De plus, en sélectionnant par inadvertance un autre son au beau milieu d'une manipulation d'édition, celui-ci ne remplira que le premier buffer. A condition de ne pas éditer ce nouveau son, rien n'empêchera de récupérer l'ancien, encore présent dans le buffer d'édition. Dans les systèmes à buffer unique, ce dernier est à la fois utilisé pour le stockage et pour l'édition.
Le problème se complique avec les machines multitimbrales à l'intérieur desquelles plusieurs sons résident simultanément. Selon les appareils, il existe soit un buffer de stockage et/ou d'édition par voix de multitimbralité (Yamaha TX802, Roland D1O/D20/D110...), soit un buffer de stockage et/ou d'édition commun à l'ensemble des voix (Korg M1, WS...). Cette seconde solution restreint les possibilités d'édition, puisque l'utilisateur n' accède qu'à un seul son.
Si les appareils MIDI de la première génération ne contenaient qu'un seul type de données (de sons), il en va tout autrement des instruments actuels.
Les messages de dump
La limitation des mémoires
Dans les années 1990, en raison du prix de revient élevé de la mémoire vive (RAM), et de par la limitation du nombre de messages de changement de programme à 128 (sauf à utiliser le "bank select"), la capacité mémoire des instruments MIDI, de l'époque, est relativement restreinte. Ainsi, le nombre maximal de sons en RAM se monte à 32 pour un synthétiseur comme le DX7 Yamaha, à 60 pour le VFX-SD Ensoniq, à 64 pour les D50/D550 Roland, à 100 pour le Korg M1, à 128 pour les D10/D20/D110 Roland, et dépasse exceptionnellement cette valeur avec des expandeurs comme le Proteus Emu (192 sons), le K2000 Kurzweil (jusqu'à 1 000 sons), etc. Bien qu'il existe des cartes d'extension mémoire (ROM ou RAM) pour la plupart de ces appareils, elles sont loin de couvrir les besoins courants. En effet, il n'est pas rare que le nombre total de sons disponibles sur le marché pour tel ou tel synthétiseur dépasse la dizaine de milliers. D'où la nécessité de développer un protocole destiné à transférer les mémoires de l'instrument MIDI vers une unité de stockage externe, et, réciproquement, afin d' être en mesure d' accéder aux banques de sons existantes.
De l'interface cassette à l'interface MIDI
Les premiers synthétiseurs à proposer la sauvegarde et le chargement de leurs sons sur un support externe firent appel à une interface cassette. Après avoir converti les données constituant ces sons sous forme d'un signal enregistrable, il suffisait pour les sauvegarder de les transférer de l'instrument vers une simple cassette audio, et d'en recharger de nouveaux grâce à la manipulation inverse (le tout l'intermédiaire de prises d'entrée/sortie intégrées au synthétiseur, et de n'importe quel lecteur de cassette externe). Outre sa lenteur de mise en oeuvre, le principal inconvénient de ce système réside dans son manque de fiabilité (pertes fréquentes de données dues à l'altération de la bande magnétique). C'est pourquoi certains instruments le remplacèrent avantageusement par un lecteur de disquette, plus rapide et plus sécurisant. L'incorporation d' un lecteur par appareil multipliant d'autant le prix de revient global d'une installation MIDI, rares sont ceux qui en intègrent. D'où une solution universelle plus naturelle et moins coûteuse visant à stocker les mémoires de tous les instruments MIDI confondus dans un seul et unique lecteur de disquette (par exemple celui d'un micro-ordinateur). L'interface existant déjà, il ne restait plus qu'à mettre au point un procédé permettant d'y faire transiter le contenu des mémoires. Cette opération d'échange de données (vidage de la mémoire) porte le terme générique de dump. Elle autorise une unité MIDI incluant une mémoire vive programmable (synthétiseur, expandeur, console, etc.) à en transférer le contenu vers l' extérieur, ou à la remplir des données reçues.
La mémoire de chaque instrument MIDI diffère en taille et en contenu, ce qui rend difficile l' établissement d'une norme universelle de transfert de données à l'aide d'un seul et unique protocole MIDI. Celle-ci existe bel et bien aujourd'hui avec la norme General MIDI 2 pour les instruments entrant dans cette catégorie. Le dump véhicule des informations aussi variées qu'un unique paramètre de synthèse (fréquence de coupure, enveloppe...), qu'un son (voice, patch, preset...), qu'un ensemble de sons (bulk), qu'un pattern de boîte à rythmes, qu'une configuration de console de mixage automatisée, qu'une table d'assignation de changements de programmes, que des données de micro-accordage, et ainsi de suite.
C'est la raison pour laquelle la fonction de dump est prise en charge par la seule catégorie de messages propre à chaque constructeur : les messages "system exclusive" (SysEx). En effet, il est bien évident qu'un synthétiseur LA n'est pas concerné par les paramètres d'un synthétiseur FM et réciproquement, etc. Chaque constructeur utilise donc le MIDI pour y faire transiter les données propres à chaque appareil par l'intermédiaire des SysEx.
Par définition, le dump est un message exclusif contenant tout ou partie des données d'un instrument MIDI. En ce qui concerne le transfert de données, de l'instrument vers une unité externe (la sauvegarde), il chemine de la prise MIDI-Out de l'instrument vers la prise MIDI-ln de l'unité de stockage (le micro-ordinateur, un second instrument de même type, etc.). A l'inverse d'une unité externe vers l'instrument (le chargement), il chemine de la prise MIDI-Out de l'unité de stockage vers la prise MIDI-In de l'instrument.
En envoyant une requête à la plupart des appareils MIDI dotés d'une mémoire vive (RAM), ceux-ci retournent les données correspondantes sous la forme de dump. Cette requête porte le nom de dump request, et présente de nombreux avantages.
Il existe deux méthodes pour transmettre un dump de l'instrument vers l'unité de stockage. La première consiste à initialiser (déclencher) le dump directement depuis l'instrument grâce à la fonction adéquate, tandis que la seconde fait appel au message exclusif de dump request (demande de dump). Ce message, lorsqu'il est transmis par l'unité de stockage vers l'instrument, donne l'ordre à ce dernier de vider ses mémoires (ou, exactement, d'en acheminer une copie à la prise MIDI-Out). C'est une procédure d'automation (ou de télécommande) du transfert de données. Notez bien que certains instruments MIDI peuvent parfaitement n'implémenter que l'une de ces deux méthodes.
La norme MIDI stipule que tout message exclusif doit commencer par FOH et se terminer par F7H. Entre ces deux statuts, un nombre illimité d' octets de données est en droit de circuler. Seuls les messages en temps réel (horloge MIDI, MTC quarter, frame...) sont autorisés à s'intercaler entre deux octets d'un message exclusif de manière à maintenir si nécessaire une parfaite synchronisation. L'émission de tout autre statut interrompt la transaction.
Lorsqu'il est inférieur à 125 (7DH), l'octet qui suit FOH est chargé d'identifier le constructeur. On le nomme manufacturer's ID. Afin d'étendre le nombre de constructeurs potentiels, une valeur égale à zéro représente un cas particulier signifiant que l'identificateur utilise deux octets supplémentaires (soit 14 utiles, c'est-à-dire 16 384 combinaisons possibles). Rappelons que trois autres valeurs font exception à la règle : 7D pour un usage non commercial (universités, écoles, centres de recherche...), 7E pour les non real time (sample dump standard...), et 7F pour les liaisons real time (MTC...). Il s'agit là des impératifs imposés en matière de système exclusif En dehors de cela, chaque constructeur est libre de les exploiter comme bon lui semble.
Quoi qu'il en soit, l'expérience prouve que l'en-tête des messages de dump ou de dump request comporte un certain nombre d'informations dont la teneur est plus ou moins commune à une majorité d'instruments. Ce sont:
Concrètement, les messages exclusifs permettent de traiter les données que contient la mémoire d'un instrument MIDI à l'aide d'un micro-ordinateur et du logiciel adéquat (utilitaire de dump, bibliothécaire, éditeur...), avec tous les avantages que cela comporte (ergonomie, support de stockage bon marché...).
Parfois, l'utilisateur pourra être amené à gérer lui-même les messages exclusifs, soit, comme nous l'avons mentionné précédemment, en priant directement l'instrument de vider ses mémoires vers l'extérieur (en appuyant sur les touches appropriées, si elles existent), soit en automatisant la procédure par l'envoi d'un message de dump request. Insistons une dernière fois sur le fait que cette seconde solution, de loin la plus élégante, donne à l'unité sollicitée l'ordre de transmettre (de dupliquer) tout ou partie de ses données vers la prise MIDI-Out. Pour l'exemple, voici comment procède le constructeur Sequential Circuits. Les codes exclusifs ci-dessous ne sont donnés qu'a titre indicatif, afin d'illustrer la syntaxe des messages de dump et de dump request. Leur mise en oeuvre pratique avec d'autres instruments se fait suite à une lecture attentive du chapitre "messages exclusifs" du manuel utilisateur.
Le Prophet 5 de Sequential Circuits
Avant d'approfondir la programmation des dumps, voici la syntaxe des messages exclusifs des instruments de la série Prophet de Sequential Circuits (une société à qui la norme MIDI doit beaucoup), et plus précisément du Prophet 5, possédant 120 mémoires de sons.
Format du message de dump requestF0H (11110000) : statut de message exclusif 01H (00000001) : identification de Sequential Circuits 00H (00000000) : identification d'un dump request ppH (0ppppppp) : numéro du son à dumper (0 < 0ppppppp < 120) F7H (11110111) : EOXFormat du message de dump
F0H (11110000) : statut de message exclusif 01H (00000001) : identification de Sequential Circuits 01H (00000001) : identification d'un dump pour le Prophet 5 00H (0ppppppp) . numéro du son à dumper (0 < 0ppppppp < 120) ddH (0ddddddd) : les paramètres du son en question (48 octets) ... F7H (llll0lll) : EOX
Nous constatons d'une part que ces messages n'incorporent pas de notion de canal, et d'autre part que rien n'est prévu pour dumper d'un seul coup le contenu des 120 mémoires. Nous ne pourrons donc procéder ici qu' à un échange individuel de sons.
En étudiant le format d'autres instruments de la série, nous constatons que l'identificateur de dump request (00H) est commun au Prophet 600, 10, T8, VS, etc. Toutefois, chacun d'eux comporte en retour un identificateur de dump bien spécifique (02H, 04H, 03H et 0AH se substituent respectivement au 01H du Prophet 5). Cette formule de dump request commun constitue un cas d'exception. En règle générale, chaque demande de dump identifie avec précision l'instrument auquel elle s'adresse.
La méthode Yamaha
Le DX7 est également l'un des premiers synthétiseurs ayant implémenté une procédure de transfert de données. Or on retrouve ce type de synthèse FM à 6 opérateurs sur différents modèles de la marque (DX1, DX5, TX7, TF1, DX7II, TX802...). Le format des demandes de dump sera donc commun à l'ensemble de ces machines, de manière à préserver une compatibilité d'échange de sons à l'intérieur d'une seule et même famille.
Suite aux indispensables F0H (statut exclusif) et 43H (identificateur Yamaha), le troisième octet représente un sous-statut sur trois bits les plus significatifs (bits 4 à 6), ainsi qu'un numéro de canal sur les quatre bits les moins significatifs (bits 0 à 3). Le sous-statut est destiné à préciser le type de message (dump ou dump request), le dump request étant représenté par le chiffre 2 (010). Cet octet de sous-statut/canal est suivi d'un numéro de format dont la valeur correspond à la catégorie de données : 0 pour un son (voice) et 9 pour un bloc de 32 sons, etc. Le statut F7H (EOX pour End Of eXclusive) ferme la marche.
Format du message de dump request d'une seule voiceF0H (11110000) : statut de message exclusif 43H (01000011) : identification du constructeur (43H = Yamaha) 2nH (0010nnnn) : sous-statut/canal (2=dump request, n = canal) 00H (00000000) : numéro de format (0 = une seule voice) F7H (11110111) : EOXFormat du message de dump request des 32 voices
F0H (11110000) : statut de message exclusif 43H (01000011) : identification du constructeur (43H = Yamaha) 2nH (0010nnnn) : sous-statut/canal (2=dump request, n = canal) 09H (00000000) : numéro de format (9 = 32 voices) F7H (11110111) : EOX
En retour, le dump revient du DX7 en commençant par quatre octets identiques à ceux de la demande (mis à part la valeur 2 du sous-statut qui, égale à zéro, précise qu'il s'agit plus d'un dump request, mais d'un dump), pour suivre par les données elles-mêmes (précédées de deux octets en indiquant le nombre), le checksum (voir plus loin) et le statut de fin d'exclusif (F7H).
Format du message de dump d'une seule voiceF0H (11110000) : statut de message exclusif 43H (01000011) : identification du constructeur (43H = Yamaha) 0nH (0000nnnn) : sous-statut/canal (0=dump, n = canal) 00H (00000000) : numéro de format (0 = une seule voice) 01h (00000001) : compteur de poids fort du nombre de données 1BH (00011011) : compteur de poids faible du nombre de données ddH (0ddddddd) : données de voice (155 octets) ... ccH (0ccccccc) : checksum F7H (11110111) : EOXFormat du message de dump des 32 voices
F0H (11110000) : statut de message exclusif 43H (01000011) : identification du constructeur (43H = Yamaha) 0nH (0000nnnn) : sous-statut/canal (0=dump, n = canal) 09H (00000000) : numéro de format (9 = une seule voice) 01h (00000001) : compteur de poids fort du nombre de données 1BH (00011011) : compteur de poids faible du nombre de données ddH (0ddddddd) : données des 32 voices (4096 octets) ... ccH (0ccccccc) : checksum F7H (11110111) : EOX
Les messages de dump et dump request précédents n'intègrent pas à proprement parler d'identifiant précisant à quel type ou à quelle famille d'instruments ils s'adressent (en l'occurrence les synthétiseurs 6 opérateurs). Yamaha a tenté par la suite de normaliser la syntaxe de ces messages en élaborant un format commun à l'ensemble de ses produits.
En matière de dump request, l'octet de sous-statut/canal est suivi d'un octet précisant le type de format du message (7EH) et d'un en-tête sur 8 octets. Sauf exception, les quatre derniers octets de cet en-tête identifient en ASCII le numéro du produit (8387 pour la DMP11, 8976 pour le TX81Z, etc.), tandis que les quatre premiers, toujours en ASCII, correspondent aux lettres "LM" (pour LM Division, Nippon Gakki Ltd, participant au développement logiciel des instruments) suivies de deux espaces. Les deux octets qui suivent identifient le type de mémoire à transférer (à la manière des numéros de formats des "six opérateurs"). Au message de dump, il convient d'ajouter les deux octets de comptage du nombre de données, les données elles-mêmes, ainsi que le checksum.
Format du message de dump request
F0H (11110000) : statut de message exclusif
43H (01000011) : identification du constructeur (43H = Yamaha)
2nH (0010nnnn) : sous-statut/canal (2=dump request, n = canal)
7EH (01111110) : type de format
4CH (01001100) : premier octet d'en-tête ("L" en ASCII)
4DH (01001101) : deuxième octet d'en-tête ("M" en ASCII)
20H (01001100) : troisième octet d'en-tête (" " en ASCII)
20H (01001100) : quatrième octet d'en-tête (" " en ASCII)
wwH (0wwwwwww) : premier octet du type d'instrument (caractère ASCII)
xxH (0wwwwwww) : deuxième octet du type d'instrument (caractère ASCII)
yyH (0wwwwwww) : troisième octet du type d'instrument (caractère ASCII)
zzH (0wwwwwww) : quatrième octet du type d'instrument (caractère ASCII)
ggH (0ggggggg) : premier octet de format de données
hhH (0hhhhhhh) : deuxième octet de format de données
F7H (11110111) : EOX
Format du message de dump
F0H (11110000) : statut de message exclusif
43H (01000011) : identification du constructeur (43H = Yamaha)
0nH (0010nnnn) : sous-statut/canal (0=dump, n = canal)
7EH (01111110) : type de format
eeH (0eeeeeee) : compteur de poids fort du nombre de données
ffH (0eeeeeee) : compteur de poids faible du nombre de données
4CH (01001100) : premier octet d'en-tête ("L" en ASCII)
4DH (01001101) : deuxième octet d'en-tête ("M" en ASCII)
20H (01001100) : troisième octet d'en-tête (" " en ASCII)
20H (01001100) : quatrième octet d'en-tête (" " en ASCII)
wwH (0wwwwwww) : premier octet du type d'instrument (caractère ASCII)
xxH (0wwwwwww) : deuxième octet du type d'instrument (caractère ASCII)
yyH (0wwwwwww) : troisième octet du type d'instrument (caractère ASCII)
zzH (0wwwwwww) : quatrième octet du type d'instrument (caractère ASCII)
ggH (0ggggggg) : premier octet de format de données
hhH (0hhhhhhh) : deuxième octet de format de données
ddH (0ddddddd) : données
...
ccH (0ccccccc) : checksum
F7H (11110111) : EOX
Avec le SY55, yamaha à développé un nouveau format proche du précédent, mais encore plus complet. Un en-tête supplémentaire ainsi que des octets de type de numéro de mémoire ont été ajoutés.
Format du message de dump request série SY/TG
F0H (11110000) : statut de message exclusif
43H (01000011) : identification du constructeur (43H = Yamaha)
2nH (0010nnnn) : sous-statut/canal (2=dump request, n = canal)
7EH (01111110) : type de format
4CH (01001100) : premier octet d'en-tête ("L" en ASCII)
4DH (01001101) : deuxième octet d'en-tête ("M" en ASCII)
20H (01001100) : troisième octet d'en-tête (" " en ASCII)
20H (01001100) : quatrième octet d'en-tête (" " en ASCII)
wwH (0wwwwwww) : premier octet du type d'instrument (caractère ASCII)
xxH (0wwwwwww) : deuxième octet du type d'instrument (caractère ASCII)
yyH (0wwwwwww) : troisième octet du type d'instrument (caractère ASCII)
zzH (0wwwwwww) : quatrième octet du type d'instrument (caractère ASCII)
ggH (0ggggggg) : premier octet de format de données
hhH (0hhhhhhh) : deuxième octet de format de données
iiH (0iiiiiii) : en-tête additionnel de 14 octets (à zéro si inutilisés)
...
jjH (0jjjjjjj) : type de mémoire
kkH (0kkkkkkk) : numéro de mémoire
F7H (11110111) : EOX
Format du message de dump série SY/TG
F0H (11110000) : statut de message exclusif
43H (01000011) : identification du constructeur (43H = Yamaha)
0nH (0010nnnn) : sous-statut/canal (0=dump, n = canal)
7EH (01111110) : type de format
eeH (0eeeeeee) : compteur de poids fort du nombre de données
ffH (0eeeeeee) : compteur de poids faible du nombre de données
4CH (01001100) : premier octet d'en-tête ("L" en ASCII)
4DH (01001101) : deuxième octet d'en-tête ("M" en ASCII)
20H (01001100) : troisième octet d'en-tête (" " en ASCII)
20H (01001100) : quatrième octet d'en-tête (" " en ASCII)
wwH (0wwwwwww) : premier octet du type d'instrument (caractère ASCII)
xxH (0wwwwwww) : deuxième octet du type d'instrument (caractère ASCII)
yyH (0wwwwwww) : troisième octet du type d'instrument (caractère ASCII)
zzH (0wwwwwww) : quatrième octet du type d'instrument (caractère ASCII)
ggH (0ggggggg) : premier octet de format de données
hhH (0hhhhhhh) : deuxième octet de format de données
iiH (0iiiiiii) : en-tête additionnel de 14 octets (à zéro si inutilisés)
...
jjH (0jjjjjjj) : type de mémoire
kkH (0kkkkkkk) : numéro de mémoire
ddH (0ddddddd) : données
...
ccH (0ccccccc) : checksum
F7H (11110111) : EOX
La méthode Roland
Commune à l'ensemble de leurs produits depuis plusieurs années, les méthodes de transmission de SysEx Roland sont soumises à deux types d'échanges : le mode one way et le mode handshake. Les messages exclusifs commencent bien entendu par F0H, suivi de 41H (correspondant au numéro d'identification de la marque). L'octet suivant, ou device-ID, représente le numéro de canal MIDI (de 00H à 0F), ou le numéro d'unité (de 10H à 1FH). L'avantage du numéro d'unité est d'être indépendant de la notion de canal (au cas où plusieurs appareils identiques seraient réglés sur les mêmes canaux) et d'autoriser l'accès à des données "protégés" (inaccessibles par numéro de canal). Viennent ensuite le model-ID, indiquant le nom du produit ou de la famille de produits (série D10/D20/D110 par exemple) et le command-ID, spécifiant le type de message : 11H pour un dump request en mode one way (RQ1/Request Data 1), 41H pour son équivalent en mode handshake (RQD/Request Data), etc.
En ce qui concerne les messages de dump request, le principal intérêt du système réside dans la signification des six octets suivants, les trois premiers indiquant l'adresse mémoire des données à aller chercher, et les trois derniers leur taille. Les manuels utilisateur Roland incluent systématiquement une table des adresses mémoire de l'instrument. Les octets de checksum et d'EOX ferme la marche. En retour (message de dump), les identificateurs RQ1 et RQD sont remplacés par 12H (DT1/Data Set 1) et 42H (DAT/Data Set). Les données s'intercalent entre les octets de taille et le checksum. La supériorité du système mis au point par Roland réside donc dans l'indépendance du message vis-à-vis des données. En effet, la même structure de message est capable de vider tout ou partie de la mémoire, depuis son contenu intégral jusqu'à un paramètre individuel. Cependant, certains instruments Roland parmi les moins récent, comme c'est le cas de la famille Juno-1/2/MKS-50, bien qu'implémentant déjà les modes one way et handshake n'utilisaient pas encore ce procédé.
Message du dump request one wayF0H (11110000) : statut de message exclusif 41H (01000001) : identification du constructeur (41H = Roland) aaH (0aaaaaaa) : canal MIDI ou numéro d'unité (device-ID) bbH (0bbbbbbb) : modèle ou famille (model-ID) 11H (00010001) : code RQ1 (request one way) ddH (0ddddddd) : adresse (début) eeH (0eeeeeee) : adresse (suite) ffH (0fffffff) : adresse (fin) ggH (0ggggggg) : taille (début) hhH (0hhhhhhh) : taille (suite) iiH (0iiiiiii) : taille (fin) ccH (0ccccccc) : checksum F7H (11110111) : EOXMessage du dump one way
F0H (11110000) : statut de message exclusif 41H (01000001) : identification du constructeur (41H = Roland) aaH (0aaaaaaa) : canal MIDI ou numéro d'unité (device-ID) bbH (0bbbbbbb) : modèle ou famille (model-ID) 12H (00010001) : code DT1 (dump one way) ddH (0ddddddd) : adresse (début) eeH (0eeeeeee) : adresse (suite) ffH (0fffffff) : adresse (fin) xxH (0xxxxxxx) : données ... ccH (0ccccccc) : checksum F7H (11110111) : EOX
Qu'il s'agisse de Roland, de Yamaha ou d'autres constructeurs, les procédures de dump ont évolué empiriquement vers une sorte de standardisation au fur et à mesure des besoins. Aujourd'hui avec la norme General MIDI 2, pour les instruments répondant à cette norme, il existe un message de system exclusive universel (se référer à la documentation livrée avec l'instrument entrant dans cette catégorie).
Dans tout réseau informatique, les techniques d'interfaçage (dispositif grce auquel s'effectuent les échanges d'informations entre deux systèmes) posent le problème de l'intégrité des données. En effet, ces données sont susceptibles d'être altérées pour diverses raisons : câbles trop longs, interférences électriques, rupture physique de la connexion, etc. Fort heureusement, ce problème est en partie résolu grâce aux codes de détection et de correction d'erreurs. Le MIDI n'échappe pas à la règle : checksum, handshaking, acknowledge, rejection et autres anglicisme rencontrés dans les manuels utilisateur contribuent à la fiabilité des transmissions.
Codes détecteurs et correcteurs
L'erreur est une altération de la plus petite information numérique, c'est-à-dire du bit, lors de son passage dans l'interface. Or, le bit ne présentant que deux états (0 ou 1), son altération se matérialisera par la transformation d'un état 0 en 1, ou d'un état 1 en 0. Le système binaire n'engendre donc que deux sortes d'erreurs. C'est ainsi qu'une erreur portant sur un bit égal à 1 sera corrigée en le transformant en un bit égal à 0, et réciproquement. Une erreur localisée est ainsi en mesure d'être corrigée. Cette constatation permet de classifier les codes en deux catégories : les codes détecteurs et les codes correcteurs (détecteurs et localisateurs).
Un code détecteur d'erreur est un système ajoutant à l'information utile une information redondante répondant à une loi connue de l'émetteur comme du récepteur. Avant de transmettre des données, l'émetteur y applique un calcul (loi), dont le résultat est également transmis. A réception des données, le récepteur applique ce même calcul à ces mêmes données, pour le comparer avec le résultat du calcul effectué par l'émetteur. En cas de différence, il est alors en mesure de signaler une erreur. Ainsi, en admettant que l'émetteur transmette les données 2, 9, 4, 1 et que la loi de détection soit matérialisé par une simple addition, la tram émise aura l'allure suivante :
En supposant que la troisième données soit altérée durant le transfert (qu'elle passe par exemple de la valeur 4 à la valeur 5), le récepteur recevra la trame suivante :
En additionnant les quatre premières données (2 + 9 + 5 + 1 = 17), il s'apercevra que son résultat diffère de celui calculé par l'émetteur (16). Par conséquent, il en déduira qu'une erreur de transmission est intervenue. Cependant, un tel code de détection ne permet pas de localiser l'erreur. En effet, rien n'indique sur quelle donnée porte l'altération, ni si elle concerne les données utiles ou le résultat du calcul. Après détection d'une erreur, le récepteur a la possibilité d'afficher un message et d'interrompre la transaction, ou, s'il est programmé pour, de demander une réémission de la trame erronée.
Avec le système binaire, le bit de parité est l'un des codes les plus fréquemment utilisés. A l'intérieur d'une liaison sérielle, lors de la transmission d'un octet (8 bits), l'émetteur ajoute un bit supplémentaire de manière à obtenir un nombre pair de 0 ou de 1 (parité paire ou parité impaire). De son cÙté, le récepteur calcule la parité de l'octet reçu pour le comparer avec le résultat obtenu par l'émetteur (le neuvième bit transmis). Toutefois, ce procédé est caractérisé par l'incapacité de détecter un nombre pair d'erreurs. Dans l'exemple suivant, l'émetteur transmet un octet suivi d'un bit de parité calculé de manière à obtenir un nombre impair de bits à zéro :
En supposant qu'une double erreur de transmission affecte les bits 0 et 7 (passage de la valeur 1 à la valeur 0), le système de parité estimera qu'aucune altération ne s'est produite, puisque le nombre de bits à zéro demeure impair.
Plus évolués, les codes correcteurs d'erreurs sont capables, après détection, de localiser, donc de corriger le ou les bits altérés. Notamment utilisés en audionumérique, de tels codes consomment un grand nombre d'octets redondants de par leur aptitude à localiser l'erreur. Sans entrer dans les détails, voici un exemple de code correcteur simple qui, en plus d'un simple calcul de parité horizontal sur chaque octet, ajoute un calcul de parité verticale tous les huit octets transmis :
| Emission | Erreur de réception et localisation | |
| 11001101 1 | 11001101 1 | |
| 01010000 0 | 01010000 0 | |
| 00001111 0 | 00001111 0 | |
| 01010001 1 | 01011001 0 | |
| 11101010 1 | 11101010 1 | |
| 01000101 1 | 01000101 1 | |
| 00100010 0 | 00100010 0 | |
| 00011110 0 | 00011110 0 | |
| 01010000 | 01011000 | |
Ce calcul de parité matriciel permet par conséquent de localiser l'erreur comme étant située à l'intersection des erreurs de parité horizontale et verticale, pour la corriger immédiatement en modifiant la valeur du bit altéré.
La solution MIDI : le checksum
La norme MIDI telle qu'elle est spécifiée véhicule principalement des messages en temps réel d'une longueur inférieure à 4 octets. Il est donc impossible de mettre en oeuvre un système de détection simple, puisque le fait d'émettre des messages en temps réel en fonction du jeu musicien est incompatible avec une réémission d'un message erroné. Quant à un système de correction d'erreurs, il surchargerait inutilement le réseau MIDI par rapport à des messages courts statistiquement peu altérables. De plus, certains octets de statut (all notes off, reset all controllers, system reset) sont prévus pour pallier d' éventuelles erreurs bloquantes.
Par contre, la longueur des messages exclusifs (dumps) ne cesse de croître proportionnellement aux progrès technologiques, où la nécessité d' un système de détection d'erreur, voire de correction. Excepté pour le sample dump standard, dont le protocole d'échange est défini par la norme MIDI, toute liberté est laissée à chaque constructeur pour vérifier l'intégrité de ses données. Jusqu'à présent, le checksum (somme de contrôle) est l'unique critère de détection d'erreur utilisé. Il s'agit d'un octet qui, une fois toutes les données MIDI additionnées, doit s'y ajouter de manière que le résultat soit égal à zéro. Bien entendu, cette addition s'effectue sur 7 bits, sans prendre en compte les retenues.
Soit les cinq octets suivants à transmettre :
| 01010011 | (octet 0) |
| 01100110 | (octet 1) |
| 00000101 | (octet 2) |
| 01111100 | (octet 3) |
| 00100010 | (octet 4) |
Additionnons-les sans nous soucier de la retenue :
| 01010011 | (octet 0) | |
| + | 01100110 | (octet 1) |
| = | 10111001 | |
| = | 00111001 | (après mise à zéro de la retenue du bit 7) |
| 00111001 | (résultat) | |
| + | 00000101 | (octet 2) |
| = | 00111110 | |
| 00111110 | (résultat) | |
| + | 01111100 | (octet 3) |
| = | 10111010 | |
| = | 00111010 | (après mise à zéro de la retenue du bit 7) |
| 00111010 | (résultat) | |
| + | 00100010 | (octet 4) |
| = | 01011100 | (résultat de l'addition des cinq octets) |
Par définition, l'addition du checksum avec le résultat précédent (01011100) doit fournir un nombre dont les bits 0 à 6 sont égaux à zéro (peu importe le bit 7, puisque celui d'une donnée MIDI est invariablement positionné à zéro). Cependant, pour faciliter les calculs (le résultat d'une addition n'étant généralement pas nul), nous effectuerons les opérations suivantes en positionnant le bit 7 à 1 :
| 01011100 | (résultat de l'addition des cinq octets) | |
| + | ccccccc | (checksum) |
| = | 10000000 |
C'est-à-dire :
| 10000000 | (résultat de l'addition des cinq octets) | |
| - | 01011100 | |
| = | ccccccc | (checksum) |
| D'où | ccccccc = 0100100 |
Afin d'éviter cette soustraction binaire, un moyen plus simple d'obtenir le checksum à partir d'une somme sur 7 bits de n octets consiste à en calculer le complément à 2 :
| somme des données | 01011100 | |
| complément à 1 (inversion des bits) | 10100011 | |
| complément à 2 (on ajoute 1) | + | 00000001 |
| résultat | = | 10100100 |
| bit 7 forcé à zéro | 00100100 |
En reprenant la première méthode (celle de la soustraction), mais cette fois-ci en décimal et en hexadécimal, le calcul du checksum s'effectuera en étant la somme des données à 128 (80H) :
| 128 | 80H | 10000000 | |||
| - somme de données | 92 | 5CH | 01011100 | ||
| = checksum | 36 | 24H | 00100100 |
Pour terminer, voici un dernier exemple de calcul de checksum, à partir des nombres 40, 116, 59 et 3 :
Commençons par les additionner :
Le bit 7 du résultat est forcé à zéro, soit en convertissant 218 en binaire (11011010) pour le reconvertir en forcé le bit 7 à zéro, ce qui donne 90 (01011010), soit plus simplement en calculant le reste de la division de 218 par 128 (218 : 128 = 1, reste 90). Pour obtenir le checksum, il suffit de calculer la différence entre 128 et 90. Celui-ci est donc égal à 38.
Le checksum est calculé par l'émetteur, puis recalculé pour vérification par le récepteur, qui est alors en mesure de détecter une erreur en cas de différence. Si récepteur est incapable de formuler une demande de réémission du message erroné, il se contentera d'afficher un message d'erreur (checksum error), et d'ignorer éventuellement les données reçues. Dans le cas contraire et sur la demande du récepteur, l'émetteur retransmettra le paquet de données erroné, ce procédé se poursuivant jusqu'à obtention d'une transmission correcte. Cette requête de réémission fait partie d'un protocole de communication généralement appelé handshaking (littéralement "poignée de main"), employé par un certain nombre interfaces.
Les logiciels de gestion des SysEx
Après avoir étudié la structure et le contenu des mémoires des instruments MIDI ainsi que les protocoles de communication utilisés pour transférer ces données (dump), et avant d'aborder des exemples pratiques de programmation, passons brièvement en revue les principales familles d'applications logicielles exploitant les messages exclusifs.
Les utilitaires de dump
Les logiciels de dump sont des utilitaires d'archivage destinés à stocker tout ou partie du contenu de la mémoire des instruments MIDI sur un support de type disquette, disque dur... afin de le leur renvoyer ultérieurement. Ils permettent ainsi de disposer à peu de frais d'une importante banque de données (sons, etc.). En pratique, tout logiciel de dump intègre au minimum une fonction de réception et une fonction d'émission :
Un dialogue entre l'ordinateur et l'instrument ne peut s'instaurer qu'à condition que ces deux unités soient raccordées en mode handshake : MIDI-Out de l'ordinateur vers MIDI-In de l'instrument pour l'envoi du dump request (s'il est implémenté), et réciproquement pour la réception du dump.
Les différents logiciels de dump
Sur le plan des instruments MIDI pris en charge, nous distinguerons trois catégories de logiciels de dump : les logiciels dédiés à un instrument spécifique, les logiciels universels et les logiciels universels programmables.
Il existe de nombreuses solutions logicielles pour les plate-formes PC-Windows et Macintosh-MacOS. Chaque logiciel a ses propres spécificités. Les expliquer nécessiterait de doubler la longueur de cet exposé qui n'a pour but que d'introduire la notion des "System Exclusive". Pour en savoir plus, je vous conseille de vous reporter vers la littérature "papier". Je vous propose aussi d'aller voir sur les sites des concepteurs ou distributeurs de ces programmes pour vous faire une (petite) idée du produit.
