Diseño del protocolo de comunicación serie Arduino

Hago una interfaz de secuenciador de batería para música electrónica .

Utiliza un arduino mega como microprocesador, y actualmente se conecta a un programa de procesamiento que escribí para la comunicación en serie. A partir de ahí, los mensajes OSC se envían a un programa Max/MSP que mi socio colaborador escribió para crear un flujo de datos midi.

Asi que:

Mi interfaz física -> Arduino Mega -> E/S serie -> Procesamiento -> OSC -> Max/MSP -> Midi ( -> aplicación de música)

Elegí este camino en parte por no ser lo suficientemente inteligente como para eliminar ninguno de los pasos todavía, pero también para poder actualizar la interfaz física de la manera que queremos, poder hacer que la interfaz física sea multipropósito (múltiples modos para el faders, perillas y botones de selección de voz), y ser capaz de garantizar la modificación del ritmo y la temporización de misión crítica (también conocido como "swing").

Mis mensajes seriales están configurados así:

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)

Entonces, puede ver que, según la cantidad de comas por punto y coma, puedo determinar cómo analizar los datos en serie del arduino en el programa de procesamiento. Desde Processing, este tipo de mensajes se transforman en OSC así:

/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

Y todo funciona bien, pero se siente ineficiente. ¿Realmente necesito la aplicación de procesamiento en el medio?

Ahora, traté de eliminar el procesamiento y las partes OSC de la ecuación, pero me falta algo de conocimiento con respecto al diseño del protocolo de datos en serie.

Soy consciente de que hay un udpreceiveobjeto en Max. Y eso funciona bien, supongo? Tal vez lo estoy usando mal.

En un momento, cambié todo mi código arduino para no enviar nuevas líneas al final de cada mensaje en serie, ya que eso no significaba nada especial para el udpreceiveobjeto de Max. De hecho, si no recuerdo mal, solo aceptaría el primer mensaje hasta el primer salto de línea y luego dejaría de procesar los datos. Entonces, para evitar eso, eliminé todos los caracteres de nueva línea y luego arrojaría a max / msp continuamente.

Luego, el siguiente problema con este método es que el udpreceiveobjeto solo acepta un carácter a la vez. Así que estaba tratando de usar un jsobjeto javascript para concatenar los caracteres entrantes y luego analizarlos en los puntos y comas. El problema con el que me encontré allí fue que era impredecible e inestable. Los caracteres desaparecerían y el mensaje no se podría procesar. Entonces, ¿realmente me pregunto si debería cambiar mi protocolo de datos en serie a algo más robusto? ¿O si lo estoy haciendo completamente mal?

¿Debería desecharlo todo y empezar de cero usando un firmware de firmata? He visto algunos tutoriales para usar la firmata con Max/MSP , y creo que podría echar un vistazo nuevo a lo que está haciendo el código en la caja y si es necesario que lo haga. ¿Puede la firmata aceptar datos de cadena en un pin para enviarlos a la pantalla LCD serial integrada? si puedo controlar la pantalla LCD desde max/msp, eso podría funcionar bien.

¿Tienes algún consejo?