Design des seriellen Kommunikationsprotokolls von Arduino

Ich mache ein Drum-Sequencer-Interface für elektronische Musik .

Es verwendet einen Arduino Mega als Mikroprozessor und ist derzeit mit einem Verarbeitungsprogramm verbunden, das ich für die serielle Kommunikation geschrieben habe. Von dort werden OSC-Meldungen an ein Max/MSP-Programm gesendet, das mein Kooperationspartner geschrieben hat, um einen Midi-Datenstrom zu erstellen.

So:

Meine physische Schnittstelle -> Arduino Mega -> serielle E/A -> Verarbeitung -> OSC -> Max/MSP -> Midi ( -> Musik-App)

Ich habe diesen Weg teilweise gewählt, weil ich noch nicht schlau genug war, einen der Schritte zu entfernen, aber auch, um die physische Schnittstelle nach unseren Wünschen aktualisieren zu können, um die physische Schnittstelle vielseitig zu gestalten (mehrere Modi für die Fader, Regler und Tasten zur Sprachauswahl) und in der Lage sein, missionskritisches Timing und Rhythmusmodifikation (auch bekannt als "Swing") sicherzustellen.

Meine Seriennachrichten sind wie folgt aufgebaut:

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)

Sie können also sehen, dass ich anhand der Anzahl der Kommas pro Semikolon bestimmen kann, wie die seriellen Daten vom Arduino im Verarbeitungsprogramm analysiert werden. Von der Verarbeitung werden diese Arten von Nachrichten wie folgt in OSC umgewandelt:

/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

Und es funktioniert alles gut, aber es fühlt sich ineffizient an. Brauche ich wirklich die Verarbeitungs-App in der Mitte?

Jetzt hatte ich versucht, Processing und die OSC-Teile aus der Gleichung herauszuschneiden, aber mir fehlen einige Kenntnisse in Bezug auf das Design serieller Datenprotokolle.

Mir ist bewusst, dass sich udpreceivein Max ein Objekt befindet. Und das funktioniert ok denke ich? Vielleicht benutze ich es falsch.

udpreceiveIrgendwann hatte ich meinen gesamten Arduino-Code so umgestellt, dass am Ende jeder seriellen Nachricht keine Zeilenumbrüche gesendet wurden, da dies für Max ' Objekt nichts Besonderes bedeutete . Wenn ich mich richtig erinnere, würde es tatsächlich nur die erste Nachricht bis zum ersten Zeilenumbruch akzeptieren und dann die Verarbeitung von Daten einstellen. Um das zu umgehen, habe ich alle Newline-Zeichen entfernt, und dann spuckte es kontinuierlich in max/msp aus.

Dann besteht das nächste Problem bei dieser Methode darin, dass das udpreceiveObjekt jeweils nur ein Zeichen akzeptiert. Also habe ich versucht, ein jsJavascript-Objekt zu verwenden, um die eingehenden Zeichen zu verketten und sie dann anhand der Semikolons und Kommas zu analysieren. Das Problem, auf das ich dort stieß, war, dass es unvorhersehbar und instabil war. Zeichen würden ausfallen und die Nachricht wäre nicht verarbeitbar. Ich frage mich also wirklich, ob ich mein serielles Datenprotokoll auf etwas Robusteres ändern sollte? Oder wenn ich es nur komplett falsch mache?

Soll ich einfach alles verschrotten und mit einer Firmata-Firmware von vorne anfangen? Ich habe einige Tutorials zur Verwendung der Firmata mit Max/MSP gesehen , und ich denke, ich könnte einen neuen Blick darauf werfen, was der Code auf der Box tut und ob er dies überhaupt tun muss. Kann die Firmata Zeichenfolgendaten auf einem Pin akzeptieren, um sie an das integrierte serielle LCD zu senden? Wenn ich das LCD von max/msp aus steuern kann, könnte das funktionieren.

Haben Sie einen Rat?