Do you even own a C4, surely you know what the commander is?
I’m saying that the C4 Commander software sends the SysEx, it’s that datastream being sent to the C4 which you capture using tools like MIDI-OX etc. Very simple to reverse engineer each row addresses.
Hi,
I don’t own C4, but I would also expect (0x13) for the 2nd display row or something really simple here.
Thanks, Martin.
Gives the impression of being reverse engineered from a midi monitor of sorts, but good stuff. Also great info on the display.
OK, after further research, i want to apologize to anyone here for making some mistakes. I talked with very nice and friendly developers from the Cakewalk/Sonar forum, regarding their support of the C4 and how they managed this.
From what they told me is, that Mackie really only provided the stuff from the Logic manual. So everytime i wrote here about the MCU protocol, we can be sure that this indeed was written by Steinberg, i apologize again. This is very bad from Mackie regarding the support of their own hardware. On the other hand, other DAW developers could create their own MCU protocols too and it was no witchcraft.
Cakewalk developers told me, that the C4 needs a own protocol, but it is not much different from MCU.
To solve the display stuff. It does not help to send sysex stuff, just to see something on a display. What we want, are the readouts from the DAW and displaying that. I am not interested in writing “Hello” on the displays of a C4. I hope that this is somehow clear now.
If you want to see, how that may look like, you can go here: Cakewalk-Control-Surface-SDK/Surfaces/MackieControl at master · Cakewalk/Cakewalk-Control-Surface-SDK · GitHub
As you see, this is open source and with SDK and because of that, someone has even written a very nice program, where you can also arrange the ordering of the parameters (from DAW) and how they will look like on the C4 displays. They do not offer only that, the C4 is also very well documented. If you look into the sources of the C4 protocol, you will see that this is not too much code (as i guessed). All displays of a C4 needs to be defined and therefore you can send sysex how you want, but the displays of a C4 will stay blank, because inside of the Steinberg protocol no displays of a C4 are defined.
This is a major difference to Steinberg. I have no hope, that Steinberg will open this protocol or give users a SDK in that regard. Since this is kind of never happening, it will be a DEAD END or someone really needs to start from scratch and that will be indeed a huge amount of work.
We need to use a Generic Remote that does not work properly and that since a decade. I can understand that Steinberg did not want to write the protocol for the C4, but i do not understand, why they did not include proper encoder settings for the Generic Remote, so that people could try their own stuff. Since Steinberg has full support for Mackie Control written by themselves, why they did not include the encoder settings for Generic Remote at least?
We are talking here about code, that was written 15 years ago, but Steinberg still keep that protocol closed. That is simply bullshit.
The only one who is screwed and raped here, are the users and owners of C4 hardware. The politics on that topic are very bad handled by Steinberg.
Steinberg is not open minded enough and have no trust and faith in their own customers. Someone would have written support for a C4 long time ago, but not with such politics.
While you have their attention, Could you ask those developers what part of the sysex string changes to address the 4 different displays?
In regards to Steinberg supporting it, remember that they fail to even update their own controllers very well (CC121 etc) so I’d have no hope on any future mackie updates in Cubase.
Its a real shame they don’t involve the community for control surface support.
According to the DAW developers of Cakewalk/Sonar, this is what they said to me:
“The displays are controlled sending binary information encapsulated within the MIDI messages, and it’s different between the MCU and the C4, which is why you don’t see anything on the displays of a C4.”
How they adress this, can be read here: Cakewalk-Control-Surface-SDK/MackieControlC4TxDisplay.cpp at master · Cakewalk/Cakewalk-Control-Surface-SDK · GitHub
This is not all and there is more regarding the displays (you need to look in the other C4 code as well, to fully understand my link), but basically that is how they have done it.
And yes, i gave up any hopes regarding Steinberg. This will not happen. I will test Sonar the whole next week and decide, if i want to stay with Cubase. Probably not, as Cubase smells like a dead horse. They do not realize that we live in 2020 now and that many things have changed meanwhile. Also hardware is way more common then in 2005. People are sick of mouse clicking and staring at screens. They can rely on these politics, but it will break their neck if they think, that this is enough. I see DAWs at a fraction of a price that Cubase is charging and offering way more control of how i want to use my hardware. Thank God, that i did not spend 1300€ for the C4.
End of Life for a product or not. If you only support current hardware, you are lousy and a noob. We once had wonderful device panels for many, many hardware-synths… it is all gone. But we have VST3 … yeah. 
There will be a payback for this kind of behaviour towards their own customers. Believe it or not.
Mackie for sure would have got a SDK license for cubase if they liked. If they had put some efforts to it it would not have been a discontinued product today. We would have got a USB version for sure. They were marked leaders, they could have been in euphonix position if they had continued and developed their solutions.
This does not change anything what is said before. Both companys did a very bad job… easy as that.
You can be here like a fan boy, buy that euphoria stuff like you want.
I will not spend or invest a single cent anymore into this End of Life product called Cubase.
Like i said, if you can only support new hardware then you have no skill and no respect to your own customers.
Other DAW developers did not have no support from Mackie too. In case of Sonar/Cakewalk you have full freedom, to do your own stuff.
Cubase is a big monstrum and wants to be everything. I do not need notation or logic editors, that i did not use in 20years, but it is nice how the menues all get cluttered, messed up with those things. When it gets important to connect your hardware, you are troubled with a Generic Remote that is so old, i could start with Atari ST Cubase and would have more options.
After some time I finally found out, how ALL displays of a C4 can be properly adressed. The problem is still the MCU protocol. There is no way that i know, how a user could change that. You can not “grab/catch” the display info from the MCU protocol and change it to a way, that it uses the C4 displays.
All of that, because the protocol is not open.
Here is how it works: A MCU unit has only a single display. The example in the Logic manual shows:
F0 00 00 66 10 12 00 48 65 6C 6C 6F F7
for writing “Hello” in the top left in the display of a MCU unit. Of course, this example is for a MCU not a C4. It still works on the 1st display of a C4 by changing the sysex header to a C4 accordingly to:
F0 00 00 66 17 12 00 48 65 6C 6C 6F F7
but you can do what you want, it will not work on the other three displays.
If i change that to:
F0 00 00 66 17 30 00 48 65 6C 6C 6F F7
it writes again “Hello” in the top left corner on the display of the first row encoders (same like before).
If i change that to:
F0 00 00 66 17 31 00 48 65 6C 6C 6F F7
it writes “Hello” in the top left corner on the display of the second row encoders.
If i change that to:
F0 00 00 66 17 32 00 48 65 6C 6C 6F F7
it writes “Hello” in the top left corner on the display of the third row encoders.
If i change that to:
F0 00 00 66 17 33 00 48 65 6C 6C 6F F7
it writes “Hello” in the top left corner on the display of the fourth row encoders.
With all that info now, it just needs someone who can change the MCU protocol to do “paging” on the remaining three displays and thats all.
So Martin, what can i do now? For someone who implemented MCU protocol to several other softwares, you may have a solution or at least knows people (maybe at Steinberg) that could further help me. I even have a Character-chart, including all zones (encoder 1-8 labeling/names per row and display) and the needed offsets to label the displays.
I also have the syntax for all LED rings in all four rows of the C4:
B0 20 06 to B0 27 06 creates a centered LED on the ring for the first row encoders.
B0 28 06 to B0 2F 06 creates a centered LED on the ring for the second row encoders.
B0 30 06 to B0 37 06 creates a centered LED on the ring for the third row encoders.
B0 38 06 to B0 3F 06 creates a centered LED on the ring for the fourth row encoders.
Basically everything that is needed, for someone who could implement these things into the existing MCU protocol.
If i could “catch” and change the display adressing of the MCU protocol, i could emulate and adapt the stuff to a C4 on my own. This could be done in a day or two.
Your memories are wrong and nothing is or was super easy to find out. C4 Commander software does not send any messages regarding the displays, unless you have some magic monitor software, that can look into the binary code of the program. Any display info (or basically everything) with the Commander Software is defined with .xml files. The .xml files will not help you in “sniffing” the MCU protocol. The .xml files work only with the Commander software together. You can not use the .xml files for anything else (i.e. with Cubase). If you do not use any .xml file, you do not need the Commander software at all, because the C4 will be in a state, that is equal to “just turned on”.
And if you use a .xml file, you will mask the encoders with whatever is defined in the .xml file, but the MCU protocol expects “unmasked” encoders. So even if you are monitoring the Commander software, you will have very wrong values. The only way to make that work with .xml files, is to mask the encoders, with exactly the same CC-parameters they have before masking (CC 0-31). You will not find such a .xml file, you need to create one on your own. So happy tracing… 
But who knows, proof me that i am wrong. You maybe have a monitor software that is unknown to me 
Tnx for the tech info. However I don’t this was the magic information that open up steinberg to do it. Steinberg want the hardware vendor to do the coding. And Mackie sells hardware so they want the software vendors to do the coding. Steinberg has an API/SDK for it, but they only give it to hardware vendors. If the SDK was open in the same way as VSTSDK you will soon have a C4 driver in gitlab. But as long as Steinberg does not want it to happen it will not happen, or maybe I should say Yamaha. I think Yamaha is far behind western world in adaptation of open source and open communities.
Steinberg has written the protocol, so a employee or developer could do this. I would even pay that person. With all the info i have now, this is a 1-2 day job. I have a SDK, it does not help. Because you are still unable to look into the MCU protocol. It is only good for developing new tools, which in this case, is absolutely NOT neccessary.
What SDK do you have?
The VST SDK. The SDK that people told here, is needed to create components. Sadly you can not look into already finished ones. So only option is starting from scratch, which would be to much work and is unneccessary.
VSTSDK is the interface for writing VST plugins. They both end up in a .dll for windows or .so OSX. But it it does not give you access to the functions needed for a remote component. (Technically it is not access, it is the knowledge on howto interact with the host) Steinberg publish their open source here Steinberg · GitHub. But they have not published the remoteSDK needed for a doing a remote component. They also has a forum for developers of plugins. https://sdk.steinberg.net/
Well, that is what was told to me. 75 posts later, there is still nothing that helped me. All i can say. Everything new what was found out, is my own work.
Tell me something new and positive and i am in.
The people that you need to convince are most likely not reading this thread,
That does not help either.
Why not? I sent you a link to Steinberg development site. Someone there might even have an idea who you need to convince.
But there is of course many options. One might to convince Hans Zimmer that he needs community support for some cool hardware that can only be achieved with open source remote-sdk. Or you could team up with some AI-researcher that needs to practice reverse engineering for their AI-system for code analyse. As some cheaper alternative is to sell your C4 and buy some cool control surface from Avid. It is far more economic solution to buy a high-end of the shelf solution that trying to build one where your obstetrical is legal more than technical. If you value freedom, cubase is not the right tool.
That does not help either.