Hi Martin ,
first i want to clear some things and want to point out that the main goal of this thread is, to find a proper and correct solution.
My english is bad and i apologize for that and i am really sorry, if you feel offended by my speech.
Second my Midi knowledge is ok, a little more than average IMHO, so i can approach the problem only in a logical way, by inspecting, guessing etc.
Any findouts, decide next decisions and again acting in a logical way is needed. Obviously i will sooner or later come to my limits and need help from someone that is familiar with that stuff. I really want to help and that is why my post now, will be rather long. On the other side, it will contain EVERYTHING a developer needs to know, to support ALL MCU units from this product line, even if you encounter some cynical sidenotes.
Yeah and the fourth row is sending 24-31 .
This for sure was not only a thing of luck. I mean what is a C4? It is mainly a extension to a MCU and i do not think that Mackie decided to use a different way to program/map the C4 encoders. MCU+C4(+XT) is one product line, so i do not think this is just luck and here is why: with this example, i just wanted to successfully proof, that the MCU protocol contain parts that can program/map C4 encoders “on-the-fly”, without any C4 software involved, nothing more .
You have implemented MCU communication in several softwares? You are my man and maybe we can together solve this mystery.
So the MCU+C4(+XT) is one product line and in that regard Mackie did provide anything a developer need, to implement it into a DAW.
The easiest way to do this, is to deliver a DAW independent SINGLE protocol, that works for the entire product line (especially if you want to support many DAWs). The MCU protocol (as a successor of HUI protocol) was born. A DAW developer needs to understand, that this protocol delivers advantages, that no hardware product (based on midi-connection) can offer. You simply can not transmit that amount of data with MIDI and Sysex, let alone give that even more “extensions” and most important keeping the DAW stable and tight at the same time.
Mackie “outsourced” DAW controls, so that as much as possible went into the MCU protocol. Complex routines, that are triggered just by simple Midi-commands. Only then, you can mantain stable performance and have excessive control via a hardware GUI, like the MCU+C4(+XT) product line.
In our case, they not only gave Steinberg the MCU protocol, they also left things open (many user/developer options, in form of unassigned buttons on the hardware product line itself).
You want to use the hardware in your DAW differently? No problem, we will make a different overlay for your DAW. Overlays that match exact those unassigned and “free” buttons (of the whole product line), where a DAW developer can decide, how deep the whole product line is involved into DAW, simply by adding key functions of the DAW itself and Steinberg did by far the laziest job on that, but we will come to that soon.
You seem to miss some important point i previously posted: that the C4 encoders are only working properly (with LEDs and LCD and even feedback) if they are programed/mapped previously (see my C4 programmer guide bold-quote in my #3rd post) . Be it with the C4 software or (to proof my theory and this example) with a protocol that can do this on-the-fly and the MCU is the nearest/closest product to a C4. It turned out that the MCU protocol is partly working and the only thing missing is text display/labeling.
This is neither luck or coincidence, it is rather a logic-al thing, because both products are meant “to play” together. It is obvious, that there must be things in a MCU protocol, that are adressed for a C4 or are working on a C4 too. There must be some handshaking if both products exist in a setup.
The two modes of a C4 and their very important meanings:
The MCU+C4 (or XT+C4) combo mode:
Logic DAW i.e. provided ALL possible options, how to include the C4 in a setup: MCU+C4, C4+XT etc. or Standalone.
Cubase offers me only two options: use the MCU protocoll and “abuse” it on a C4 (as i did in the example and it indeed worked but without display) or Generic Remote, where i loose ALL benefits from the C4 and have nothing more then partly working incremental values, if relative mode is enabled.
Simply said, the DAW need to provide a connection/environment, that establish that the units can see each other. The autoscan process in DAWs with a working C4 support, guarantees that a C4 is found and that you can include it into your setup. In fact, it is the only way how to add it into your setup.
How to do this, is described in full detail inside the “Logic Pro 7.2.1 Dedicated Control Surface Support” manual starting at page 239.
Since the C4 is the oldest product in the MCU product line (and initially was made for Logic) a DAW developer needs to go back that far to know this. Mackie assumed that developers will know this fact. In reality a good amount of DAW developers did understand that concept and implemented that autoscan/handshake protocol in their DAWs to fully support the hardware, just by reading this tutorial.
Inside of the MCU protocol must be a way that handles this case. In fact everything needed for the same function like in Logic, Tracktion, Reaper etc. is to tell the protocol that a C4 is present.
With Cubase you can just add another MCU protocol if you wish to extend the MCU, which is a wrong approach or no full support for people who have a really big Mackie setup like MCU+XT+C4.
Cubase has no options to deliver and show the MCU protocol, how a user wants to build a big Mackie setup.
Cubase, because by accident and pure luck, can use the very same MCU protocol for a XT, sadly this is not working anymore, when a C4 comes into play. No scan, no C4 hence can not work at all. No handshake. Devices do not see each other. End of story.
So till this point, no work of Steinberg is involved, but badly needed to support a C4.
We need a button that starts handshaking, this can only be done by a developer
If you look closely at these extenders, then it is clear that you can expand a MCU (silver unit) to a maximum of three extra units in two ways:
8-24 Fader channel or 8-16 Fader channels with 32 encoders.
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 and for a proper working setup, the protocol needs a way to distuingish the units and here will Cubase start to fail. In a Cubase world, the protocol sees the XT units, but no C4 at all, as there is no autoscan function that could establish a connection and tell the protocol that a C4 is present.
My guide provides at least partially this Standalone-Mode for Cubase, with LCD displays missing for the split-zones that are running through the MCU protocoll. This is still good, because it is the “better” mode (if feedback would work) and here is why: The Standalone mode, offers simply the most flexibility and you have Split-Zones that you can combine with real hardware and this works really well, what i can tell from my experience.
Downside of the Standalone mode (if by any means) is, it works only together with the Commander Software.
In theory and how it works in other DAWs, this means you can use i.e. the first 2rows for MCU protocol and the last 2 rows for your Hardware setup. Many combinations are possible. My current setup supports that too. I can use the Split mode and move the pan encoders from our MCU example. All together with the other 24 encoders (of the C4) that controls hardware (or VST-Quicksettings, like in my guide). These 24 encoders even have labels and text on display, because that is handled by the Commander Software. I just miss the display for our “MCU example” encoders.
Again, this is impossible to do with Cubase alone, as already said, there is no connection to the MCU protocol. My standalone mode works only, because i have a virtual Midi-cable and with that can create a connection from the Commander Software to Cubase, but not to the MCU protocol.
Now you see the dilemma in its full glory.
So what is missing in Cubase then:
My biggest guess is, that the MCU somehow still does not see the C4. The MCU protocoll (that is used/handled in Cubase) need to be informed about this “special” situation.
The C4 is sending this sysex-message, if powered on.
F0 00 00 66 17 01 00 00 00 00 00 00 00 34 31 06 00 F7
The lamp of the F-Function button (of a C4) is lit. It means a C4 is in receive mode. In this mode the C4 encoders can be programmed, but not used.
You end that mode by pressing F-Function again and then the encoders start working according to how they are programmed.
So the C4 literaly waits on a answer of the MCU protocol, after powering on. He is even in receive mode by default.
A successfull handshake with a MCU protocol, will program/map all encoders and buttons of the C4 on-the-fly and after that turn off the receive mode, so that a user can use the C4 right away. That is how Mackie wants to be used.
It would be very nice, if someone with a real MCU (firmware 3.0 prefered) could observe what happens, while receiving such a C4 sysex-message with the MCU.
Also how does a real MCU needs to be configured, do i still need to push the “sel” buttons while powering up the unit, to put it in the different modes? Or does it work in Cubase just by powering up? I maybe need to know this, because i will emulate this (with the Remote SL) , but need to be sure to exclude this options/choices that are maybe the problem. All DAWs that support the C4 use the “Mackie Control” mode.
I abused the Commander software in that way, that i used it for “controlling” Cubase VSTs, but and here is the thing, the software is not made for this and therefore i can not make feedback possible for the C4 encoders that are programmed/mapped with the Commander Software.
Standalone mode offers something that will not work with a MCU+C4 combo mode, because in this mode ALL C4 encoders are programmed/mapped on-the-fly by the MCU protocoll and can only do, what the MCU protocol offers them. Obviously the protocol do not offer mappings for hardware synths/FX. It offers DAW control and therefore this mode is limited to exactly that and all 32 encoders are reserved only for exclusive DAW control and more importantly (for you) as a extension to the MCU(protocol).
The split function in this mode just provides vertical or horizontal alignment of parameters on the displays. So a user have some limited option to layout the GUI (of the MCU extension) to his taste.
Conclusion or what the C4 really is:
A MCU+C4 combination can only work, if it is declared as such in the MCU protocol and that needs to be told by the DAW. Unlike a MCU+XT combo, where you can simply just add another MCU protocol from the Studio-setup Menu in Cubase and that really by luck is enough (a XT is basically a MCU without Transport functions) for working in Cubase .
Cubase is missing this link and currently Cubase has no tool to provide that info to the MCU protocol.
In all DAWs that support the MCU+C4 combo mode (after a successfull autoscan) comes a exclusive C4 setupmenu, where you can choose in which mode you want to use your C4: Combo or Standalone.
A very trivial thing, if you ask me. All it needs (from Steinberg/Cubase), is to tell the MCU protocol, that it is extended with a C4.
Lets say you choose the MCU+C4 combo, then basically the MCU protocol takes control over the C4 and “sees” it like a extension.
In other words, if you only use a MCU, you can only partly see all parameters of a EQ/FX/Instrument as you have only one display.
This is solved through pages, that you scroll with Vpots.
The C4 can extend and display four pages (from the MCU protocol) at once and enhance the GUI experience with 4 labeled displays (with MCU even 5).
How much of a extension, is only based on what you define with the splitzone buttons on a C4. Going from one row, to all four rows of the C4. You can see this in every youtube-video, that shows this MCU+C4 combo. But thats it. If you want more, you need to define it and using unassigned buttons, for more deeper controls of the DAW. Again this is a job for a DAW developer to make that possible.
Yes, i read the remote control manual, but i am afraid that Cubase does not have more support for different modes other then the two mentioned in the manual: absolute and relative. What we (as users) need, is to have more options on this. How a proper encoder support should look like, is shown here: https://www.cantabilesoftware.com/guides/controllerEncoding
A 69$ DAW that gives me three options just for relative mode alone and even with options for rotary scaling (encoder behaves different with acceleration of rotating).
BTT, the encoders in the MCU are not any different from the ones on a C4, but their behaviour is defined in the MCU protocoll.
Cubase offers only one relative mode and that make the encoder only partially working.
Now if you look at my link above, you can see that the developers took care about this problem, it starts even with this headline “Binding Jump Prevention”, because that is what happens with decremental values on a C4 encoder with Generic Remote in relative mode. It jumps to zero if rotating CCW and behaves normally (+1 increment) if rotating CW.
It is very well explained, what Steinberg would need to implement to avoid this problem: https://en.wikipedia.org/wiki/Two’s_complement
“The MCU receives other MIDI messages then the V-pot is sending out” is how the MCU protocol establish feedback with the DAW (aka bi-directional editing). This way it is guaranteed that it is impossible to create a feedback-loop, because that would lead to midi or even system-crash. As i said in my first post: the encoders are aligned to Midi Controllers 0-31, this is because these controllers can use 14bit. Cubase use mainly 7-bit values for many parameters in the DAW.
The MCU protocol use real 14-bit values only on the faders. Other wise it is used just for feedback. 7bit send + 7bit receive = 14bit. You can use this method only on controllers 0-31 and if you use 14bit on one of them, you need a additional CC. In the MCU protocoll this is done with Midi Controllers 32-63. If we use 14bits with Vpots/Midi CCs 16-23, we also use MIDI CCs 48-55. Do you see the relation? Good
If you observe and take a deeper look into the midi-controller.xml file that is attached to my first post, you will see that not all common midi-controller are included. This is to avoid, that the user by accident take a midi-controller to program the encoders with the C4 Commander Software, that is also used by the MCU protocol and again can create a feedback-loop, which needs to be avoided by all means.
Rings, Text, feedback, encoders, faders everything is handled by the MCU protocol. You only need a Sysex message, if you want to show something different/outside of the MCU protocol. We do want that maybe later, but first we want the displays/value readouts from the MCU protocol.
It dont need any Sysex to show something on the display. You do not communicate with the MCU protocol via sysex (if there is no reason), you communicate with Midi Notes and CC 0-127, keyfunctions and assigned buttons. Nothing else. Otherwise the data would be too much for a Midi-Connection.
Well, we come finally to the end. Everything what is needed to make a C4 fully working with the MCU protocol and Cubase is said.
It just need someone, who can create the handshake protocol of what is described in the “Logic Pro 7.2.1 Dedicated Control Surface Support” manual starting at page 239 and the sysex from the C4 is: F0 00 00 66 17 01 00 00 00 00 00 00 00 34 31 06 00 F7
After successful handshaking, create a “shell/dummy/placeholder”, so that a user can choose C4 from the pop-up menu in the Studio setup of Cubase, so that the MCU protocol is aware of a C4.
The developer will need a C4 and in best case a MCU too. A MCU with firmware 3.0 is prefered, because Mackie stopped the support of C4 with firmwares higher than 3.0. At this point i do not know, how much of this belongs even to the MCU protocol, it could be that a actual MCU protocol is aware of that and need a “older” MCU protocol.
So who has the guts here, to make that possible