You'd have to add some delay between each step of an animation.
There are many ways to do it but I'd use an FSM and/or SoftwareTimers.
This way you already would implicitly address your second question as you'd never even had any loops to break.
That would also help decouple the animation playing and the command reading/parsing.
BTW, regarding your binary data.
I've never "programmed" a MaxMSP, so I've no idea what's possible there or not, but I'd rather surprised if you couldn't package binary data with it somehow (what language are you using?)
I'd put the option selector (%s) into as leading byte into your 32bit value.
With that you could do something like that in your Photon code
enum FIELDS{ OPTION, R, G, B };
uint8_t data[4];
...
if(sizeof(data) == Udp.receivePacket(data, sizeof(data))) { // when we got a full packet
select(data[OPTION]) {
case 'B':
// deal with B
break;
case 'C':
// deal with C
// colors would be accessed via
r = data[R];
g = data[G];
b = data[B];
break;
default:
// deal with invalid option
break;
}
Here you can get an idea how this could be done
I've modified some of the (simpler) animations to illustrate the non-blocking paradigm.
Each of these animations is only visited for on single update and yields back control immediately. The animation sequence is bound to a step
variable that allows it to advance on next visit.
I also dropped your 'C'
option and its related f
value and rather took the first byte of the 32bit value to carry all the info that's needed (values 1..16 and 'B'
).