Ajout d'écrans sur une BCF2000

Citation de chimimic

Tu en est sûr, ou c'est le comportement de ton soft qui t'y fait penser ?

 J'utilise Ardour sous linux, patché dans Jack. Ce qui est bien pratique pour gérer toutes les connexions MIDI et audio.

Ma BCF est patchée sur l'entrée Mackie Control IN, mon Arduino sur la sortie Mackie Control OUT, et tout ce que je reçois, c'est du CC, PC et cie… (dans la librairie MIDI d'Arduino, j'ai un getMessageType qui me renvoit cette info, j'attends un 0xF0 comme début de trame SysEx.)

Quand je lance la lecture dans mon DAW, le RX de mon Arduino me signale que je reçois bien des infos en masse, et que d'après la lib, c'est pas du SysEx. 

L'émulation Mackie Control et le protocole MCP sont fait du coté DAW non?  J'essaierai éventuellement avec un autre DAW sous Windows pour voir si c'est le cas aussi. J'essaie de me remettre dedans prochainement 

Citation de : chimimic

Levé de doute avec capture oscillo sur lignes MIDI, et analyse des trames réellement échangées

 Certes, mais dans mon cas l'arduino communique avec l'ordi en MIDI via l'usb HID, donc la communication "série" de l'arduino est directement géré dans le firmware, mais je peux toujours essayer de sortir de la carte son en midi et analyser les trames à l'oscillo (qui d'ailleurs est à la cave dans un carton, car pas très Wife compliant dans le bureau  ) 

Edit: avec un moniteur logiciel, ça fonctionne bien, le DAW m'envoie bien des SysEx  

C'est connecté ainsi : 

… et les trames envoyées quand je fais play depuis ma BCF :

Donc c'est bien dans mon code qu'il y a un soucis…

@moustick, c'est exactement ça que je compte faire, mais sans la partie controlleur, mes compétences en usinage/méchanique sont bien limitées, donc je vais me contenter d'un affichage avec 2-3 boutons de contrôle.  Les écrans sont les mêmes, bien qu'un peu trop "chargés" d'informations à mon gout. Le problème, avec ce genre de projets, c'est que les gens sont souvent tellement fier d'avoir fait leur truc qu'ils en oublient de partager comment ça fonctionne, et quelles sont les étapes pour en arriver à un projet fonctionnel. 

@CéGlucose, interressant! merci, je vais checker ça aussi

Sinon, j'ai bien réussi à récupérer les mêmes SysEx que sur mon moniteur MIDI logiciel,  sur mon écran Oled!   C'était un problème de code mal formé, avec des mauvaises déclarations de variables. Je suis un peu rouillé en C depuis que je fais beaucoup plus de web et de python.

Maintenant, faut que je décode, convertisse ça en human readable!

Après lecture du magnifique : LogicControl_EN.pdf, je comprends mieux mes trames SysEx:

L'écran LCD sur une mackie control possède 56 caractères, ça tombe bien, divisé par 8 (nombre de tranches/écrans) ça fait 7 caractères par écran.

Chaque position de caractère est identifié par une valeur Hexa:

• allant de 0x00 à 0x37 (soit 56 valeurs) pour la première ligne,
• et de 0x38 à 0x6F pour la seconde ligne.

Dans les SysEx reçus (dont le screenshot se trouve quelques posts plus haut), on retrouve bien ce format:

5 chars : F0 00 00 66 00  qui correspond à l'identifiant du device,

12 : qui indique le début du message LCD

Puis : 38 4C 35 31 52 34 39 20 8    

Donc: à partir de l'offset 38 (2e ligne, 1er caractère) on doit donc afficher : 

Si vous suivez jusque là, on à donc un affichage de PAN sur la 2e ligne, 1er afficheur : L51 R49  (j'ai du me rater dans le DAW pour faire un PAN pareil  )

 Il y a 8 messages SysEx qui se suivent avec le même schéma, soit mes 8 configurations de PAN pour chacune de mes tranches sur la 2e ligne!

@metalfx : J'ai utilisé HIDuino pour flasher le mien, ça semble être sensiblement la même chose! 

@chimimic: Merci de ton soutien ! Ton site est une mine d'or pour tout bricoleur!

De retour avec une belle progression sur le projet,

J'arrive à présent à afficher les infos que le DAW m'envoie sur la sortie MIDI mackie control! 

Je change la valeur du PAN via les potards de la BCF, et mon écran réagit bien et m'affiche un truc du genre: 

Après quelques temps, l'écran retourne à sa valeur initiale:

Ça réagit même sur les faders quand je les bouge depuis la bcf, ou directement dans le DAW:

Il revient toujours sur PAN visiblement. J'ai jamais eu de MCU en main, donc je suppose que c'est un comportement voulu.

J'ai aussi réussi à afficher le nom de la piste sur l'écran, mais le problème, c'est que celui-ci ne s'affiche que lorsque je le modifie dans le DAW… 

En gros l'écran ne réagit pas tant que je ne modifie pas de paramètres. Il y a peut-être une fonction pour demander au DAW de me fournir des valeurs, piste à creuser.

J'ai un autre soucis, quand je modifie rapidement les paramètres, l'écran affiche parfois des caractères aléatoires un peu n'importe ou. Y'a de la friture sur la ligne… il faut que j'arrive à stabiliser le truc, c'est peut-être dû au grand nombre de messages qui passent par la liaison MIDI-USB 

Reste à faire: 

• La gestion du nom de la piste,
• La gestion eventuelle d'un petit bargraph/vumetre 
• La gestion du TimeCode sur un écran à part pour connaitre la position du curseur dans le projet,
• Des boutons pour switcher l'affichage,
• … plein d'autre trucs!

J'ai mis à jour le code sur Github si ça interesse quelqu'un. 

Je crois que je vais lancer une commande d'afficheurs Oled supplémentaires! 

Je tacherais de faire une petite vidéo pour montrer le projet en fonctionnement!

Après réflexion, je vais me heurter à un souci, l'adressage des écrans OLED… mon écran actuel cause en I2C, jusque là, pas de soucis, 4 câbles, c'est un BUS. Par contre, les écrans I2C à base de SSD136 n'offrent que la possibilité de 2 adresses différentes (via un jumper). Là où je veux en mettre un minimum de 8, ça va poser problème…

Je regarde donc du coté des écrans SPI, qui semblent être plus rapides (et donc plus fluide?) Mais qui nécessitent plus de branchements. Ils sont un peu plus cher aussi.

J'aurai donc besoin de 4 I/O que je peux chainer entre les différents écrans:

• DATA to digital 9
• CLK to digital 10
• D/C to digital 11
• RST to digital 13

mais chaque écran nécessite 1 I/O supplémentaire pour être "selectionné" ce qui me laisse:

• CS to digital 2 3 4 5 6 7 8 12

Je ne sais pas si je peux utiliser 0 et 1 car je pense qu'elles sont réservées pour la communication Série/MIDI 

Ça me fait un total de 8 écrans, tout pile. Je pense cependant balancer le tout derrière un multiplexeur pour n'utiliser qu'une seul I/O sur l'arduino, pour laisser de la place à d'éventuelles améliorations. 

Ça complexifie un peu le montage par contre... mais ça me semble nécessaire. 

@metalfx : Je connais Notes and Volts, c'est une véritable mine d'informations! C'est grâce à lui que j'ai commencé mes premiers montages MIDI (un switcher de canaux pour mon ampli/préampli en rack)

Le "problème", c'est qu'il se concentre sur la partie controlleur, et un peu moins sur le retour d'informations. Je peux toujours essayer d'entrer en contact avec lui pour voir. 

En attendant de pouvoir me prendre des nouveaux écrans en SPI et quelques MUX (je dois en avoir quelques un qui trainent dans mes tiroirs),  j'ai avancé sur la partie Metering envoyé par le MCP. Ça m'a permis de découvrir un point important, le protocole n'envoie pas que du SysEx, mais aussi des messages MIDI plus «standards».

Les messages de Metering pour chaque canal sont de type 0xD0 (Channel pressure) et sont formés ainsi: 

D0 ,  XY

XY étant un byte qui permet de définir à la fois le canal et la valeur du vu-metre

• X : numéro du canal, allant de 0 à 7 
• Y : valeur du vu mètre, allant de 0 à C (0 étant 0% et C étant 100%) 
  • si ce Y est égal à E, alors on set l'overload (typiquement une led avec un clip)
  • si ce Y est égal à F, alors on efface l'overload (on éteind la led de clipping)

Donc à chaque fois que je rencontre un 0xD0, je regarde la valeur qui suit, je la "découpe" en 2 à l'aide d'un masque 

byte chan = data & 0xf0;

byte level = data & 0x0f; 

… et je prend en compte l'overload s'il y a.

A partir de là, je dessine une ligne en fonction de la valeur, (en prennant en compte la largeur totale de l'écran: 128px dans mon cas pour 100%)

Je dois encore gérer le decay de la valeur, en gros, quand je stoppe la lecture dans le DAW, le vu-metre est sensé (d'après la doc) retomber d'une unité toute les 300ms, soit 1.8s pour retomber depuis le 100%.

Ça fonctionne plutôt bien, et c'est réactif! J'affiche ça sur la 1ère ligne du LCD pour le moment (vu que j'ai toujours pas réussi à y afficher le nom de la piste), mais un petit vu-metre par cannal pourrait vraiment être classe visuellement 

Citation de metalfx

 Encore bravo pour ton travail... tes explications sont limpides et je me régale.

FL Studio n'a pas de mode learn ou de truc similaire? Je ne me suis pas penché sur le mode "Plug-in Edit view" de la mackie, car non supporté sur Ardour pour le moment. Mais je pense que ça doit être faisable via le protocole Mackie Control non? (si FL le supporte)

Pour tes histoires de raccourcis, on voit souvent des gens qui désossent des claviers PC pour en faire des controleurs, ça serais pas plus facile? Surtout que des faders motorisés, ça se trouve dans les 15-20€ sur le net et c'est parfaitement géré avec les Arduino (ici par exemple). Ça reviendra moins cher que d'acheter une QCon 

Concernant les vu-mètres, oui c'est bien du peak, c'est simplement le petit effet smooth qui fait que les valeurs retombent à cette vitesse. Dans mon DAW, quand tu stoppe la lecture, il y a une barre qui reste au niveau du peak et ça retombe lentement jusqu'a 0, mais la valeur du peak est gardée en valeur décimale.