Hago una interfaz de secuenciador de batería para música electrónica .
Utiliza un arduino mega como microprocesador, y actualmente interactúa con un programa de Processing que escribí para la comunicación en serie. Desde allí, los mensajes OSC se envían a un programa Max/MSP que mi socio colaborador escribió para crear un flujo de datos midi.
Así que:
Mi interfaz física -> Arduino Mega -> E/S en serie -> Procesamiento -> OSC -> Max/MSP -> Midi ( -> aplicación musical)
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 queramos, poder hacer que la interfaz física sea polivalente (múltiples modos para los faders, los mandos y los botones de selección de voz), y poder asegurar la modificación del tiempo y el ritmo de misión crítica (aka "swing").
Mis mensajes en serie 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)Así, puedes ver que en base al número de comas por punto y coma, puedo determinar cómo parsear los datos en serie del arduino en el programa Processing. 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 36Y todo funciona bien, pero se siente ineficiente. ¿Realmente necesito la aplicación de procesamiento en el medio?
Ahora, yo había tratado de cortar el procesamiento y las partes OSC fuera de la ecuación, pero me falta un poco de conocimiento en lo que respecta al diseño del protocolo de datos en serie.
Soy consciente de que hay un udpreceive en Max. ¿Y eso funciona bien, supongo? Tal vez lo estoy usando mal.
En un momento dado había cambiado todo mi código de arduino para no enviar nuevas líneas al final de cada mensaje en serie ya que eso no significaba nada especial para Max udpreceive objeto. De hecho, si no recuerdo mal, sólo aceptaba el primer mensaje hasta la primera línea nueva y luego dejaba de procesar los datos. Así que para evitar eso, quité todos los caracteres de nueva línea y entonces se escupía en max/msp continuamente.
Entonces el siguiente problema de este método es que el udpreceive sólo acepta un carácter a la vez. Así que estaba intentando utilizar un js objeto javascript para concatenar los caracteres entrantes, y luego parsearlos en los puntos y comas. El problema con el que me encontré fue que era impredecible e inestable. Los caracteres se caían y el mensaje no se podía procesar. Así que me hace preguntarme si debería cambiar mi protocolo de datos en serie a algo más robusto. ¿O si lo estoy haciendo mal del todo?
¿Debería desechar todo y empezar de nuevo con un firmware de firmata? He visto algunos tutoriales para utilizar el firmata con Max/MSP y supongo que podría echar un nuevo vistazo a lo que el código de la caja está haciendo y si necesita hacerlo en absoluto. ¿Puede el firmata aceptar datos de cadena en un pin para enviar a la LCD de serie de la placa? si puedo controlar la LCD desde el max/msp, eso podría funcionar bien.
¿Tienes algún consejo?
