You should send it to the midi interface. The midi interface is patched to it send it to the MCU component within cubase, it should also be patched so it send C4 data to same MCU component.
It does not work that way. If you look how a connection is established according to Logic Manual 7.2 page 240, you will see, that i need a answer from the MCU protocoll, that my C4 will not receive. It will be received by the MCU component. The component speeches to the MCU protocol. Everything what is happening there, is invisible to us. For example, you dont see the midi-data transfered from MCU protocol to realworld MCU. You can at max observe, what midi you send with a MCU, but not what it receive from the protocol.
You simply do not understand the MCU protocol.
The protocol does answer anything. You dont even know what a protocol is.
There is a MCU driver in cubase. There is a C4 controller. Between them there is midi. The MCU protocol requires bidirectional transport. With a good interface you can listen and send on both directions.
For example: If C4 is turned on, it sends:
F0 00 00 66 17 01 00 00 00 00 00 00 00 34 31 06 00 F7
A DAW will answer with:
F0 00 00 66 17 01 00 00 00 00 00 00 00 7A 5E 7E 12 F7
The C4 will answer with:
F0 00 00 66 17 01 00 00 00 00 00 00 00 7A 5E 7E 12 F7
Connection established. The bold values, will change each time you restart your DAW.
No you can not listen to both directions. Cubase or MCU protocol is not sending the C4 any sysex. I monitor it, but dont see anything.
Therefore i can not reply and no connection is established.
Then you will need to do little midi application. Any programming language with midi should work. Python or java.
This is way beyond my knowledge. You need to know, that you need to respond in 0.300ms or connection will be terminated.
Still the simplest thing to do, would be to create the MCU component and to change the sysex there.
This can only do a Cubase developer unfortunately 
.
Hi,
Iām sure not Cubase developers only. Lots of hardware manufacturers are writing own components too.
Then it is not possibleā¦ The message is 18 bytes. It take about 3.9ms to transfer a byte at midi speeds. So about 70 ms in total, and then another 70ms for the reply.
It is 300 milliseconds, just checked.
Maybe some people can do that. We all here obviously not.
Hey, Martin.
I remember trying to find the MCU protocol documentation a few months ago without success. Iāve been a professional dev for 30 years and sometimes play with things just for the fun of it (clearly Iām in need of therapy).
Would you happen to know where the spec is? It hasnāt been Gregās Mackie in long time and I couldnāt find any indications on the Mackie website.
Some interesting information in here, i would love to be able to adjust the MCU support too.
I looked into it a while back and itās appears to be an unclimable wall as no SDK exists that i could find, yet people out there are writing extensions for control surfaces - i guess you have to be a hardware partner or something perhaps?.
Another issue youād have with using the C4 is, even if running smoothly, when multiple Mackie controls are in use the controls spread across them and thereās no way to mirror. i.e. if you had an MCU for faders and a C4 for plugin control, the first 8 vpot parameters would be on the MCU, and vpots 9 and onwards would be on the C4. Thereās no option to put 1-8 on the second surface (i.e. mirror). 
This is a real pain if you have an MCU and a second controller (Such as keyboard controller) that utilises Mackie protocol. It really canāt be that hard to setup a mirror option, surely?!
Sorry but you must be confusing this with something else, such as the Avid hardware perhaps? Iāve created software emulations of MCUās before as i was working on a modular hardware controller project but ran out of funding. And thereās no protection there whereby only ārealā hardware can answer, itās all quite straight forward and you can send directly to the Mackie displays using SysEx without any return communication.
i.e. using only Midi Out from computer it would still put up a display (from memory).
However, i think thereās something in the licensing issue, because the documents that were easily to get in years gone past seem to have dried up now. You used to be able to get very detailed docs on all the hardware - most of which has vanished.
Hi,
Here is kind of specification. The problem is, there are some mistakes. As you can see, D#2 is assigned to the āV-Pot switch 8ā same as to the āEditā.The āChannel Rightā, āFlipā and āEditā buttons are all shifted one octave. It should be C#3, D# and D#3.
And of course the Function buttons are described for the Digital Performer in the very most left column and the default button description on the most right column. Cubase has other functions assigned to these buttons. So you have to compare with the Cubase layout.
The display response is very well described here.
It does not cover multiple displays like the C4.
Hi,
Sorry, I was talking about MCU (Mackie Control Unit).
I believe it will be quite similar for the other displays at C4.
They are part of the same controller family with the Mackie Control Unit, Mackie Control Extender, Mackie Control C4, where the MCC4 is discontinued. However they are most likely use very similar protocols.
From memory with the C4 i think you just change the controller message from 12 (0x12) to feed the other rows, the basics are the same across the entire protocol and at least follow a sequential logic.
Itās super easy to find out (if you own a C4), just run the C4 Commander software and trace the messages that get sent using monitor software.
You can still get the C4 commander software (Plus a lot more!) from this archive (SW_c4c_pc_v1.0 file for example):-
https://supportloudtech.netx.net/loud-public/#/search/basic/c4
The display are sysex and does not send data.