Mackie C4 Pro and Cubase

No, i do not need to reverse engineer anything and i also do not want to do something that MCU can not do. I want a component that does Sysex handshaking, so that the MCU protocol is aware of a C4. I talked so much about it, but no one seems to understand me :frowning: .

The Mackie MCU protocol, provides everything for the whole product-line (MCU+XT+C4), it just needs to know that a C4 is present.
I will make a graphic that is maybe more clear. The MCU protocol is like a virtual midi-interface, between this productline and the DAW.
A DAW developer need to provide components for the MCU protocol. The components we currently have, do not need a mastery skill level to create.
Everything else is delivered by the MCU protocol: Faders, Encoders, Rings and Displays and the displays can only show something, what the MCU protocol can find in the DAW and what the DAW provides. So everything what a MCU or XT can display, can be displayed on a C4 too.
A C4 is basically four times a XT, just with encoders instead of faders. :slight_smile:

MCU only do sysex for the display. Do you have the protocol spec for the C4?

Checking my cubase 10.5.12 installation. The MCU is not a dynamic bundle. So it is linked in to cubase binary, and that makes it very much harder to do a parallel C4 based on a MCU library. (This is also a good indication on that it is Steinberg that has written the MCU driver)

Hi cubace,

We do not need the MCU protocol we need the component (the one you choose in the “Studio Setup Settings”) and there is no Sysex for communication between MCU protocol and the MCU,XT,C4. Except the only time, when you turn on the devices. This sysex needs to be in the component, because otherwise the MCU protocol can not see or create the connection.

There is no real protocol spec for the C4, but there is for MCU and XT. It is the one in the Logic 7.2 manual i previously posted.

If you turn on a C4 and start the Commander software, you will see what a successfull sysex connection means, because then the C4 is ready to be programmed with the MCU protocol or the Commander software. If you then start Cubase and use the MCU component (the one you choose in the “Studio Setup Settings”), then the encoders will start working, except no display and you trick/fool the MCU protocol, because it thinks that there is a MCU (in reality a C4).

This process, can not be fooled by other hardware (Behringer, Novation etc.), because you cannot “steal” the sysex of a hardware. This is a proof that the MCU protocol handles MCU+XT+C4. This process only worked, because we used the Commander software for sysex handshaking and then started Cubase.

Since Cubase does not have a C4 component (with the sysex), the MCU protocol can not see it.

No it is not, it is only a indication, that BOTH companys want their stuff to be protected and is part of the deal, how that works and looks.
The component however does NOT need to be protected, because there is nothing in it, that needs to be protected.
The component just describes the connected hardware and provides assignment for the buttons (not encoders).

That the code is static linked in to the binary is a good indication that it’s steinberg that do the coding. IPR may still be shared with Mackie.
Yes, it does not have do be protected. But they have chosen to have it protected, and since it is within the binary I guess the code is also protected with the dongle checksums. The C4 has a lot of different properties than the XT so it wont work as you wish.

You need some asymmetric crypto with challenge-response to stop that from happen. And you need to protect the private keys. So in one way you think C4 is the same as an extender, and now it is something you cant even copy?

You simply dont understand the MCU protocol. Steinberg did only the connection handling, and because every DAW treats that differently, it needs to be done by the DAW developers themselves. So a DAW developers duty is, just to connect “Control Surface Layout and IDs” from the Logic manual 7.2 starting at page 251 to its own Host protocol and to deliver the components for the MCU protocol. A DAW connection that provides all that DATA IDs to the MCU protocol and this protocol process that DATA and communicates that, with common Midi-controller messages to the hardware devices.
The hardware itself is a dongle, because it needs sysex-handshake with channel response, that only the “real” hardware can answer. You see, software and hardware is protected. It is part of the license-agreement. You will not get the MCU protocol otherwise.

Do a research on Google for the MCU/HUI protocol, i will not explain it anymore further here. It is not written by Steinberg, end of story.

In no other DAW, are the components (for MCU protocol) protected. In some cases they are even just a simple .ini file or a simple XML file.
But the MCU protocol itself is hidden deep in the DAW software. In case of Steinberg, it is maybe like you said, a double protection, because of the dongle. I do not think that the dongle is involved, into the communication between DAW and MCU protocol, because it would slowdown operation and is not needed, because MCU protocol is already in the binary-code of Cubase and therefore well protected. This protection works well, till today noone could “crack” the MCU protocol. No matter if it is hidden in a DAW software with dongle protection or not. Tracktion, Sonar, Reason, all have no dongle protection.

I can copy the component, because thats how you extend the MCU with a XT, but i would need to exchange the sysex-message that is sent by the component, because it is different hardware then a XT.
You can use the same MCU component (by accident) on a XT, just because it is the same as a MCU, minus the Transport controls and assignment buttons, they are both very much the same.

You all need to understand that the whole productline (MCU+XT+C4) are “passive” controllers. The controllers have initially no “brain” and without a MCU protocol, they do not operate with full functions. The MCU protocol tell them how to work properly and give them all the infos for the displays, rings, encoders, faders.
The C4 can not work properly, since the MCU protocol can not program it, because it do not see the C4. There is no sysex-handshaking that allows this. You can trick this, if you just start the Commander software (doing nothing else), this software has proper sysex-handshake and put the C4 into online mode, if you then start Cubase and use the MCU component, it will start working magically, because the MCU protocol starts to program the C4, but sadly it is thinking it is a MCU.
As soon as you quit/close the Commander software, the C4 wents into offline/passive/brainless mode and the MCU protocol can not see the C4 anymore (again).
Again the C4 sysex is not documented anywhere, but if you look at the Logic manual 7.2, how to establish a connection, you will see that there is no mention of a C4. Important here: the manual shows only just a example how you do this and NOT ALL cases of how a sysex-handshake can look.

Since all the “big work” from Steinberg to have a functioning MCU protocoll is already done (MCU+XT are properly working), we only need a component that invokes the sysex-handshaking between a C4 and the MCU protocol, by sending this sysex to the MCU protocol:

F0 00 00 66 17 01 00 00 00 00 00 00 00 34 31 06 00 F7

then a C4 will start working, believe it or not. That is how all the other DAWs have done it. Nothing more was needed, once you have a working MCU.
Sadly a C4 sends only once this sysex (when turned on) and then waits for a response from the MCU protocol. The MCU protocol can not respond, because it does not see the C4. Steinberg sadly did not know this and this is the reason, why we do not have a C4 component.

So, create a sysex file with that content and send it to the C4 from cubase.

Dude, you dont get it. I need to send the sysex FROM a C4 to a MCU protocol. If you can tell me, how to do that, i will do it.
Sending a sysex from a hardware device that it is not known to exist, in Cubase DAW or MCU protocol.

Are u using a C4 or a C4-pro?

It works for both, but i have a C4 pro

C4-pro has usb, and only usb. You need a device that can merge midi streams on usb.
If you dont have a nice loopback in your stack, it you can use this hardware I have an older model with network but I that one should be the same.
WIth this you can merge midi, so you route cour C4-pro in/out to that units ports. Then you also route one of its output to the same input as you have routed the mackie. It will merge the midi streams.

C4 or C4 Pro DO NOT have usb, they only have midi-in and midi-out. MCU Pro, is the only device with usb.

Then you can do it with any midi interface that can do merge. You can do that with the iConnectivity mio device but sure there are other that also can do that. But you get the point, if you can’t do it in your computer you need to do it externally.

I DO NOT have a MCU or a XT. I might get one from a friend. I ONLY have a C4. So i can not merge anything. I have a MOTU Timepiece AV with usb. I have a patchbay-software for routings, but i would need a real MCU, that i do not have.

I can try to create a Midi-device (for the C4) in Cubase and try to send the sysex from there, but i can only hope, that a MCU can see it (i doubt it). Also i am unexperienced in creating midi-devices (in Cubase) that involve sending sysex messages. Right now, i am reading the Cubase manual how i can do that.

You should merge the C4 with a cubase output, not a MCU or XT. With this merge you can send the “magic” sysex to the MCU input.

Yeah ok, explain it in some more detailed steps, so that i know how to do exactly this.

You need hardware that can do midi merge. If your MOTU has patchbay you need to figure out how to do the merge. Sorry cant help youy how to do that on that unit. Do you have some other software that can send sysex?

Ok, i have success with Midi Translator Pro. I can send the sysex by pushing Vpot 1.
But as i said, i can not send it to the MCU protocol, because there is no MCU protocol that you can choose as a destination. In fact, i can not even choose the MCU component as a destination. So it can not work this way.