Mackie C4 Pro and Cubase

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

Hi,

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

Ok, i have a idea that maybe works.

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.

Hi,

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.

Hi Martin,

here is what i found out recently:

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 :wink: ) 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)

Hi,

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.

Hi Martin :slight_smile: ,

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 :smiley: .
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 :wink: .

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 :wink: 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.
https://usermanual.wiki/Apple/Logic.1909626546
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.

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 :wink:

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 :slight_smile:

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.

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.

Btw

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.

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.

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.

Hi,

Thank you for the video. Very nice integration!

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

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 :wink: .
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. :wink:
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 :slight_smile: .

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.

Hi,

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

This is what I said… :wink:

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

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.

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 :slight_smile: . 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. :wink:

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

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

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

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

Hi cubace,

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

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

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

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

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