HMM. I am not sure.
I don't think Pd would split a message across multiple blocks. If anything, Pd would make your audio glitch rather than breaking its determinism (it's a design feature). Also, if that was the case, you should see
bela: print: 1 0 0 1
bela: print: 0
I am not sure why you see that print, though. It may have to do with line buffering. When running a script from within the IDE, all stdout buffering is disabled, to be able to print the messages fast enough. Again, I would not expect this to add a line break (and even less so should it break your Pd code). One possibility is that the cpu is so busy that rt_printf (which is called by Pd's print) sends the output in two separate chunks (which is expected, given its low-priority nature), although I would not expect this to happen unless you have a very busy AuxiliaryTask.
To sum up, I expect the list to be delivered to the C++ code at once. What do you do with it? How does your list get converted to analog outputs? I guess you must have a custom render file for that. Note that the message to the receiver will come in in-between audio samples (because Pd's internal clock is actually more accurate than sample-accurate), and it will call the callback while your render function is being executed, so you may have some sort of race condition there? For instance, what happens if the list comes in halfway through a loop in your render function?
When the 5 analogue outs are set up with the correct values, then a 6th out goes from high to low and the LCD executes the command.
How do you know the 6th output goes high after the others? Do you wait for one sample after you wrote 0-4 before writing 5?
