Oh yea of little faith. Yes, I pretty much know what I'm doing as I've been at this stuff for a long while. ;-)
Well what you ask now is not as easy as you might think. MT Pro determines the start of a message by the status byte (high bit set) and cannot break up SysEx into different pieces. I've added translators in case Cubase always sends the full 56 text bytes (plus the header and end of SysEx bytes) for each message but my guess is the length of the messages from Cubase might actually be shorter. It requires LOTS of global variables. So what you will need to do is see how long the messages are, that are coming from Cubase and take off the extra bytes from the end (but not the F7) . My guess is the messages will likely be much shorter than 56 bytes.
Also, I assume we are always starting at the first byte of each line which may not be the case. The variable rr is the start byte of the line and should translate correctly if left untouched.
The variable qq is the C4 display number 0x30 to 0x34 for displays 1-4.
Bottom line is for every virtual Mackie device, you need to put in translators like this for every possible length of bytes that Cubase might send as the pattern and number of bytes will need to match exactly.
See translaters 4.4 through 4.7 for 56 data byte data messages. We use all global variables from ya-yz y0-y1 and za-zz z0-z1. DO NOT USE THESE GLOBAL VARIABLES ANYWHERE ELSE IN YOUR PROJECT.
I would suggest monitoring Cubase and see if it is sending a consistent length of bytes and you might not need 56 combinations of byte lengths for every virtual Mackie devices. You might be able to get away with just shortening the existing patterns to something much smaller.
Remember the pattern length must match and the variables within them must also match.
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz (This is my paypal account)
Attachments:
1590465168011_V02_C4-2020-05-25-text.bmtp