Je fais une interface de séquenceur de batterie pour la musique électronique .
Il utilise un méga arduino comme microprocesseur et actuellement il s'interface avec un programme de traitement que j'ai écrit pour la communication série. De là, les messages OSC sont envoyés à un programme Max / MSP que mon partenaire collaborateur a écrit pour créer un flux de données midi.
Donc:
Mon interface physique -> Arduino Mega -> E / S série -> Traitement -> OSC -> Max / MSP -> Midi (-> application musicale)
J'ai choisi ce chemin en partie parce qu'il n'était pas assez intelligent pour supprimer encore l'une des étapes, mais aussi pour permettre de mettre à jour l'interface physique comme nous le souhaitons, de pouvoir rendre l'interface physique polyvalente (plusieurs modes pour le faders, boutons et boutons de sélection de voix), et être en mesure d'assurer le timing critique de la mission et la modification du rythme (aka "swing").
Mes messages série sont configurés comme ceci:
PL,1; // transport control: play
PL,0; // transport control: stop
SW,30; // swing value 30
TM,130; // tempo value 130
SD,1,8,04,0; // Step sequencer data, pattern 1, voice 8 (of 8), step 04 (of 16), off
MU,8,1; // Mute, voice 8 (of 8), on
SO,4,0; // Solo, voice 4 (of 8), off
VL,3,127; // Velocity, voice 3 (of 8), value 127
CC,1,127; // Midi CC, controller 1, value 127
NN,1,36; // Note number, voice 1 (of 8), value 36 (usually a kick drum)
Ainsi, vous pouvez voir qu'en fonction du nombre de virgules par point-virgule, je peux déterminer comment analyser les données série de l'arduino dans le programme de traitement. Depuis Processing, ces types de messages sont transformés en OSC comme ceci:
/beatseqr/play 1
/beatseqr/play 0
/beatseqr/swing 30
/beatseqr/tempo 130
/beatseqr/matrix/1/8/04 0
/beatseqr/mute/8 1
/beatseqr/solo/4 0
/beatseqr/velocity/3 127
/beatseqr/midicc/1 127
/beatseqr/midinn/1 36
Et tout fonctionne bien, mais cela semble inefficace. Ai-je vraiment besoin de l'application de traitement au milieu?
Maintenant, j'avais essayé de couper le traitement et les parties OSC de l'équation, mais je manque de connaissances en matière de conception de protocole de données série.
Je sais qu'il y a un udpreceiveobjet dans Max. Et ça marche ok je suppose? Peut-être que je l'utilise mal.
À un moment donné, j'avais changé tout mon code arduino pour ne pas envoyer de nouvelles lignes à la fin de chaque message série, car cela ne signifiait rien de spécial pour l' udpreceiveobjet de Max . En fait, si je me souviens bien, il n'accepterait que le premier message jusqu'à la première nouvelle ligne et arrêterait alors le traitement des données. Donc, pour contourner cela, j'ai supprimé tous les caractères de nouvelle ligne, puis ils se répandaient en max / msp en continu.
Ensuite, le problème suivant avec cette méthode est que l' udpreceiveobjet n'accepte qu'un seul caractère à la fois. J'essayais donc d'utiliser un jsobjet javascript pour concaténer les caractères entrants, puis les analyser sur les points-virgules et les virgules. Le problème que j'ai rencontré là-bas était qu'il était imprévisible et instable. Les caractères disparaîtraient et le message ne serait pas traitable. Donc, je me demande vraiment si je devrais changer mon protocole de données série pour quelque chose de plus robuste? Ou si je me trompe complètement?
Dois-je simplement tout supprimer et recommencer à zéro en utilisant un firmware firmata? J'ai vu quelques tutoriels pour utiliser les firmata avec Max / MSP , et je suppose que je pourrais jeter un nouveau regard sur ce que fait le code sur la boîte et s'il doit le faire. La firmata peut-elle accepter des données de chaîne sur une broche à envoyer à l'écran LCD série intégré? si je peux contrôler l'écran LCD à partir de max / msp, cela pourrait fonctionner correctement.
Vous avez des conseils?
OMGWTFbouton, mais très bien pensé et question détaillée aussi!