Timing of SysEx blocks

    Peter Ostry
    Mar 01 2010 | 5:33 am
    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?
    • seejayjames
      Mar 01 2010 | 6:12 am
      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.
    • Peter Ostry
      Mar 01 2010 | 10:41 am
      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?
    • seejayjames
      Mar 01 2010 | 11:31 am
      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...
    • Daniel P
      Mar 02 2010 | 11:54 pm
      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...
    • Peter Ostry
      Mar 03 2010 | 11:50 am
      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.