|
|
Post by uncledave on Jan 17, 2022 14:48:47 GMT
I'm experimenting with sending a SysEx message in multiple steps. Each Send has +F, and the last Send ends with F7. I'm running StreamByter as AUv3 in AUM. When I route the MIDI to an external receiver, like MidiFire or midiwrench, they receive the full message, as expected. But when I route it internally to a MIDI monitor (another SB, mfxMonitor, MidiSpy), they only see the terminal F7, which was the last thing sent. Is this a problem in AUM, or is SB not waiting for the full message before transferring fragments to the host? If I route the message to external MidiFire, loop it inside MidiFire, and receive it from MidiFire in AUM, I see the full message, as expected. The problem seems to be only when the message does not leave AUM. Now, since SysEx messages are likely meant for external gear, that's not a serious limitation, but it does seem incorrect. nic ? Edit: It's even worse with Audiobus. Looping the message through MidiFire results in only the trailing F7 being seen on a monitor in Audiobus. The monitor in MidiFire shows the full SysEx message on a single line, but apparently it is relayed in fragments. Am I wrong to add +F to each Send? |
|
nic
Soapbox Supremo 
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jan 17, 2022 16:49:14 GMT
Hi uncledave , The +F means 'force' - ie. break the sysex standard (bypass checking) and send an invalid message. The host apps are getting partial sysex messages and unless they have the capability to assemble multi partial sysex are likely to barf. The +F was really designed with the original Stream Byter module in MidiFire. If you need to send sysex messages that are longer than 16 bytes, try adding a +I to each send - My memory is hazy and I don't remember if the AU StreamByter includes the code to assemble injected partial messages, but it might in which case it should deliver the full sysex message to the host. Let me know if it works or not. Regards, Nic. |
|
|
|
Post by uncledave on Jan 17, 2022 23:10:12 GMT
Thanks nic, I'll give that a try, though I'm not sure how to get that internal message out. Need to think about that. Anyway, it works fine going to external ports, which is what counts. While doing this I discovered another annoyance. The only MIDI monitor that displays a full SysEx message is the old MidiFlow Monitor, running stand-alone. The internal monitor in MidiFire, the SB monitor, mfxMonitor, and MidiWrench all truncate the message with ... MIDISpy is even worse; it does not appear to recognize the SysEx message at all, and just displays "247", F7, useless! This is actually quite an interesting project. I'm helping mo13 with sending commands to his ES-9 Eurorack mixer. They expose all the controls to SysEx, while only a subset respond to CC. And they use a 3-byte format to send a 16-bit word, split 2:7:7, so this extends 14-bit MIDI controls to the next level. We did a bit of this before, but didn't need to go beyond 14 bits. Now we're doing filter cutoff frequency on a log scale, so we have to use the full range. Cheers, Dave |
|
|
|
Post by uncledave on Jan 18, 2022 16:00:48 GMT
Hi uncledave , The +F means 'force' - ie. break the sysex standard (bypass checking) and send an invalid message. The host apps are getting partial sysex messages and unless they have the capability to assemble multi partial sysex are likely to barf. The +F was really designed with the original Stream Byter module in MidiFire. If you need to send sysex messages that are longer than 16 bytes, try adding a +I to each send - My memory is hazy and I don't remember if the AU StreamByter includes the code to assemble injected partial messages, but it might in which case it should deliver the full sysex message to the host. Let me know if it works or not. Regards, Nic. You were right! Looping the message through SB seems to collect it into a properly formatted SysEx. We tried it without +I, and even though MidiFlow Monitor showed the full message, the data reaching the hardware was garbled, causing much confusion. I guess MF Monitor was collecting the fragments for us. The final script is here. It might be a useful example for anyone trying to create long SysEx, and using the ES 3-byte format for a 16-bit value. Thanks very much, Dave Edit: Maybe I spoke too soon. This works for SB in MidiFire, which should satisfy our user. But it does not work at all in AUM. There, the message fragments are received as they are sent yielding junk as a result. This may need some further study. |
|
|
|
Post by uncledave on Jan 24, 2022 11:32:40 GMT
Here is my improved version. It's still flakey inside AUM, but seems OK externally. I also implemented this function in Mozaic. Moz has the advantage of an array Send capable of handling long strings. It would be great if SB had a similar array send. Maybe it could be an adaptation of the existing UDP send (option +S?). Then we could send moderately long SysEx with confidence. Loading the data in the W array would be no problem. We could even consider a "generalized" script capable of sending various ES SysEx control messages. |
|
