-
-
Dagal Mon 05 Mar 2012 22:09Et bien, je pensais que ce serait plus compliqué que ça mais, c'est en fait très simple de récupérer ces données là et les afficher comme le fait hexdump.
J'ai trouvé comment ouvrir un séquenceur ALSA, je vais maintenant lui donner un nom et tenter de lui faire envoyer un message midi de test, puis synchroniser avec la réception des données, ensuite, peut être lire un fichier de config pour l'assignation perso des différentes fonctions.
La suite au prochain numéro.
-
Dagal Tue 06 Mar 2012 22:52Et voici donc où j'en suis!!!
J'ai converti tous les boutons en 00 pour off et 127 pour on.
Tous les potars sont converti en linéaire de 000 à 127
Quand l'application est lancée en mode console, elle affiche le nom de ce qui est manipulé ainsi que la valeur en cours.
Tous les boutons et potars sont modifiés en même temps, ce qui garantit un contrôle total pour l'utilisateur.
Je n'ai pas encore très bien assimilé comment envoyer un message de contrôle MIDI, mais c'est pour bientôt.
Donc, depuis que ce driver est installé, il y a deux nouveaux périphérique dans /dev:
- un contrôle (vide)
- un bulk (plein 😀 )
Je vais donc tenter de me rapprocher un peu plus de ce fameux bulk. (/dev/hdjbulk0)
En utilisant hexdump sur ce fichier périphérique, on se rend très vite compte que les données sont groupées par 20 octets à la fois. On voit aussi que la réaction est directe quand on touche un des contrôles, donc latence ultra basse. Chaque bouton est représenté par un bit et chaque potar par un octet.
Le bouton 'on air' n'est pas représenté comme dans le driver pour windows. Il sert juste à sa fonction de base, qui, elle, a l'air correcte. %J'analyserai cela plus tard.
Pour en revenir à nos moutons, je vais donc tenter d'écrire une espèce de passerelle entre le fichier bulk et une sortie midi de type alsa, ce qui devrait déjà combler pas mal de gens, qui, comme moi, aimeraient voir leur matériel fonctionner.
Il restera donc a gérer les différentes "lumières" de la console.
A bientôt...