Mackie C4 Pro and Cubase

[u-man]

@Martin.Jirsak

Hi,

Thank you for the message.

I can see one discrepancy in our thoughts. It seems you are convinced C4 is part if (and it follows) MCU protocol. I’m convinced it is not. Maybe I’m convinced about this, because I have never seen any DAW (but Apple Logic) which would integrate C4.

Well, i can not proof or give evidence that the handshake protocol would work in Cubase.
Simply by the fact, that you and i can not do it, as a normal user in Cubase.
But i proofed and showed you, that this is the case for every other DAW that has C4 support and more important, this is not just the Logic DAW. Tracktion and Reason have the same support and is also behaving, like in Logic.

Here you can watch, what a C4 can do with Tracktion: https://www.youtube.com/watch?v=eEhf7WNWGkU

So if you think i am wrong here, then i expect that you show me some proof/evidence for your theory. If you just say “i do not believe it”, well, that does not help anyone here or proof that you are right.

Moreover you should really read more carefully what i wrote, as you would better understand that i am indeed right. What you think is “magic” showing up in the Logic DAW (if a C4 is used) , is no magic at all. The C4 is just showing you, a extended display of a MCU unit. What you see in the video here, are basic operations of a MCU on 4 displays of the C4. Nothing more.

Watch the video again and show me one single thing on the C4, that you can not do with your MCU alone.
This means, that everything that you can see on a MCU display, can be extended to the C4 and for this process, you do not need any drivers or hocus pocus that Mackie needs to give to Steinberg, to get a working C4.
The MCU in Cubase, can not extend the display, because it can not find or “see” the C4 to do it. Thats all.

The Logic Manual says what you need to do, to make that possible.
Again, you did not read this carefully. I know that this is the Logic DAW manual, but in that manual, is all midi-specs for the whole MCU product line.
It is just labeled “Logic Control”, but is the same for MCU and valid TILL TODAY. Most DAW-controller used EXACT this manual, to get the info to build hardware based on the MCU protocoll.

@Martin.Jirsak

I just realised, what is my point of view, to the MCU in general. For me the main part is the “channels” area, plus the Transport part. This works the very same way in all DAWs. So this is the standard for me. The other (function) buttons is more like an addition for me. These could be mapped freely and very DAW developer does it different way. Now I see the C4 is kind of the same as the Function buttons. The communication is established, but every single DAW developer (or any software/hardware developer) can do whatever he wants to. Of course, it’s correct. At the end the device is just sending and receiving common MIDI data and everyone can interpret it as he wants to.

Every taste is different and Mackie tried the most, to deliver for each taste. I am not interested in faders at all. I have a Yamaha 01v96i for that. Perfect integration with bi-directional remote control of the DAW. I want more control over parameters and displays for them.
C4 delivers the very best options for this and at the end the device is NOT just sending and receiving common MIDI data, it also has four displays to label all that amount of data and can use readouts from the MCU protocol that VISUALLY show me, what the DAW is doing. Otherwise it would be a simple CC-controller.

@Martin.Jirsak

So you are right, the C4 has to be implemented completely on the DAW side. Which is not in Cubase (same as all other, but Logic, DAWs, as far as I know).

The task to at least try my attempt, is so simple, trivial, banal.
For a first try, you (or developer) could just copy the MCU component (the one where i need a SDK for) and change only the Header syntax.
That is, take my posted C4 sysex and exchange it with every sysex of the MCU component that adresses the realworld MCU units.
How this sysex string looks, is the first sysex of the Logic Manual on page 239.
So instead of 10 (MCU) or 11 (XT), you put 06 (C4) there. Thats all. So easy is this. You do not need a book to write or a complete new component.
I simply want a dummy component (that is just a copy of MCU component, with very, very minor changes) for the C4 as a start.

@Martin.Jirsak

I didn’t know, Mackie stopped the support of C4 with firmware 3.0. Then I’m 100% sure no developer in Steinberg would spent a time to implemented it. It doesn’t make sense to implement something, what is outdated and not supported anymore.

If someone else would like to implement this to Cubase, he couldn’t use just the already established devices. He would need to make a new component (by using SDK – Steinberg Developer Kit) to Cubase. This component could talk to Quick Controls and ask for the name of the parameter (which is not sent over via MIDI), then the parameter name and the current value could be displayed on the C4 displays. You can’t ask Cubase for these data by using just MIDI.

Again, you are wrong and it does not help anyone here. I am not interested in that kind of beef and absolutely do not want to debate with you, if it is useless or not to support things or not. I want solutions and i am a 100% solution-oriented man.
I live in Hamburg, i can literaly sit on my bike and be in less than 5 minutes @ the Steinberg department. I can bring my C4 for further development testing and even pay (with cash) a work-day, if someone there just spend time to try this.
But before i really do that, i want to be prepared the best and most possible. So that no time is wasted on stupid things. I need to write a good schedule, of what someone can do in a day. I need to test every possibility i can do, on my own before i go to Steinberg.
That is what this thread is about. Test and proof what goes and what goes not. I think i got very far and can now say, that i nearly understand the whole concept behind the MCU protocol.

@Martin.Jirsak

Btw

@u-man

You can only use one C4 in a full blown setup. The Logic manual says that the MCU protocol can not handle more. This is a indication that the MCU protocol handles all communication: MCU+XT+C4 everything is inside the protocol

This is just the way, how did Apple (magic in that time in the past) implemented it. There wouldn’t be a problem to handle it different way. It’s just another MIDI device.

Just for your info, I have just tried to use 5 MCU devices to control up to 40 tracks at once. It does work.

And btw, sorry for my English, it’s my second language. I don’t want to be impolite, maybe sometimes my wording is wrong just because of my poor language knowledge. I’m sorry for that.

Just for your info, you did not use a single C4, only MCU in your setup.
One C4 is = four MCU/XT just in faders and display.
Just for your info, we talk about a time (2000), where any PC had a single CPU core (two at most). ONE CORE of a today CPU and with much less instructions, 32bit and 4GB RAM max. So if they wrote that, then it is absolutely true to standards at that time and the reason why they did not put much more into the MCU protocol and the reason why you can not use two C4.
Why are you arguing with me like that? I just wanted to show (according to a manual), that everything is handled by the MCU protocol and you answer me that you can control 40faders with it… !!!
I showed you, that the MCU protocol work partly on a C4 and that it can properly program the encoders of a C4 on-the-fly and you answer me, that this is just luck.
How can this be luck? Tell me? We all know now, that the C4 encoders can not do a thing, if the C4 is just powered on. You can not even get them to work with Generic Remote. If it would be just luck, only the encoders would work, nothing else. Still everything worked, except no display (for obvious reasons that i explained before).
This is quite dissapointing and delivers no motivation. If you have really implemented MCU communication in several softwares, you could be giving me way better answers than this. I researched a lot here and you do not respect that or help me seriously on that matter.

[Martin.Jirsak]

Hi,

Thank you for the video. Very nice integration!

OK, it seems, I’m wrong and the MCU protocol/communication is part of C4.

[u-man]

Hello again,
I did sign for the developer kit of Cubase. I think i did not understand, what you really meant as you wrote this and after reading your post again, i need to ask you again, just to be sure.

From how I understand you now, you would suggest to create a VST plugin, that makes readouts for parameters etc. and pass that to the displays of the C4, am i right with this? Yes, maybe that would work, but i think this is way more work, because i meant something different .
I would like to create a component for the Studio Setup in Cubase. If you have a piece of hardware, that Cubase does not support, then you (as normal user) has only the Generic Remote as a option to add your hardware. I want to create a C4 device, like MCU, HUI, 01v96 etc.
From what i can see, the SDK is only for VST plugins.

Even if i start with a VST plugin, i would not know how to adress the C4 displays, because the C4 is not present in the Studio Setup and then how will you adress something, that is non existing for the System/Cubase DAW??

I need someone, who can create such a component (not VST) and to keep the work as low as possible, he would take the MCU component, change minor things in it and rename it to C4. We first need to create a device, not a plugin. Feel free to ask, if you do not understand something .

MCU from the Studio Setup Menu is a device. This not the MCU protocol. It should not be. The protocol would be inside Cubase-machinecode. No normal user should see the protocol.
For Cubase the C4 is not a device. It is a undefined object/device that is how a Cubase system sees it. We need to tell Cubase, that there is a new device (C4) and a option to choose this device from the Studio Setup settings menue.

Tommorow i will get a MCU from a friend, so i can better test the C4 and see what will happen in other DAWs.

[Martin.Jirsak]

Hi,

@u-man

From how I understand you now, you would suggest to create a VST plugin, that makes readouts for parameters etc. and pass that to the displays of the C4, am i right with this?

No, I didn’t say VST plug-in. I said a component. So the device will show up in the Studio Setup.

@u-man

I would like to create a component for the Studio Setup in Cubase.

This is what I said…

@u-man

I need someone, who can create such a component (not VST) and to keep the work as low as possible, he would take the MCU component, change minor things in it and rename it to C4. We first need to create a device, not a plugin. Feel free to ask, if you do not understand something .

Sorry, then it’s Steinberg SKI. I alway mix them up.

[cubace]

@u-man

For a first try, you (or developer) could just copy the MCU component (the one where i need a SDK for) and change only the Header syntax.
That is, take my posted C4 sysex and exchange it with every sysex of the MCU component that adresses the realworld MCU units.

I is likely that the MCU component is provided by mackie in some form. It might be a spec or it might be code. However it is probably under some NDA.

[cubace]

@u-man

I need someone, who can create such a component (not VST) and to keep the work as low as possible, he would take the MCU component, change minor things in it and rename it to C4. We first need to create a device, not a plugin. Feel free to ask, if you do not understand something .

You need the source code to do that. Or reverse engineer it, and that is expensive. And to do something that MCU can not do you need the Remote SDK. You wont get that without a NDA. Somewere read that you also need to be a manufacture of the device you going to write the component for. It is quite clear that Steinberg/Yamaha does not want it to be open.

[u-man]

@Martin.Jirsak

Hi,

@u-man

From how I understand you now, you would suggest to create a VST plugin, that makes readouts for parameters etc. and pass that to the displays of the C4, am i right with this?

No, I didn’t say VST plug-in. I said a component. So the device will show up in the Studio Setup.

@u-man

I would like to create a component for the Studio Setup in Cubase.

This is what I said…

@u-man

I need someone, who can create such a component (not VST) and to keep the work as low as possible, he would take the MCU component, change minor things in it and rename it to C4. We first need to create a device, not a plugin. Feel free to ask, if you do not understand something .

Sorry, then it’s Steinberg SKI. I alway mix them up.

Ok, we both agree and understand the same . But even SKI is wrong, because that is for ipads or other wireless remote devices.
As far as i looked, i did not find anything, that helps me (or a developer) to create such a component. Correct me, if i am wrong here.
I checked all your recommendations, but none of them provide component creation.

[u-man]

@cubace

@u-man

I need someone, who can create such a component (not VST) and to keep the work as low as possible, he would take the MCU component, change minor things in it and rename it to C4. We first need to create a device, not a plugin. Feel free to ask, if you do not understand something .

You need the source code to do that. Or reverse engineer it, and that is expensive. And to do something that MCU can not do you need the Remote SDK. You wont get that without a NDA. Somewere read that you also need to be a manufacture of the device you going to write the component for. It is quite clear that Steinberg/Yamaha does not want it to be open.

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 .

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.

[cubace]

@u-man

@cubace

@u-man

I need someone, who can create such a component (not VST) and to keep the work as low as possible, he would take the MCU component, change minor things in it and rename it to C4. We first need to create a device, not a plugin. Feel free to ask, if you do not understand something .

You need the source code to do that. Or reverse engineer it, and that is expensive. And to do something that MCU can not do you need the Remote SDK. You wont get that without a NDA. Somewere read that you also need to be a manufacture of the device you going to write the component for. It is quite clear that Steinberg/Yamaha does not want it to be open.

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 .

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.

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

[cubace]

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)

[u-man]

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.

[u-man]

@cubace

(This is also a good indication on that it is Steinberg that has written the MCU driver)

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).

[cubace]

@u-man

@cubace

(This is also a good indication on that it is Steinberg that has written the MCU driver)

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.

[cubace]

@u-man

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.

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?

[u-man]

@cubace

@u-man

@cubace

(This is also a good indication on that it is Steinberg that has written the MCU driver)

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 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.

@cubace

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?

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.

[cubace]

@u-man

@cubace

@u-man

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 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.

@cubace

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?

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.

[u-man]

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.

[cubace]

@u-man

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?

[u-man]

It works for both, but i have a C4 pro

[cubace]

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
https://www.thomann.de/se/iconnectivity_mioxm.htm. 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.