Ich mache eine Drum-Sequenzer-Schnittstelle 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-Nachrichten an ein Max / MSP-Programm gesendet, das mein Kooperationspartner geschrieben hat, um einen MIDI-Datenstrom zu erstellen.
Damit:
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 klug genug war, um einen der Schritte zu entfernen, aber auch, um die physische Schnittstelle so zu aktualisieren, wie wir es wollen, und um die physische Schnittstelle vielseitig zu machen (mehrere Modi für die Fader, Regler und Sprachauswahltasten) und in der Lage sein, geschäftskritisches Timing und Rhythmusmodifikation (auch bekannt als "Swing") sicherzustellen.
Meine seriellen Nachrichten sind wie folgt eingerichtet:
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. Aus 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 alles funktioniert in Ordnung, aber es fühlt sich ineffizient an. Benötige 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 es udpreceivein Max ein Objekt gibt . Und das funktioniert ok, denke ich? Vielleicht benutze ich es falsch.
Irgendwann hatte ich meinen gesamten Arduino-Code so umgestellt, dass am Ende jeder seriellen Nachricht keine Zeilenumbrüche gesendet wurden, da dies für Max ' udpreceiveObjekt nichts Besonderes bedeutete . Wenn ich mich richtig erinnere, würde es tatsächlich nur die erste Nachricht bis zur ersten neuen Zeile akzeptieren und dann die Datenverarbeitung beenden. Um das zu umgehen, habe ich alle Zeilenumbrüche entfernt und dann wurde es kontinuierlich in max / msp gespuckt.
Das nächste Problem bei dieser Methode ist, 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 in 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 soll. Oder wenn ich es nur ganz falsch mache?
Sollte 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 überhaupt benötigt wird. Können 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 in Ordnung sein.
Hast du einen Rat?
OMGWTFKnopf, aber auch sehr gut durchdachte und detaillierte Frage!