Faccio un'interfaccia drum sequencer per la musica elettronica .
Utilizza un mega arduino come microprocessore e attualmente si interfaccia con un programma di elaborazione che ho scritto per la comunicazione seriale. Da lì, i messaggi OSC vengono inviati a un programma Max / MSP che il mio partner collaboratore ha scritto per creare un flusso di dati midi.
Così:
La mia interfaccia fisica -> Arduino Mega -> I / O seriale -> Elaborazione -> OSC -> Max / MSP -> Midi (-> app musicale)
Ho scelto questo percorso in parte per non essere abbastanza intelligente da rimuovere ancora nessuno dei passaggi, ma anche per poter essere in grado di aggiornare l'interfaccia fisica come desideriamo, essere in grado di rendere l'interfaccia fisica multiuso (più modalità per fader, manopole e pulsanti di selezione della voce) ed essere in grado di garantire il timing mission-critical e la modifica del ritmo (alias "swing").
I miei messaggi seriali sono impostati in questo modo:
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)Quindi, puoi vedere che in base al numero di virgole per punto e virgola, posso determinare come analizzare i dati seriali dall'arduino nel programma di elaborazione. Dall'elaborazione, questi tipi di messaggi vengono trasformati in OSC in questo modo:
/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 36E tutto funziona bene, ma sembra inefficiente. Ho davvero bisogno dell'app di elaborazione nel mezzo?
Ora, avevo cercato di eliminare dall'equazione Processing e le parti OSC, ma mi mancano alcune conoscenze in merito alla progettazione del protocollo di dati seriali.
Sono consapevole che c'è un udpreceiveoggetto in Max. E funziona bene, immagino? Forse lo sto usando male.
A un certo punto avevo cambiato tutto il mio codice arduino per non inviare nuove righe alla fine di ogni messaggio seriale poiché ciò non significava nulla di speciale per l' udpreceiveoggetto di Max . In effetti, se ricordo bene, accetterebbe solo il primo messaggio fino alla prima riga nuova e quindi smetterebbe di elaborare i dati. Quindi, per ovviare a questo, ho eliminato tutti i caratteri di nuova riga e poi sarebbe emerso continuamente in max / msp.
Quindi il prossimo problema con questo metodo è che l' udpreceiveoggetto accetta solo un carattere alla volta. Quindi stavo cercando di utilizzare un jsoggetto JavaScript per concatenare i caratteri in arrivo, quindi analizzarli nei punti e virgola e nelle virgole. Il problema in cui mi sono imbattuto era che era imprevedibile e instabile. I personaggi si ritirerebbero e il messaggio non sarebbe elaborabile. Quindi mi sto davvero chiedendo se dovrei cambiare il mio protocollo seriale con qualcosa di più robusto? O se sto sbagliando completamente?
Devo semplicemente scartare tutto e ricominciare da zero usando un firmware firmata? Ho visto alcuni tutorial per usare la firmata con Max / MSP , e immagino di poter dare uno sguardo nuovo a ciò che sta facendo il codice sulla scatola e se deve farlo. Il firmata può accettare i dati di stringa su un pin da inviare al LCD seriale di bordo? se riesco a controllare il display LCD da max / msp, potrebbe funzionare bene.
Hai qualche consiglio?
OMGWTFpulsante, ma anche domande ben ponderate e dettagliate!