Some times you need to help yourself.
C4 Commander DOES send MIDI messages out, itâs how i traced them previously - it does it in realtime as you change the displays and controller values. You donât need to view the binary of the app to see the resulting MIDI data it produces, youâre just being silly making such statements.
As for getting C4 support in Cubase, itâs not going to happen sadly. Partly because thereâs probably some kind of long standing licensing/legal issue with using the protocol within your DAW, and god knows who owns the right for that. So even if you went to Steinberg and offered to do it for them, signing NDAâs etc. i donât know if theyâd know the right people, or be willing to spend the time to look into the legalities of it. As soon as you go knocking someone wants paying in this world. 
Itâs a shame controller support isnât more open source - it would really add to Cubaseâs appeal, and youâd hope quite feasible for them to write a layer in that the community could connect to, and all they need to do is maintain that layer with future updates. They wouldnât even have to concern themselves beyond that with the detail of each specific controller.
Of course, that already exists in an SDK somewhere - would be great to have a look at that, but have no way of knowing how/where to find it.
One idea to get a C4 to work in cubase is to write a EuCon driver for it. Im not sure what policy avid has about that. I know that they are quite relaxed about using Avid controllers in software with SDKâs. Doing the opposite is most likely very much harder. From an engineering view it is technically possible, but economically very stupid. Much cheaper to buy one from Avid.
I thought Avid were worse, and required a piece of licensed software to unlock your hardware for use and everything had to authenticate with that?
Iâve never used Avid hardware though, so this is maybe sheer ignorance on my part based on one article iâve read in the past! 
In all honesty, the easiest way to get a C4 running is to create 4 instances of an MCU in cubase, and then used a midi transformer tool to convert the 4 virtual MIDI ports and translate the data going in and out on those virtual ports based on the single C4 connection. Then you could filter the SysEx to go to the 4 displays/controls of the C4.
Itâs very much doable as Cubase spreads multiple Mackie instances across devices, something like BOME midi translator would make it much simpler too.
Edit: Looks like someone had a try before, but canât see if they got anywhere.
https://www.bome.com/forums/viewtopic.php?t=11988
Im not sure where avid is as a company. They did a lot of own controllers I think. But they bought EuCon that seems to have a different mindset. The ones I have tried are good. A totally different class than Icon, Beheringer or Steinberg. But still it is only a box with knobs and leds. For cubase users, it is Steinberg that is the limitation not the hardware, but that is also true for the much much cheaper devices from Icon, Beheringer and Steinberg. (I have never tested Nuage though, some serious knobs there too). But it is all about software, and lot of the design of cubase does not translate well to controllers.
Hi,
Avid controllers are also totally different price range thean Behringer, iCon, Steinberg.
From my point of view, Avid is very pricy. The Artist series feels rather cheap (poor). The only advantage is very good EuCon software. But unfortunately very unstable and unrealable.
Where exactly can you see the limitation on Cubase side, please?
Really? The Artist series is more expensive than Behringer and Icon, but I would say thatâs because of more features and the build quality is much better. The displays and motorized faders are quite a step up from cheaper brands. Iâve never had any stability or reliability problems. What kinds of problems have you had? Which model do you use?
How do you even know which controllers work with Steinberg/Cubase then? Is it -any- eucon? And am i right that if you buy a controller secondhand you may need to buy a license to use the software which controls it?
I know artist controllers work because Iâve used them with Cubase. Iâve never heard of anyone buying a license to use an artist controller with Cubase. But maybe I misunderstand your question?
Hi,
The Artist series feels really cheap to me, I have to say.
I have had lots of troubles with Avid Artist MC Control and Control Mix, working together (on Mac). The connection has been lost quite often. I had to find out the order, in which I have had to switch my computer/controller/Cubase on to make it working. If the connection has been lost, I have had to quit everything and start again from the scratch in that specific order.
The 1st generation of the Touch display on the MC Control was really poor. It was incredibly slow and the display was blinking so much. The 2nd generation was better, but still not fast enough to call it fluent.
And the cap if the faders feels really very, very cheap. Actually even cheaper than some Behringer. So the only one advantage for me has been the great integration to Cubase with loooooots of pages/functions available out of the box.
I did not say that the Commander software does not send MIDI, i mean that would be really hillarious if not. I said, i can not see any messages, where the display (and content/names/label) is involved. I see only CC-messages and one sysex, if you turn on the device, but other than that 
I am sorry if i offended you, but read my post again. My bad, if my english is so bad. I thought you talked about adressing the displays.
And still, it is somehow wrong at the moment you start using .xml files, then the encoders are masked and will send CC depending what is defined in the .xml file. So other than maybe observing how the LED rings works, for what else would be the Commander software good? How they work is described in the Logic manual.
Hope this makes sense to you.
From all what i have learned, the Logic manual is 100% true to midi-specs and implementation. Change the sysex-header from MCU to C4 (the ID) and you can do what is written in the manual. Plus, my latest post regarding adressing the displays and the LED rings for feedback.
Bome MTP: I use it extensively. It is what makes the C4 functional in Cubase. However, even if i like your approach regarding adressing the displays (four MCU, translated with MTP), i do not think it will work. I am currently exactly on this or better the support from Bome. Are you really sure, it can be done this way? I can not even make one display work, let alone all four (with MCU protocol). Again, did you ever make the display work with MCU protocol or is this just a theory from you?
I am nearly done/finished and can use the Commander software with feedback in Cubase. I may try some last attempts with MCU protocol, but it is pointless if the displays does not work. Would be nice, just for the readouts alone, i am not so into that mixing stuff, that does not interest me.
I do not believe that license story either. I believe that Steinberg has a unprofessional team, when it comes to such things like Generic Remote, encoders, CC handling and so on. I believe they hired someone, who wrote the MCU protocol for them. It would make sense, because why we do not have native support for Vpot encoders in the Generic Remote? If they have written the protocol???
This license thing does not make sense at all, because other DAWs support the C4, without having any license issues. This must be a cheap excuse from Steinberg, nothing else.
Otherwise i agree 100% with you. Regarding community, SDK, open source. It is 2020, people use ipads and they keep that $hit closed, since 15 years⌠LMAO
Yes iâve worked on C4 in the past and had displays running fine using our own applications, the trick was to send the correct SysEx message to address the C4 (And not the MCU).
I wish i had a C4 here, or at least a working emulation so i could help you more.
In BOME MTP, my idea is just theory but it should work as you would have the following virtual ports which Cubase SENDS to for each MCU setup:-
Mackie 1 = VIRTUALMIDI1 (VM1),
Mackie 2 = VIRTUALMIDI2 (VM2)
Mackie 3 = VIRTUALMIDI3 (VM3)
Mackie 4 = VIRTUALMIDI4 (VM4)
And you just ensure that device â10â is replaced by â17â on all the incoming SysEXâs, and that row 10 is replaced by 30/31/32/33 respectively for each row.
VM1
Would Convert
F0 00 00 66 10 12 xx xx xx xx xx xx F7
To
F0 00 00 66 17 30 xx xx xx xx xx xx F7
VM2
Would Convert
F0 00 00 66 10 12 xx xx xx xx xx xx F7
To
F0 00 00 66 17 31 xx xx xx xx xx xx F7
VM3
Would Convert
F0 00 00 66 10 12 xx xx xx xx xx xx F7
To
F0 00 00 66 17 32 xx xx xx xx xx xx F7
VM4
Would Convert
F0 00 00 66 10 12 xx xx xx xx xx xx F7
To
F0 00 00 66 17 33 xx xx xx xx xx xx F7
Using MTP you would take those 4 filters, and then pass it to the C4 hardware, and ensure that the MCUâs are placed in the correct 1-4 order in Cubase to get the rows in the correct order. I believe you have to connect the last one first, so you would assign them VM4, VM3, VM2, VM1 etc.
That would be your initial starting point at getting the display to work.
Did you even read my post on page three? That happens if trolls are trolling, with useless comments (cubace, please stay away from here).
That is exactly what i wrote there.
But you can not convert anything from the MCU protocol. The adressing is correct, but there is no content that Cubase sends out. You can put your own ASCII code into the xx xx xx stuff, but not anything MCU related.
There is no F0 00 00 66 10 12 and therefore you can not change a $hit. You can use this approach for the Commander software as a example or your own software, but this will not magically make the displays working with a MCU protocol.
So again, did you ever get the displays working, with MCU protocol?
YES and YES and YES, how many times do i need to tell you?! This must be the third time i said that iâve had display data running via MCU protocol. It was work i was carrying out with a partnership where we were wanting to make generic controllers that supported multiple protocols AND were modular by design (Meaning you could slot in in your own faders/rotaries etc.). The whole project was an impossibility as it became too big for us to support financially, but getting the displays running wasnât hard from memory.
But you can not convert anything from the MCU protocol. The adressing is correct, but there is no content that Cubase sends out. You can put your own ASCII code into the xx xx xx stuff, but not anything MCU related.
Of course, this depends hugely on what mode you have the MCU set in (As controlled via Cubase), i presumed you were referring to being in insert/instrument mode on the MCU so that the display data WAS being sent from Cubase. Once youâre in that state of operation, if Cubase believes itâs sending that display data to 4 different MCUâs you can filter it to display onto the 4 rows of the C4 by manipulating the data because Cubase wonât mirror, but it will spread across. Therefore when you page through them it will jump ([NumberOfDevices]*8) too.
Sadly i only have an MCU, and no C4 - otherwise iâd do something in practise and send you the results. I cannot confirm my own theory if i have no way of testing it⌠But it should be quite easy to create a few virtual MIDI ports and filter SysEx to each as a test and pass on to a real MIDI port.
If it doesnât work, and youâre out of ideas then itâs a dead end project and you can see why so many others have failed in the past.
I am sorry if i ask you the same that often. I have already a setup like you describe (build in MTP and setup in Cubase), but the displays are still blank. I admit that i did not include the sysex filter, because i never saw a incoming sysex.
You need to see it from my POV. I have only a C4, never owned a MCU or have any similar hardware that supports MCU.
So, i can not really tell you, in what âmodeâ i am. Not from just rotating, pushing, clicking blind in the woods with blank screens, i never saw a sysex with the midi-monitor. Maybe i just had not enough luck, to enter a different mode 
Just from observing midi-monitor and Cubase, this is what i have found out:
If second row encoders are pushed/pressed, then the 1st button (from left) is for routing, the 3rd button for pan, the 5th button for EQ bands, 6th button for channel strip. All reflected on third row rings. Other buttons from second row do something, but i do not know what.
Never saw a sysex here
And yes, i know that Cubase spreads across. Anything that has more than one page, would be extended to the displays of a C4. That is how the C4 works in other DAWs too, with one exception that is if you use it in standalone mode (no MCU).
I do not see it currently as a dead end, it is quite the opposite. It might be the dead end for that damn MCU protocol, but otherwise the C4 is working more and more nicely. To be honest, the Commander software + MTP solution is superior to that damn MCU protocol. The only thing that is of interest for me, are the readouts of parameter-names. The rest is not relevant to me. Maybe, if i could see it in action, i will change my opinion. Right now, i can label, i have feedback, i can arrange how i want and can have dozens of dozens pages and mixing rows with VST support and real hardware synths.
Can you do that with the strict MCU protocol? I guess not 
.
Well the most fundamental is there is do distinction on how to add things and what it then should imply. This is a common problem for all remotes. Avid has even added a dedicated button for it called multi-select shift. So when you select that its should add the section to what ever is selected. Like keyboard cmd + select on does on mcu if your mouse is pointing at the right window, so if you dont look at your cubase screen cmd-select is random behaviour. However on EuCon select-shift does nothing, neither does keyboard shift do multi selection. The funny thing is there is a cmd key in EuCon, when that is pressed multi-select works on MCU (if the mouse points at certain window.) And then we have mixing fundamentals that relay on multi-selection. Group, folders, VCA etc it falls apart without that.
Right ok, so that puts you at a disadvantage then. Thereâs many modes of operation for a basic MCU and they require button pushes in addition to the V Pot controls. i.e. http://download.steinberg.net/downloads_software/documentation/Remote_Control_Devices.pdf
Page 7 of the manual, you can see the âinstrumentâ and âPlug-insâ buttons on the MCU, you would need to send that data to put the MCU protocol into the mode to control either instrument or plugin for that track, for example. (Presuming you have Cubase set to the same mode as per this doc)
Just from observing midi-monitor and Cubase, this is what i have found out:
If second row encoders are pushed/pressed, then the 1st button (from left) is for routing, the 3rd button for pan, the 5th button for EQ bands, 6th button for channel strip. All reflected on third row rings. Other buttons from second row do something, but i do not know what.
Never saw a sysex here >
No, you wonât see any sysex data for those controls coming in to Cubase as theyâre basic MIDI CC or note on type messages.
You need to monitor the data COMING OUT of cubase to capture the SysEx stream which is being sent. Whether you do this via software that can spy on software ports OR create a virtual set of MIDI connections to route through to do it (And pass on) is up to you. But if youâre capturing the output stream thatâs where the SysEx data appears.
The rest is not relevant to me. Maybe, if i could see it in action, i will change my opinion. Right now, i can label, i have feedback, i can arrange how i want and can have dozens of dozens pages and mixing rows with VST support and real hardware synths.
Can you do that with the strict MCU protocol? I guess not >
You can do a lot with MCU protocol, as itâs all software driven. Itâs the standard that everyone chooses to use that limits it, that and the lack of any progression over the years.
Thereâs a guy working on a CSI project for REAPER, it may be worth giving that project a look at as he knows the Mackie protocol pretty well and shows how useable it is:-
Also, i read last night that there is a C4 emulator on Lemur or OSC for the ipad, so if i get a moment i may try and get that running and try to help you more.
Ok, if i understand you right, i need to emulate the assignment button âPlug-Insâ and/or the âInstrumentâ button (left from the âMasterâ button), to engage into a different mode and then Cubase/MCU protocol starts sending a sysex, is this correct?
What I do not understand exactly is what you mean with this part of your post:
âPresuming you have Cubase set to the same mode as per this doc.â
You need to monitor the data COMING OUT of cubase to capture the SysEx stream which is being sent. Whether you do this via software that can spy on software ports OR create a virtual set of MIDI connections to route through to do it (And pass on) is up to you. But if youâre capturing the output stream thatâs where the SysEx data appears.
Well, thats what i did. Anything else would not make much sense (for sniffing). I observed the IN and OUT from the C4 or the virtual cable(s). I used Midi-OX (on start of this project) and Bome MTP (currently) for that purpose.
Must be really bad luck, that i never saw a sysex coming out from Cubase 
Thereâs a guy working on a CSI project for REAPER, it may be worth giving that project a look at as he knows the Mackie protocol pretty well and shows how useable it is:-
Control Surface Integration (CSI) Technical Feature Discussion - Page 234 - Cockos Incorporated ForumsAlso, i read last night that there is a C4 emulator on Lemur or OSC for the ipad, so if i get a moment i may try and get that running and try to help you more.
First, thanks for the links. Still, this is nothing new to me. I did a huge amount of research regarding this project, to a degree where my closest friends started asking me, if i am ok 
. I talked already with many developers from other DAWs and there was indeed a lot of help, but at the end of the day, it is understandable that most of them will not invest any of their time to make C4 support available to Steinberg/Cubase. It is a rival product.
I must admit, that i did not talked to Geoff (because of the reasons i wrote before), but i read most of the threads there regarding the C4.
I also was on the Lemur page, seeing that C4 emulator. I think you mean this: https://liine.net/en/community/user-library/view/448/
I have problems with forum-registering there. It seems, there is no one who can activate my account for the forums (for weeks!).
By any means, if that panel can help you (and me). Give it a go.
I am truly thankful for your help. I wish i could share a couple of beers with you. Although funny fact, that the approach is nearly the same, to get the C4 working (at least, i liked that).
I might can borrow a Mackie Control from a friend. Before it was not clear enough for me, that i might really need that (just for the sysex-messages alone, i will need that thing).
Till the end of the week, i will try to make a more comprehensive guide regarding the C4 and this topic (pdf with about 15 pages).
I thought it would be quite easy to convert the sysex with Bome MTP, but it seems that i am not able to create a rule/translator that split the sysex into two parts (or more). Only relevant is the ID part and the adress number for the displays (basically four numbers). I can not find a way, that only these numbers are converted. If you have some elegant way to do this or know a good way for a global rule or something like this, please tell me how.
Right now, it seems i need to catch every single sysex that might be send from Cubase and i guess, there will be a lot, once i am in that mode, that the displays start working.
Again, many thanks so far.
No, Cubase will send SysEx feed the display as required. But to use the C4 to control plugin or instrument parameters you will need to send those buttons, which is why i made special mention to them. If you used an MCU it would become quite clear how it all works and how you could possibly embark on finding a solution outside of getting Steinberg to write a C4 extension.
What I do not understand exactly is what you mean with this part of your post:
âPresuming you have Cubase set to the same mode as per this doc.â
Sorry, thereâs two modes of operation for MCU in Cubase, i canât remember what theyâre called from the top of my head (Compatibility i think is one of them). You have to be mindful of this as it can alter the selections on the device itself depending on which mode youâre running, so pick the newer mode which is called Cubase/Nuendo.
Well, thats what i did. Anything else would not make much sense (for sniffing). I observed the IN and OUT from the C4 or the virtual cable(s). I used Midi-OX (on start of this project) and Bome MTP (currently) for that purpose.
Must be really bad luck, that i never saw a sysex coming out from Cubase >
Yes thatâs really bad luck as i just checked myself with my MCU connected and the SysEx data is clearly being sent. Make sure youâre not filtering anything out and you are monitoring the correct ports. But obviously, you donât need me to tell you that. What OS and Midi Monitor are you using?
I thought it would be quite easy to convert the sysex with Bome MTP, but it seems that i am not able to create a rule/translator that split the sysex into two parts (or more). Only relevant is the ID part and the adress number for the displays (basically four numbers). I can not find a way, that only these numbers are converted. If you have some elegant way to do this or know a good way for a global rule or something like this, please tell me how.
Iâve not used the modern versions of Bome MTP but i do use something called âPXT Generalâ by Native Kontrol which can convert DAW MCU transmissions to an Ableton Push 1 controller, and it uses the MT Player for that transcript. So, i know for sure that MTP is capable of carrying out such tasks including display manipulations. And this was running maybe 5+ years ago? so was probably created using the âclassicâ version of MTP?
Ok, i think i did understand that. I will try to get that MCU of my friend. I gave up on the idea that Steinberg will do anything.
Sorry, thereâs two modes of operation for MCU in Cubase, i canât remember what theyâre called from the top of my head (Compatibility i think is one of them). You have to be mindful of this as it can alter the selections on the device itself depending on which mode youâre running, so pick the newer mode which is called Cubase/Nuendo.
Ok. Checked, that is page 6 from your link. Will check that, as soon as i can sit in front of my setup again.
This reminds me also on that thing, that if you turn on a real MCU and press the select buttons 1+2, that there also modes (on the device) that are selectable. Do i need that too? Because if i need that, how would i make that possible, once i return the MCU to my friend again
Yes thatâs really bad luck as i just checked myself with my MCU connected and the SysEx data is clearly being sent. Make sure youâre not filtering anything out and you are monitoring the correct ports. But obviously, you donât need me to tell you that. What OS and Midi Monitor are you using?
OS: Windows 10 64bit
Cubase Pro 10.0.6
Monitoring: I used Midi-OX (on start of this project) and Bome MTP (currently) for that purpose.
If there would be any filtering accidently on, i would not see the sysex while turning on the C4 or while turning on Commander software (as a another example). I checked more than once, that in the Cubase program preferences, the midi filtering is unchecked for sysex. Other than that, where would you look at in Cubase?
I really do not know, why the hell i am not seeing any other sysex messages from the protocol
The only big difference i see is, you have a unit that is supposed to work with the MCU protocol and i try to fool that protocol.
Maybe it is this on page 240 from the Logic manual: Apple Logic Pro 7.2.1 Dedicated Control Surface Support User Manual 7: (Manual) Logic7 Cntrl Info
Iâve not used the modern versions of Bome MTP but i do use something called âPXT Generalâ by Native Kontrol which can convert DAW MCU transmissions to an Ableton Push 1 controller, and it uses the MT Player for that transcript. So, i know for sure that MTP is capable of carrying out such tasks including display manipulations. And this was running maybe 5+ years ago? so was probably created using the âclassicâ version of MTP?
I am not questioning that MTP can do this task, but it will be many, many rules and not a single global rule. To make that possible, it will require a lot of work, to catch any possible case, where the MCU protocol sends out sysex. I can not find a way, to make it as easy, as the examples you and me wrote here before. Hope that makes clear, where my problem is, with this task.
So what looks easy here:
F0 00 00 66 10 12 xx xx xx xx xx xx F7
To
F0 00 00 66 17 30 xx xx xx xx xx xx F7
Will be by far not easy with MTP or I (and Bome support) are thinking fundamentely wrong here.
There is no option for âChange only the bold numbers.â