Timing of SysEx blocks
I send SysEx in small blocks to a hardware synth to control several parameters in real time. Here is a typical example:
240 67 16 87 2 1 2 45 247
Since the messages can be sent by Max knobs, hardware controllers or DAW automation, it will occur that two or more SysEx strings reach [midiout] at the same time. I believe I will need a system to keep the individual blocks together, otherwise they would get mixed at the output — is this correct?
How is it usually done? I think about buffering and using the start and end of the SysEx message to block/trigger the following messages. Sounds rather complicated. Too complicated to be honest.
What about many instances of [midiout] – would they handle it on their own or is this generally a bad idea?
I had problems with some SysEx commands that I was sending via [pattr] interpolation. With lots of knobs turning and each sending a SysEx, everything would freeze up. Some [speedlims] at the midiout helped a lot, but eventually I had to ditch the interpolation. Though I think using just a few parameters would be OK.
Seemed like the commands which made it weren't garbled or overlapping, they went as blocks just fine, there were simply too many of them at once. I don't know if multiple [midiouts] would help. I was also using [sxformat] which may have slowed things down, but I can't imagine the bottleneck was there rather than the MIDI i/o rate.
I don't get the purpose of [sxformat] anyway. Seems to be a message and an [iter] in one but with more complicated variable handling ( this '/ is $i1 /' instead of simply $1).
Ah, I have a side question:
I can send SysEx directly from a message box and the synth is happy. Does it even make sense to send the stuff sequentially, by [iter], [sxformat] or some other serial method?
Once it actually gets sent to midiout, it turns serial anyway if I'm not mistaken, so no, might as well use message boxes. Maybe I'll go try my synth patch again and see if it speeds things up...
I have had some similar problems, on a Windows version of a Standalone using a lot of SysEx. What I recently came to think of, though I haven't tried it yet, is to change the scheduler settings, so that it is more tolerant to big chunks of a lot. Just putting it out nice and easily.
Just thought I'd chime in...
After some tests the obvious turned out to be practical ...
If [speedlim] objects are used, these must sit as close as possible to the data sources. If [speedlim] comes too late, the stream might already be serial and [speedlim] would remove single values from the SysEx stream.
For best performance [speedlim] should be adjusted for each single control to get a good balance between speed, overall load and skipped values.
Neither [sysformat] not [iter] are necessary. Sending a whole message block to [midiout] is enough and the fastest method. To avoid unnecessary data transport within the patch, the common components of the SysEx messages should be added at the latest stage possible.
Below is an example of what I found best up to now. It is not functional on its own, it is the interior of a [patcher] and shows the method. Tested with 5 inputs at highest speed and the synth followed happily.
What if there are 2000-3000 sysex parameters?
would the hardware still receive all of them happily?
or is there a limit to the number of parameters that can simultaneously be changed via sysex?