u-man

Ok. I tried to change F0 00 00 66 10 20 00 01 F7 to F0 00 00 66 17 20 00 00 F7 or F0 00 00 66 17 20 00 02 F7 or F0 00 00 66 17 20 00 04 F7 or F0 00 00 66 17 20 00 06 F7 Sadly still nothing happens. Since i only translated assignment buttons of a MCU so far, i can only enter PAN, EQ, Sends, Inputs, Instruments or FX sections. Do i need to be in another mode to get that right? Or does the level-metering has limits and work only for audio tracks for example? Also i am not sure about the "D0 05" thing you described, as the logic manual does not mention rows at all. I tried that too, to change that to "D1 05" but still there is nothing happening on the C4. Is it possible that some (global) variables need to be done first, before anything can work properly?

Thank you azslow3 for your reply. Yes you are right with the vertical metering. It was my mistake, that i left out the other messages. Off course i have channel meter mode messages (from Cubase) too, they look like this: F0 00 00 66 10 20 00 01 F7 F0 00 00 66 10 20 01 01 F7 F0 00 00 66 10 20 02 01 F7 F0 00 00 66 10 20 03 01 F7 F0 00 00 66 10 20 04 01 F7 F0 00 00 66 10 20 05 01 F7 F0 00 00 66 10 20 06 01 F7 F0 00 00 66 10 20 07 01 F7 I can change the "10" to "17", but it does not make a difference. I also got many Peak-metering data like this: D0 06 D0 05 D0 04 D0 03 D0 02 D0 01 D0 00 and in between those D0 xx messages, i got some of these, where i do not know what they do: BF 40 33 BF 41 20 BF 42 20 BF 43 71 BF 44 20 BF 45 74 It is like you wrote before. There is no C4 documentation. I did not want to sound rude, but i am just not a expert. So looking at source code is like ???? WTF. You can help me way more, if we keep talking in midi-terms. That are things i can understand. So my big problem is, i can invoke/start level metering, but nothing happens on the C4 displays. Since Cakewalk can manage level-metering on a C4, i have the hope to get some clues here, what i need to get this working too. Again thank you both azslow3 and msmcleod for even helping me.

This does not help me much, because it is C++ code (or whatever it is). You do not communicate with a C4 like this. You only have midi to do this. I would need to know, what is send to a C4 to start level metering and what is send to start level metering on the displays. Since i can look at this git-hub code all day, at the end i will still do not know what was send to a C4. I hope i described my dilemma well enough. You need to be aware that i "translate" the MCU protocol from Cubase to a C4. And there is stuff that is clearly different between Mackie Control and a C4. Like for example the displays: A Mackie Control unit has only a single display. The example in the Logic manual shows: F0 00 00 66 10 12 00 48 65 6C 6C 6F F7 for writing "Hello" in the top left in the display of a Mackie Control unit. Of course, this example is for a MCU not a C4. It still works on the 1st display of a C4 by changing the sysex header to a C4 accordingly to: F0 00 00 66 17 12 00 48 65 6C 6C 6F F7 but you can do what you want, it will not work on the other three displays. Until i change that to: F0 00 00 66 17 30 00 48 65 6C 6C 6F F7 it writes again "Hello" in the top left corner on the display of the first row encoders (same like before). If i change that to: F0 00 00 66 17 31 00 48 65 6C 6C 6F F7 it writes "Hello" in the top left corner on the display of the second row encoders. If i change that to: F0 00 00 66 17 32 00 48 65 6C 6C 6F F7 it writes "Hello" in the top left corner on the display of the third row encoders. If i change that to: F0 00 00 66 17 33 00 48 65 6C 6C 6F F7 it writes "Hello" in the top left corner on the display of the fourth row encoders. So you see that the incoming sysex needs to be changed (the bold marked here), to be properly displayed on the C4. I assume, that the same thing is true for level metering: The incoming sysex for level metering on a Mackie Control is: F0 00 00 66 10 21 01 F7 It is not enough to change the ID to a C4 ID: F0 00 00 66 17 21 01 F7 The level metering is started (proofed by lots of incoming data from Cubase), but it doesnt do anything on the displays of a C4. And i want to know, how or what is send to a C4 (the midi data) to achieve the same with your DAW.

@msmcleod: Imade huge progress meanwhile with emulating the MCU protocol on a C4 with Cubase. Currently i have all assignment buttons working and can adress all displays. I could even start my own menues now. I still have one problem and that is level metering. I can enable the level metering, but i do not see anything happening on the displays. I see all the incoming midi-data for level metering from Cubase and i translate it to the C4, but it seems that adressing for that is different on a C4. I had similar problems with the displays, but could change the incoming sysex properly to the C4 displays. Could not find out what is need to change for a C4 and level metering and i have the hope, you might have some clue for me, if i kindly ask for it. Please help me with this if you can, it would be noble from you.

Quite understandable . I tried that experiment already, but could not get the displays to work. I would be even fine with one display, enough for Quick Controls. I could use the remaining Vpots for my hardware synths. The Generic Remote thing in Cubase is very limited. In fact, i can not even get the encoders working properly. There are only to options for encoders: absolute and relative. In relative mode, the encoders are working properly CW, but jumps when rotating CCW. I did not find anything, to get them work in both directions. But this is a essential thing, to get the encoders properly working, that is why i did not invest more time with it. I really do not understand Steinberg (as they wrote the protocol), why we as users on the other side, do not have a working option for the encoders, if we use the Generic Remote functions . It is a pity really. Thx for all the info so far

You are right, that this is the only thing i can do right now as a normal user. I can tweak some special functions out of Midi Translator Pro and can assign functions, i would not have under "normal" conditions. So i am very close already. Sadly this kind of workaround does not allow bi-directional editing, because the Commander software has only Midi-Out and no Midi-In (do not mix that with the general midi-settings for a C4). I am to dumb to get that working and to have proper automation feedback. But like i said, i have ambitions (maybe to high, but sure worth) and would even pay development. If you could look into the Steinberg MCU protocol, could you develop that?

Again many, many thanks. You both showed me valuable infos, that i searched a week, without a finding. I am a little shocked and suprised that Mackie seriously did not provide anything else, than just the info and midi-implentation of the Logic Manual 7.2, where it is described. That is pretty hard. So every DAW-developer needed to find out ways, how to provide the (display)-readouts from the DAW to the hardware? In fact, there was no protocol to start with? Phew, i think that this is a lot of work then. Now i understand, why a C4 is not supported in Cubase. Reason (Propellerhead) supported the C4 too, Reaper has some and with MAX you can get it working in Ableton. So i think that the C4 is missing only one major software and that is Cubase IMHO. Yes, the EoL of a C4 was years ago and that is why i do not understand, why there is not more to know about this hardware. I am suprised and happy, that you go another route and leave it open and SDK, for other people. Nice gesture and absolutely the right spirit. Is this documented in Github somewhere? What will happen in Cakewalk if you start to use the Commander software (from Mackie) with Cakewalk together. Lets say i use 2 rows of encoders with my hardware-synths and two rows of encoders with Cakewalk. Is that possible? In Logic you could not really use that mode. It was either this or MCU protocol, but not both AFAIK. That would be the best use for the Split-Zones of a C4, but i do not know, if a C4 really does this. Since it seems, you both know a lot about this topic. How much time would you need, to create the same support in Cubase and lets assume, you could at least look into the protocol that Steinberg already did for Mackie control. I know that this depends on lot of things, but some approximation would be nice, like best case and worst case (in days or weeks). I am at a point, where i would pay a developer for that task. I hope i do not offend you with such questions and offerings, but from my POV, i am just a user who really love this controller. It was my dream a decade ago, to own one. Yet, i have one and can only use it, in a standalone mode (via a virtual midi-cable and the Commander Software) with Cubase. Only downsides, i have no feedback and no automatic readouts and level-meters from the protocol. So each VST needs painfull labeling of each parameter-names. A process that would normally be automated and would only be needed to do it manually for your real studio-hardware. In a ideal world, the only thing that would be needed for us users, would be the Commander Software (with virtual Midi-In for feedback) plus the readouts of the protocol. The protocol itself could be some kind of plugin, so that each DAW has their own plugin to provide the readouts. That would be really UNIVERSAL, but Mackie does not seemed to understand that... sadly. The only thing i know about the Commander Software is, that it is written with JUCE, but i do not think that this info really helps and i assume you still can not look inside this program, to learn how it works. Do i need something special with the .chm file? I can open it and have the index/table contents, but sadly nothing else. The pages are empty . Thx alot and stay healthy

OK, regarding the assignment of the (unassigned) buttons, functions etc., that is something i understand, but does this apply to the MCU protocol too? I mean the protocol is something like a black box that Mackie provides to developers and they just make a connection between host and protocol. Once the DAW developers provide what they want to expose to the MCU protocol, the basic work should be done. Everything else would be to write components (button assignment, f-keys etc.) for the various hardware. I see the protocol as a middleman-software between host and hardware. All DAW controllers with feedback, are "passive" controllers and are initially (after powering on) brainless hardware. You can barely use the hardware if you have no MCU protocol. So do developers need some extra work to address the displays of a C4? I would say no, because the displays just extend the pages from a Mackie Control, where you otherwise would need to scroll through and if you use a C4 alone, it should at least just display the pages (from the MCU protocol). I can use the Mackie Control component of Cubase and use that on a C4. It begins magically working, i can access various things like volume, pan etc. , it even has feedback on encoders, but it misses the display , they are on but without a text. This is obvious, as the component was meant for a Mackie Control and not a C4. This "hack" can only be done, if i create a successfull sysex handshake before. In example simply start the Commander software and after that start Cubase. The Commander software does the handshake and Cubase provides the MCU protocol (to program the C4 hardware).

First, many thx for answering that fast. Great. i rather need the technical infos on the process how a C4 is working under MCU protocol and how to address the displays. So my first questions, are really just that. Would a DAW developer need to do much work for a C4, if it already supports Mackie Control? So again, does the MCU protocol have everything/provide everything, to make a C4 working? To my understanding, it is enough that the MCU protocol sees the C4. To be honest with you, i am a Cubase user?. Steinberg does not offer tools for users that own a C4. The have a Mackie Control component, but no C4. I wonder why and why it is not working at all? I might start thinking about, to leave the Cubase DAW, after 20years using it. I am really dissappointed that they do not listen to their customers and that we are still limited till today, with some BS they call Generic Remote, which is not working properly.

Hi msmcleod :) I own a C4 and nothing else. I am interested in how to address the four displays it have. Also i would like to know, if the MCU protocol can handle a C4 alone and if it provides the protocol automatically or does the C4 needs further implementation. I mean, if you have the hardware MCU working, does it need more code/xml whatever, to get a C4 working? To my understanding, it would need only a sysex-handshaking, but nothing more. Correct me, if i am wrong with this. It would help me a lot.