Eu faço uma interface de sequenciador de bateria para música eletrônica .
Ele usa um mega arduino como microprocessador e atualmente faz interface com um programa de processamento que escrevi para comunicação serial. A partir daí, as mensagens OSC são enviadas para um programa Max / MSP que meu parceiro colaborador escreveu para criar um fluxo de dados midi.
Assim:
Minha interface física -> Arduino Mega -> E / S serial -> Processamento -> OSC -> Max / MSP -> Midi (-> aplicativo de música)
Eu escolhi esse caminho em parte por não ser inteligente o suficiente para remover qualquer uma das etapas ainda, mas também para acomodar a possibilidade de atualizar a interface física da maneira que queremos, tornando a interface física multiuso (vários modos para o faders, knobs e botões de seleção de voz) e garantir a sincronização crítica da missão e a modificação do ritmo (também conhecido como "swing").
Minhas mensagens seriais são configuradas da seguinte maneira:
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)
Assim, você pode ver que, com base no número de vírgulas por ponto e vírgula, posso determinar como analisar os dados seriais do arduino no programa de processamento. No processamento, esses tipos de mensagens são transformados no OSC da seguinte maneira:
/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
E tudo funciona bem, mas parece ineficiente. Eu realmente preciso do aplicativo de processamento no meio?
Agora, eu tentei cortar a Processing e as partes OSC da equação, mas estou perdendo algum conhecimento em relação ao design do protocolo de dados seriais.
Estou ciente de que há um udpreceiveobjeto no máx. E isso funciona ok, eu acho? Talvez eu esteja usando errado.
Em um ponto, eu havia trocado todo o meu código do arduino para não enviar novas linhas no final de cada mensagem serial, pois isso não significava nada de especial no udpreceiveobjeto de Max . De fato, se bem me lembro, ele aceitaria apenas a primeira mensagem até a primeira nova linha e, então, interromperia o processamento de dados. Então, para contornar isso, peguei todos os caracteres de nova linha e depois ele se espalhou para max / msp continuamente.
O próximo problema com esse método é que o udpreceiveobjeto aceita apenas um caractere por vez. Então, eu estava tentando usar um jsobjeto javascript para concatenar os caracteres recebidos e, em seguida, analisá-los com ponto e vírgula e vírgulas. O problema que encontrei lá era que era imprevisível e instável. Os caracteres desapareceriam e a mensagem não seria processável. Então, isso realmente me faz pensar se devo alterar meu protocolo de dados seriais para algo mais robusto? Ou se eu estou fazendo errado completamente?
Devo simplesmente desfazer tudo e começar do zero usando um firmware firmata? Eu já vi alguns tutoriais para usar o firmata com Max / MSP , e acho que poderia dar uma nova olhada no que o código da caixa está fazendo e se é necessário fazê-lo. O firmata pode aceitar dados de seqüência de caracteres em um pino para enviar ao LCD serial de bordo? se eu conseguir controlar o LCD de max / msp, isso pode funcionar bem.
Tem algum conselho?
OMGWTFbotão, mas também muito bem pensada e detalhada!