i recently bought a Mackie C4 and to my suprise i realized that it initially will not work with Cubase. There is simply no remote control preset for it, like for the MCU or Hui. After long research in the web, i did not find any solutions, only people with problems under Cubase.
After many frustrating hours, i did find a way how to use this wonderful controller. I want to share the solution, but also have questions, especially questions that maybe only a developer could answer.
You will need a virtual cable (Midi-Yoke, Loopmidi, Midi Translator Pro) and a Software Midi-Router (Midi OX, Midi Translator Pro).
And you will need the Commander Software that came with the Mackie C4.
It seems that Steinberg developers do not know, how a C4 works. Initially when you just turn on the C4 (proper midi-connection is done etc.), the 32 Encoders are “unmasked”. They are aligned to Midi Controllers 0-31, this is because these controllers are for 14bit. They will produce a value of 1 if turned CW and a value of 65 if turned CCW. You can inspect that behaviour with a Midi-Monitor. Obviously there is something wrong with these values, as you can barely use anything, with such behaviour.
The reason for this is, the encoders need to be defined first and this is done by feeding them with .xml files. A user can do this, by using the Commander software and loading those .xml preset files into the software.
So here is the question: why is there no way for Cubase doing this? Especially if you already have a working MCU protocol???
I mean the Vpots 1-8 from the MCU right under the display, have exactly the same initial alignment, as the third row encoders (Midi Controllers 16-23) from the C4.
Why we do not have at least the same functioning encoders/Vpots 1-8 on a C4?
While i found a way to use the C4 with Cubase, i must say that i am somehow disappointed about the huge potential that is lost on this C4 controller.
Most of the naming and layout of the encoders could be done automatically and on-the-fly by Cubase itself. The MCU protocol for doing this is already there.
I am interested in the Level meters and other fancy things, that you usually could have on the FOUR displays of a C4.
Even Propellerheads Reason, has a C4 remote device, that you can import and use right away.
I am disappointed that i need to run two programs in the background, just to get the Mackie C4 running in Cubase.
I attached the common midi controller .xml , so that a developer knows, what is need to get the C4 encoders properly working.
I would be happy for some serious answers here. I am willing to help as best as i can. midi_controllers.zip (1.75 KB)
Mackie C4 is not Steinberg product. If a hardware manufacturer creates a specific hardware, the manufacturer should provide a solution, how this specific hardware should communicate with other software/hardware/existing world. For C4 very specific is, it doesn’t send a really values of the knobs. The knobs are just sending increment/decrement data. Nothing more. So Mackie should provide a communication protocol, how to link this with the rest of the world, which is using concrete values (not inc/dec only).
Mackie Control protocol has not been made by Steinberg. MCU protocol is Mackie protocol. So again, it’s on the Mackie side, to provide a protocol for C4.
If you would assign the very same MIDI CCs to the knobs on your C4, which has been send from the MCU, you would get the very same functionality.
Let me just say, you would have the very same results with any other DAWs. The protocol is just missing from Mackie. I have never understood, why C4 is sending just inc/dec values and there is no communication protocol for it.
first thanks for the reply. I am happy to see someone experienced like you.
Ok, i understand that this is not a Steinberg product, but do not you think, that some things even if they are not a Steinberg product can add great value to Cubase? Especially if nearly every other DAW can support it?
I already wrote why the encoders initially behave like this. This is really by design. With a C4 a user is able, to use it as a controller/programmer for nearly everything, be it hard or software. This is what makes the C4 really outstanding and there are only very few controllers left, that can do the same. Really, the only one downside of a C4 is, that it only works with a computer.
Initially the encoders are aligned to Midi-Controllers 0-31, these Midi-Controllers are reserved for 14bit values. This way it is guaranteed to program/“mask” the encoders like you want, be it 7bit, 14bit, sysex etc. without having any hussle. This is also something that is impossible to be done with “concrete values”, like sadly the rest of the world do. They are digital 14-bit encoders and therefore it is not dumb to assign them initially to Midi-Controllers 0-31 as there are 32 encoders.
I think that the midi-monitor is not showing the real values, that a encoder sends. My guess is, it is 14bit data and the midi-monitor just reads it as a 7bit value. Anyway, the encoders first need a “mask” through those .xml definitions. That is why i attached the midi-Controllers.xml to my last post. This .xml file IN FACT IS the communication protocol for a C4. There is nothing more needed for basic operations IMHO, at least not for Cubase or any other DAW. This and a virtual midi-connection to Cubase and this is only due to the fact for not having a own USB port. If you use a C4 with a MCU together, you maybe do not even need the virtual midi-connection.
That is what my step-by-step guide is exactly doing in the link of my first post.
If i would know how Cubase is setting up (remote) controllers and i mean the ones that exist and are in a ready-to-go state including display readouts for Cubase, i would try to make that myself.
The Mackie Commander software does not do much, it just feeds the C4 with the .xml definitions. All other stuff is of cosmetic and layout nature and is absolutely not relevant. This software does not do any (inside) magic with the .xml definitions. It is a very basic program written in JUCE.
No one can tell me, that Steinberg devs would need a huge time to implement the same “import .xml” feature inside Cubase, which in turn gives us instant a functioning C4 (that is 32 LCD labeled encoders that transmit CONCRETE VALUES).
Steinberg would also benefit in two ways. First they would attract people that have a C4 and second every Mac user with a C4 would cherish Steinberg, making a otherwise obsolete product great again (10.8 OS X is last, where Commander software worked).
I could assign the very same MIDI CCs to the knobs on my C4, if i would know, how the Vpots 1-8 are “masked” in the MCU protocoll. This MCU protocoll must be somewhere deep inside the trillions Cubase-paths on a computer and hopefully it is somehow readable for a “normal” user.
Although all kind of display-communication for the Vpots 1-8 must be in that MCU protocoll too and this is something that is essential and what you can not simply “assign” by CC-learn. In fact this just shows, how powerful this encoders can be programmed, as each encoder has a own LCD with 2 rows and 5-6 digits + assignable useful things like Db-Meters etc.
From the programmers guide for the C4:
This element represents an individual
mapping from one instrument parameter
to a C4 V-Pot.
The position of the V-Pot being
mapped to. There are 32 V-Pots per page (if
there is no split), so the 33rd V-Pot would be
the upper leftmost V-Pot on page 2. If a mapping
is not present for a given V-Pot, it will not
be functional.
I hope you understand now, why you can not assign “the very same Midi CC” to the C4. This would work for all things that use a simple “on-off” state, anything else, would be just garbage. I attached the programmers guide to this post. It explains very clearly, (but very basic too) the C4 protocoll.
I showed here, that a C4 is useable in Cubase and basically i do not need anymore, it would be just nice to not use 2 programs just for that purpose.
If you ask me, this is worth a sticky thread, as you will not find anything in the whole WWW, which can show you this. Showing that a wonderful piece of hardware, can work in Cubase too.
The thing is, it is a little to huge effort, to label and layout each VST and Plugin for every single encoder, which could be easily done by Cubase itself by simple readouts, that are passed to the displays. This is what annoys me the most. I need to mimic every single sh…t, even if all the information for labeling is there. Ridiculous.
Right now, i am trying to finetune my guide, adding simultanous use of a Generic Remote and CC-Controller in one C4 and finally to create a PDF in english and maybe Steinberg will show us some mercy and include that in the manuals or something like that. C4_Commander_Programmer’s Guide.zip (316 KB)
Nice that you mentioned it, because this is the only thing, i did not get to work. Maybe it is even impossible. I could not find out, how i would do that with the Commander Software. But if it is possible with a MCU (i dont have one), i am pretty sure that there is hope a C4 could do it as well.
Does a MCU have feedback on the Vpots? For example changing pan with mouse and MCU reflects this on the Vpots?
I can not answer this, i dont have one, but i assume this is working.
If you ask me, to get feedback working, we would need to know the “true” initial values of the encoders, because the masking/mapping would need to be reverted to these values again. One thing is sure, you can not do that with only two values (65 and 1), that is why i am very sure that this is false info of the midi-monitor.
Feedback would be perfect, but is not so essential for me. You can activate “pick up” mode for the encoders to compensate this, but yeah it would be nice to have feedback. Then you would have snapshots and total recall that work 100%.
Yes, there is a feedback on the MCU unit. Around every single V-Pot, there are 10 LEDs, which show the value. There are the same LEDs around C4 knobs, so it is possible to show the value too. The tricky part is (at least for MCU) it doesn’t receive the same MIDI Message as they are transmitted (logically, when V-Pots are transmitting inc/dec, but the ring around has to display the real value).
Let us assume the C4 encoders are sending 14-bit data. How would i setup to receive the data with a Generic Remote in Cubase?
How can i tell Cubase, that it receives 14-bit data and use that for example with the Quick Controls?
Because then the C4 feedback (from Cubase) would be 14bit, instead of the currently 7-bit that are used in my how-to-tutorial.
The V-Pots feedback to Mackie Control Unit is 7-bit only. Actually there are only 11 values sent out (Values 27 to 37 & value 86, if the panner is in the centre). For the 8 V-Pots, the feedback has been sent over MIDI Controllers 48-55.
If i use the MCU remote preset (for my C4), it behaves like we assumed: as soon as you move the third row encoders of the C4, they are responding to the pan settings of track 1-8, working right away, with the LED rings and with feedback. They behave like the Vpots 1-8 of a MCU. Sadly any string messages for the LCDs are missing, so it seems that none of the 4 LCDs are initially adressed correctly, but i admit that i need further investigation, like what will happen if i emulate “assignment” buttons of the MCU and so on. Anyway it proofs, that the MCU protocol contains a good part, that also works at least for the third row encoders (16-23) of a C4.
Another thing i found out is, that if you setup a Generic Remote preset and start to assign a encoder from the C4, then there is the pop-up menu on the right, where you can tell if it is sending and/or receiving MIDI and the two other options “relative” and “pick up”.
If you enable “relative”, then the encoder starts working properly, at least for incremental values (1,2,3…15,16,17…123,124 etc.), but the decremental values still behaves like before (-64 for each step instead of -1,-2,-3… -15,-16…-123,-124).
Note: MCU Vpots 1-8 and C4 encoders are relative, because thats what endless rotary knobs use.
So, if we would find a way for the decremental values, we would have the encoders basically working (with concrete values ) and all that, without using any additional software… just Cubase.
To summarize it: what is left to be found out, is the proper handling of the decremental values, the LED rings and finally LCD displays.
AFAIK, we can not do the LED and LCD stuff, just with the Generic Remote stuff that Cubase offers. I do not know how.
For that purpose, i attached a PDF where a smart guy, reverse engineered some parts of the HUI protocol. There are some answers for adressing the displays and LED rings. HUI.zip (128 KB)
As I have implemented MCU communication in several softwares, I feel quite confident in this protocol.
So now you find out, the 3rd row of the encoders is by a good luck sending the very same MIDI CCs as MCU is using for the V-Pots, i.e. MIDI CCs 16-23. My expectation is, that the 1st row is sending MIDI CCs 1-9 and the 2nd row is sending MIDI CCs 10-17.
If the 3rd row would send PitchBend at Channels 1-8, you would control the faders. This is, how MCU is implemented.
How does the Relative Mode works in Cubase is described in the Manual. So if the controller sends value +1, the assigned parameter jumps +1 step (it could be for example +0.01, depending on the unit). If the controller sends +2, the parameter jumps +2. If the encoder sends 127, the parameter jumps -1, if the encoder sends 126, the parameter jumps -2, etc. This is unfortunately not the same as MCU is behaving, so probably your C4 will also behave different. On MCU
+1 of V-Pot = +1 of parameter
+2 of V-Pot = +2 of parameter
+65 of V-Pot = -1 of parameter
+66 of V-Pot = -2 of parameter
This is how does it work with MCU standard.
Regarding the ring, MCU works so that it receives other MIDI messages then the V-pot is sending out (as I mentioned already, MIDI CCs 48-55). For Generic Remote it’s impossible to receive MIDI message A and transmit MIDI Message B.
To show a text at the display, you would need to send SysEx data, what is impossible with Generic Remote Device.
But as far as I understand the C4_Commander_Programmer’s Guide.pdf, it is possible to program the C4 so that it would behave as a common device and sends the exact values. Then you could assign them in Cubase. You could use the pick-up mode to make sure you wouldn’t destroy the values, if you come from other page.
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.
Standalone mode
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.
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: Binding Jump Prevention and Relative (Rotary) Encoder Support - Cantabile - Software for Performing Musicians
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: Two's complement - Wikipedia
“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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
,
) and all that, without using any additional software… just Cubase.
.