Arduino serial communication protocol design

... so long as it relates to electronics

Arduino serial communication protocol design

Postby miki » Thu Oct 06, 2016 12:15 am

I make a drum sequencer interface for electronic music.
It uses an arduino mega as its microprocessor {link edited out}, and currently it interfaces to a Processing program that I wrote for serial communication. From there, OSC messages are sent out to a Max/MSP program that my collaborating partner wrote to create a midi data stream.

My physical interface -> Arduino Mega -> serial I/O -> Processing -> OSC -> Max/MSP -> Midi ( -> music app)

I chose this path partly out of not being clever enough to remove any of the steps yet, but also to accommodate being able to update the physical interface the way we want, being able to make the physical interface multi-purpose (multiple modes for the faders, knobs, and voice select buttons), and be able to ensure mission critical timing and rhythm modification (aka "swing").

My serial messages are set up like this:
Code: Select all
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)

So, you can see that based on the number of commas per semicolon, I can determine how to parse the serial data from the arduino in the processing program. From Processing, these kinds of messages are transformed into OSC like this:
Code: Select all
/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

And it all works ok, but it feels inefficient. Do I really need the processing app in the middle?
Now, I had tried to chop Processing and the OSC parts out of the equation, but I'm missing some knowledge in regard to serial data protocol design.

I'm aware that there is a udpreceive object in Max. And that works ok I guess? Maybe I'm using it wrong.

At one point I had switched all of my arduino code to not send newlines at the end of every serial message since that didn't mean anything special to Max's udpreceive object. In fact, if I recall correctly, it would only accept the first message up to the first newline and then it would stop processing data. So to get around that, I took out all the newline characters and then it would spew into max/msp continuously.

Then the next problem with this method is that the udpreceive object only accepts one character at a time. So I was trying to use a js javascript object to concatenate the incoming characters, and then parse them on the semicolons and commas. The problem I ran into there was that it was unpredictable and unstable. Characters would drop out and the message would be unprocessable. So it's really making me wonder if I should change my serial data protocol to something more robust? Or if I'm just doing it wrong entirely?

Should I just scrap it all and start over from scratch using a firmata firmware? I've seen some tutorials for using the firmata with Max/MSP, and I guess I could take a fresh look at what the code on the box is doing and if it needs to do it at all. Can the firmata accept string data on a pin to send to the on-board serial LCD? if I can control the LCD from max/msp, that might work out ok.

Got any advice?
Posts: 1
Joined: Tue Aug 16, 2016 8:38 pm

Topic Tags

Return to Ask us anything

Who is online

Users browsing this forum: No registered users and 1 guest