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.
----------begin_max5_patcher---------- 1754.3oc4b0zaaaDD8r7uhEB8nqy98G8VQbKZA5ghfh5CEAEzVz1rUhTPhtw oA4+d3GRvzwhTy5PNTj7PTrnHkdu2N7MytyJ8oylM+5jGC2Nm7Cj+hLa1mNa 1rhCkefY6d9r4qBd7lkAaKNs42jrZUXb57yKeszvGSKN96RdHMJ9NxaShS2j rb+qG+vprWXYXZwUS2czayNosQ+eX9wXzK1e30aB2l8dGjFkD+2aBuIsDXLF WkcNDlL+Q5tGHue+UEjdy8YezUtBcwIwJtJKq3usUthnEEPN45+46Ut4UvTb vpBLM+G2DETkCQw6o.K+Xe9ryxe3bfZVwUeXEgs6nkGJ8iqCKYv74Owu5TEk HmYBETUgQKNUQw4VJo4OdPYwdPxuefZePP9oO+UHH0EDEDufrMgjDSt3hK7H DherPHI0VPWsCpXIKEKtr3jslhmPqQsLHDDk8Fbc3lCKJ7lEkWDbEkq8j4WG De2wiyLERGiSOnzkwpnUOrp5PSFr2eHNk1P7ns3cyU7nv1nBKFwJLWzUJ7tn WPJrbLqvttRgET3JrZDqvBUmovZ3JrdDqvRtnTgYssBK4fUXoaLqv1NSg8HS GcDqvJYWovJOxzwFwJrl1UJr1iLc7wrBqKmPIy05JL7LcxwbsDFdWovFOxzM lqkvX6LEFdlN4XdVyVYWovV3Y5j1wrB6bkJrssUXG7Lcxw75R3TclB6Qltw7 5Rvnk9CcwhqQ8HWGJ0qE9grOqWrjuaWGFtXYzplWdbnhO.EubIfYJN7kMWqp LHUdSQsRouStf2hKe9OmIkWGby+1lMewIsO0KEHxkyUo4KJUSMeQnGpMewoE O0JEXAQva9hvzoMeojsMGiT25nVF7qLbO64z9tozLukGdPuk3cMFPAqWGFuf vklV2Bp9VvUl+yHaxJQfQsE0YkjlPVEsHJicut1vcnppJBDJaWotYliwJzrJ b61f6BeAy4DFQS9NFRIj3NcQDgS.8VJgrZmIUxlbX4NDRG0jRx6Bkr16qfoI VDzjZLaxBB141PIZCgoIVLscJy9v3MVMHia54a+T3DzvsvCZXLSOemjDIQg6 inn6YQQfj8h1GQQ0e9Kax3U3lbekmFZ9Jcw3qvb923+.XLsemfT9e0ZLw7th Hyo3hA7MMqd3quJiQGgSqu9oVAZ94Lpr+t6DQQwI8QSTSBMwZ8QSzSCMg6il XlDZhQ6ilXmFZhGdrN2jPRzdYwRmDZhxKKV1zPS7xhkOIzDoWVrhogl3iE6z HSrvCKV2zHQL2CGV2znFVtGFrtowTcXd3u5j8XKquJX4RxeFr4iutdVefpxD Ua+biqTm0ziMX6xv0o22VjVYpRZZij11ij9WBit69zVi0L3r10ir9pEs2HsT UgyBdSb1Q6QN+Sady6B+uvMW2VD2Z.usR3n78.p1X7HxkAqV2V71IfyalnWM zh2Fk1Z93VlG7tOGuyByIWFtLn0XtQAm4bdeNhu4iu4pvVyNW67f2p9cDOyX i76AwsE0Yzpi45F+EKfoT8p61c2Sd6Cs1ftn5ftz0Lw6yRW9sjOzp7tpstT2 Huk8Ycp+ZbTZ65uwgWrJS0q9aQ2d6CaiRZsay4Uyosae0V6ftrGY9eDsJr07 1fWwJyHN82Pv0uAwgr2dYrNcu815baWejAQM9vhZ6ZGLHpIFXTiCmZxgE0Ld bulZfQM3eEAzCKlog6hXFVLSA2DwNvXFbOD2IGyx22c.5+HHWD5vicd7C81f ibB3dIhAG43vsSjCOxA2QgO3HGyCGkWE4JdmluLJ9q+85r.L4G+4LdaxCatY O52+a5H4I.sHbaZTbwWGoJmTwdrtxYcezhEgwOaqJGsXcRlZrCEj2evA.nfp XSJeTTk+spkvPCT4eenOtRkuShwDTRPfRgKnDf.kFWPAJPOeyrhInLf.kEWP oA.p7syIlXRARnnnBJELGAbsox+gLC.n33BJJHPIvMlxAINGWCAEn68v0OPA 4dOGtt4JH48b3l1SAIsmC45CXfKuioQr9Nnk2gWMmBC3x6PrPXpB93mDQXog CKAhvx.GVbDgE74XwvyZv4fiJLi3ofgkCQTA2G0hHp3fQkAQTI.iJ7R43faM nvCTvMFvyb2A2aGOqcG77fXZrKgaghXTkGnBwR9d9mWcnRg7BM97Hl5PktGP k3nnxzCnRdDTwc8.nNVvN2h6TIffIAxyjfCIAn.204mCJ+GG63b0IIpzmjnx bBhJt6TTpft3PHpSPWCM7fjD5RMhnaNzUjEOHoftv0XNucvqvOdfxAtUH3gI K3dFgGlLfatFdXBbSHQLFWAtasHBJI39ZiHnfuC.vrDXv6UhWKnxdxmO6Kf. XuDG -----------end_max5_patcher-----------