Se connecter
Se connecter

ou
Créer un compte

ou

Les SysEx du D10

Par thomasDX7 le 29/11/2013 - (Expert)
Agrandir
Ajouter ce produit à
  • Mon ancien matos
  • Mon matos actuel
  • Mon futur matos
Roland D-10
Photos
1/213
Roland D-10

Clavier synthétiseur numérique de la marque Roland

Voici un petit tuto pour ceux qui veulent utiliser les SysEx pour éditer les paramètres du D10 (mais aussi du D20 et du D110):

Je m'appuie sur le manuel du synthé (en anglais ou français c'est la même chose, ce n'est pas traduit).

Et un petit lien vers des infos utiles sur les SysEx.


1. Le message SysEx :

 

Tout à la fin, après le chapitre '7. Annexes', on trouve un document intitulé 'Roland Exclusive Messages' qui nous détaille les différents types de messages et leur utilisation.
On y lit que pour faire ce qui nous intéresse (modifier des paramètres de son), nous devons envoyer au D10 des messages SysEx de type DT1, et on trouve le tableau descriptif du format du message DT1.
J'ajoute au passage que pour le D10 Device ID=10H et Model ID=16H.
Le message va donc s'écrire sous la forme : F0 41 10 16 12 aa bb cc dd xx F7, avec aa bb cc qui est une adresse, dd qui est une valeur, et xx qui est un checksum.

 


2. Les adresses de paramètres :

 

Dans le manuel, après la section 'Roland Exclusive Messages', se trouve la section 'Implémentation de l'interface MIDI' ('MIDI implementation' dans la version en anglais).

 

Rendez-vous directement ici :

 

"6. PARAMETER ADDRESS MAP
Addresses are shown in 7-bit hexadecimal.

Address            MSB                                  LSB
Binary              0aaa aaaa      0bbb bbbb     0ccc cccc
7-bit hex.         AA                BB                 CC

The actual address of parameter in a block is the sum of the start address of each block and one or more offset address.
Parameters marked by *6_1 have two offset addresses : one in the table in *6_1 and the other one in the 'Common parameter' table or in the 'Partial parameter' table."

 


J'ai volontairement reproduit le paragraphe car il est d'une importance capitale, bien qu'il passe quasiment inaperçu!
En gros il nous explique que les adresses sont constituées d'une 'start address' et d'une ou deux 'offset address' qu'il faut additionner (pour obtenir l'adresse utilisable dans le message SysEx, la fameuse aaH bbH ccH…).
Il nous dit aussi que les adresses s'écrivent en '7-bit hexadécimal' : 0xxx xxxx.

Mais… qu'est ce que ça veut dire? Ça veut dire que les octets d'adresse (aaH, bbH et ccH) ont en fait un bit qui ne sert pas à transmettre des données, et dont la valeur est fixe et égale à 0.

Oui, très bien, mais qu'est ce que ça change?
Ça change tout!! Parce que quand on va additionner les deux ou trois adresses qu'on trouve dans les différents tableaux pour obtenir l'adresse utilisable dans un message SysEx, il va falloir tenir compte de ces foutus bits à 0 pour ne pas se retrouver avec des adresses qui ne fonctionnent pas!

 


3. Exemple :

 

Je veux donner au paramètre LOWER TONE / PARTIAL 1 / TVF CUTOFF FREQ la valeur 100.

 

Page suivante du manuel, on trouve dans les tableaux les infos suivantes :

 

"Start Address                Description
04 01 76                       Tone Temporary Area (Part 2/ Lower Tone)    *6_1"

 

Ce qui nous renvoie au tableau *6_1 Tone Temporary Area , où l'on trouve :

"Offset address               Description
00 00 0E                       Partial parameter (for partial 1)                    *6_2"

 

Ce qui nous renvoie au tableau *6_2 Partial parameter, où l'on trouve :

"Offset address               Description
00 17                           0aaa aaaa         TVF CUTOFF FREQ         0-100"

 

 

4. Calcul de l'adresse du paramètre :

 

On a donc trois adresses hexadécimales à additionner :
La start adress : 04 00 00
La première offset address : 00 00 0E
La deuxième offset address : 00 17
Mais attention! Il faut absolument tenir compte du fait que tout est codé en '7 bits utiles' et que le bit le plus à gauche ne peut pas prendre d'autre valeur que 0.


On commence donc par convertir en binaire les adresses hexadécimales :

04 01 76     =    0000 0100 0000 0001 0111 0110
00 00 0E     =    0000 0000 0000 0000 0000 1110
(00) 00 17   =    0000 0000 0000 0000 0001 0111


Puis on additionne :
(Additionner du binaire, il faut savoir que 1+1=10, 1+1+1 =11, etc…)

   0000 0100 0000 0001 0111 0110
+ 0000 0000 0000 0000 0000 1110
+ 0000 0000 0000 0000 0001 0111

 

Comme une addition normale on commence par la droite :
Bit 0 : 0+0+1=1
Bit 1 : 1+1+1=11, j'écris 1 et je retiens 1
Bit 2 : 1+1+1(+1, la retenue)=100, j'écris 0 et je retiens 10
Bit 3 : 0+1+0(+10)=11 soit 1 avec retenue 1
Bit 4 : 1+0+1(+1)=11 soit 1 avec retenue 1
Bit 5 : 1+0+0(+1)=10 soit 0 avec retenue 1
Bit 6 : 1+0+0(+1)=10 soit 0 avec retenue 1
Bit 7 : 0+0+0(+1)=1

 

Et là on se rend compte que ce n'est pas possible : le bit 7 doit être à 0. Sinon le synthé ne va pas comprendre le SysEx.
Il faut donc mettre le bit 7 à 0 quelle que soit sa valeur, et si besoin, décaler la retenue dans l'octet suivant.
Si l'on avait simplement pris additionné les adresses en hexadécimal on n'aurait pas tenu compte de ce bit de statut et la valeur obtenue serait inutilisable: 76H+0EH+17H = 9BH, alors que le résultat de notre addition donne en binaire 00011011, soit 1BH.

 

On continue à additionner nos bits et le Bit 0 du deuxième octet accueille la retenue qu'on a décalée d'un rang :
1+0+0(+1)=0
0+0+0(+1)=1
etc…

04 01 76 + 00 00 0E + (00) 00 17 ne nous donne pas l'adresse 04 01 9B comme on aurait pu le penser, mais bien 04 02 1B.

 

 

5. Ecriture du SysEx :

 

On voulait donner à la CUTOFF FREQ du PARTIAL 1 du LOWER TONE la valeur max : 100, soit 64 en hexadécimal.
Voici donc le sysex presque définitif, avec adresse et valeur :
F0 41 10 16 12 04 02 1B 64 xx F7

Il ne reste qu'à calculer le cheksum. J'utilise le calculateur de cheksum et j'obtiens mon SysEx définitif :

F0 41 10 16 12 04 01 9B 64 7B F7

Y'a plus qu'à balancer ce SysEx au D10 pour voir que la valeur du cutoff concernée change bien à la réception et voilà, le tour est joué!

 

Perso j'ai utilisé ça pour paramétrer une surface de contrôle BCR 2000 pour avoir plein de potards à tourner plutôt qu'un pauvre slide et des tas de menus.
Il suffit alors de paramétrer la BCR pour qu'elle mette une valeur variable à la place de l'octet dd et qu'elle calcule automatiquement le checksum xx… et roule!

 


Merci de m'avoir lu et bon courage!

 

 

P.S. : vous pouvez télécharger ici la liste complète des adresses SysEx du D10, les paramètres pré-enregistrés du D10 pour l'éditeur BC-Manager, ainsi que le preset que je me suis bricolé pour pouvoir éditer les Tones du D10 avec ma BCR2000 (avec les templates qui correspondent en PDF, à imprimer)

 

  • d20p 77 posts au compteur
    d20p
    Posteur·euse AFfranchi·e
    Posté le 24/01/2024 à 14:35:40
    Travaillant sur un outil pour manipuler les Sysex du D10/110/20 j'ai été confronté à ce souci de données sur 7 bits, et je me suis fait une paire de fonctions de conversion.
    Je vous les partage, si ca peut être utile à quelqu'un...
    C'est du java, mais ca peut facilement être converti dans d'autres langages, car elle utilisent juste des décalage de bits et des operations logiques (AND et OR) sur les bits.

    Je suis parti du principe qu'il était plus simple de travailler avec données sur 8 bits, puis de faire la conversion en 7 bits à la fin.
    Ainsi, pour reprendre l'exemple du tuto:
    L'adresse de départ est 04 01 76 (adresse en 7 bits utiles) on va d'abord la convertir en version 8 bits utile.
    Ainsi 04 01 76 (en hexa) qui s'écrit en binaire 0000_0100 0000_0001 0111_0110 (j'ai mis des _ pour montrer les bits d'un même octet et le 0 inutile en gras, ça facilite la lecture). Et ceci devient 000_0100 000_0001 111_0110 une fois le 8e bit (inutilisé) retiré.
    Si on le regroupe ces bits en paquets de 8 bits, ca nous donne les octets suivants: 0_0001 0000_0000 1111_0110 (il manque trois zéros au début, qui correspondent au 3 bits inutilisés retirés
    On obtient donc comme adresse de départ "réelle" 01 00 F6 (en hexa) soit 65782 en décimal

    Ensuite, on ajoute à cette valeur les offsets d'adresse (0E et 17 dans l'exemple du tuto, soit 14 et 23 en décimal)
    On a donc 65782 + 14 +23 = 65819 qui est l'adresse de notre paramètre.
    Cette adresse (65819) en binaire est: 0001 0000_0001 0001_1011
    Si on applique la conversion en 7 bits utile, en intercalant des 0 (en gras) sur le 8e bit de chaque octet on obtient:
    00_0100 0000_0010 0001_1011, soit 04 02 1B, ce qui est bien le résultat de l'addition trouvé dans le tuto.

    J'ai donc écrit 2 fonctions, une qui converti 3 octets n'ayant que 7 bits utiles en la version décimale correcte: (converti 04 01 76 en 65782)
     /**
         * Converti une adresse sur 3 octets avec 7 bits utiles en une adresse 8 bits.
         * @param byte1
         * @param byte2
         * @param byte3
         * @return
         */
        int convert7Bit3BytesAddressToInt(byte byte1, byte byte2, byte byte3) {
            return   byte3 & 0xFF |
                    (byte2 & 0xFF) << 7 |
                    (byte1 & 0xFF) << 14;
        }


    et une autre, qui converti une addresse sur 8 bits, en un tableau de 3 octets n'ayant que 7 bits utiles (converti 65819 en 04 02 1B)
    La fonction est volontairement limitée à 3 octets (pas besoin de plus pour le D10) et lève une exception si on tente de convertir une adresse plus grande
     /**
         * Converti une adresse en 8 bits en sa representation sur 3 octets avec  7 bits significatifs
         *
         * @param address l'adresse a convertir
         * @return le resultat sur forme d'un tableau de 3 octets
         * @throws Exception si l'adresse est trop grande pour etre convertie sur 3 octets
         */
        public byte[] convertAddressTo7Bit3Bytes(int address) throws Exception {
            if (address>8355711) {
                throw new Exception("Adresse " + address + " trop grande pour tenir sur 3 octets");
            }
            // Decale de 0, 7 ou 14 bits et ne conserve que les 7 derniers
            int byte1 =  address >> 14 & 0x7F;
            int byte2 = address >> 7 & 0x7F;
            int byte3 = address & 0x7F;

            return new byte[] {(byte)byte1, (byte)byte2, (byte)byte3};
        }


    En java les byte sont signés, donc vont de -128 à +127, mais comme on travaille sur 7 bits, les valeurs possible ne sont que de 0 à 127, du coup on est pas embeté par le fait que sa soit signé.
  • Jlkas 78 posts au compteur
    Jlkas
    Posteur·euse AFfranchi·e
    Posté le 24/01/2024 à 14:56:09
    Bravo ! Belles compétences !
  • d20p 77 posts au compteur
    d20p
    Posteur·euse AFfranchi·e
    Posté le 24/01/2024 à 15:35:37
    Citation de Jlkas :
    Bravo ! Belles compétences !

    J'ai pas mal galéré pour convertir d'un mode à l'autre
    J'ai commencé par convertir les adresses en une chaine de caractères (avec des 0 et des 1), puis à la découper en bloc de 7 caractères, reconvertis ensuite en nombres. Ca marchait bien, mais c'était un peu usine à gaz
    Je suis finalement arrivé a cette solution simple par décalage de bits
  • thomasDX7 161 posts au compteur
    thomasDX7
    Posteur·euse AFfiné·e
    Posté le 24/01/2024 à 15:40:03
    Super! Avoir un outil comme ça m'aurait simplifié la vie!
    Je crois - si je me souviens bien - que j'avais utilisé la calculatrice de MacOSX, qui me permettait la conversion.
    En tout cas quand j'ai fait mon éditeur de D10 pour BCR2000 j'ai bien galéré avec tout ça !
    J'ai voulu rempiler avec le DX7 mais ça m'a fatigué... :mdr:

Vous souhaitez réagir à cet tutoriel ?

Se connecter
Devenir membre