Mackie C4 and Cubase. How to make the encoders work?

u-man

2020-05-20 13:44:08

While the Mackie Control is supported by Cubase, the Mackie C4 is sadly not. Your program is the only tool, that can help me to solve my problem.  Your video here: https://www.youtube.com/watch?v=yjgmIUIS0SI
explains my problem. If i turn on the C4, the encoders behave like in your video (2´s complement example).
This behaviour is useless in Cubase, as it does not offer any options for the encoders of a C4, even if they are the same, like the Vpots of a Mackie Control (shame on Steinberg). Cubase does not know, how to treat "2´s complement" encoders.
The C4 also comes with a software called C4 Commander, which is normally used primaly for controlling hardware synths. I abused this program with a Bome virtual cable. I can use this cable in Cubase and have working encoders. My problem is, that the C4 Commander program only allows me to setup a Midi-out for the encoders, but no Midi-In and therefore i do not have feedback/bi-directional encoders. Anything i do with a mouse in Cubase, is not reflected on the LED rings of the C4 encoders.
I try my best to explain it well enough. The C4 Commander program has of course global midi-settings (in and out), so that the program knows, how the C4 is connected. But the definitions for the encoders (you create in the program) allows only midi-out. If i use the midi-out of the virtual cable to go back into the C4, the Commander program complains that the incoming midi is not from a C4 and stop the midi-stream.
I really hope you understand my problem and if not, feel free to ask :) .
I do not know how other DAW controllers work, but i think that all DAW controllers, have passive encoders. You (or DAW) need to mask/define the encoders initially, to get them work properly (like you do in the video). This is one of my main reasons, why i need to use the C4 commander program. As soon as i defined the encoders, i can start to use them in Cubase. I would like to remove this necessary step, but the program also defines the LCD labels for the encoders. In fact, i am very close to be satisfied, except i do not have feedback from the DAW.
My biggest hope, is that you might have a solution for me. I guess that i need to do something with the virtual midi-out, so that the C4 commander program does not complain about the midi-in (from the virtual out).
Thanks in advance

Steve-Bome Forum Moderator

2020-05-20 14:56:52

So your encoders send out 2's complement but Cubase is looking for absolute? Did you get that working (even if no MIDI feedback)? Is that what you need help with?

Or is the issue that you have the encoders now recognized in Cubase but no feedback to the LED rings of your encoders? Is Cubase sending any MIDI out when you turn a knob. Do you see it when looking at your log window?

I'm just trying to understand  whether the problem you are trying to solve is from your controller to Cubase, or from Cubase back to your controller.

What controller do you have?  If you want to control LED rings and you have a relative type encoder, I'm not sure how you do that unless I understand the MIDI in it needs to control the rings?

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

 

u-man

2020-05-20 15:47:41

First, many thanks into looking this.
My controller is this one here: https://www.zzounds.com/item--MACC4PRO

\"So your encoders send out 2\'s complement but Cubase is looking for absolute? Did you get that working (even if no MIDI feedback)? Is that what you need help with?\"

I got this working. Help only needed, if i did something wrong here.

\"Or is the issue that you have the encoders now recognized in Cubase but no feedback to the LED rings of your encoders? Is Cubase sending any MIDI out when you turn a knob. Do you see it when looking at your log window?\"

Yes, that is my problem, no feedback to the LED rings. Cubase can send out, but the \"middle-ware\" program Commander C4, refuses to accept the Cubase midi-out and says, this is no Mackie C4 input :( and stops the midi-stream. My guess is, it expects input that is relative again, not absolute. But this is just my opinion. I am a novice with midi, i do not know what is really needed for feedback on the rings, but i think \"from Cubase back to my controller\" is essential for the rings :) .

Like i wrote before, this is some kind of a hack, i did here. Cubase is not able to recognize the encoders properly, without the C4 Commander software and your MTP program.

Here is the Commander software described: https://www.soundonsound.com/reviews/mackie-c4
I attached you the code-definitions for the common midi-controllers, that the software uses, to program the encoders.

If you do not program the encoders, then the encoders will behave like in your video (2´s complement example) but i do not have in/decrements of 1. I have steps of +-65, instead of +-1, because Cubase has no other way to handle this.

Here is my tutorial, i did so far (sorry it is in german): https://www.sequencer.de/synthesizer/threads/mackie-c4-und-cubase-hier-lang.152922/

You can look at step 3 and step 10, to see how the Commander program handles midi. Important is, that you can not define midi-in for step 10, only midi-out. Hope this helps :)


Attachments:

midi_controllers.xml

Steve-Bome Forum Moderator

2020-05-20 16:11:56

OK, could you hook up you C4 to MIDI Translator Pro and Turn each of the 32 knobs and capture the MIDI it is sending when connected to C4 Commander. Please annotate in the log what knob you are turning and which way.

Then do the same by turning knobs on your C4 Commander so that we know what it is sending to update LED rings.

 

With this we could probably figure out the methodoligy needed for 2 way translation with Cubase.

As far as scribble strip text. We can look at it but not likely be able to do much unless Cubase sends scribble strip information back.  Are you connecting it to Cubase as a Generic Controller?

 

 

u-man

2020-05-20 16:57:30

I gave up on the scribble strip text and Cubase, also gave up on Generic Remote. It does not function properly. Unable to send or receive NRPN/RPN for example. You have only two options for encoders in Generic Remote: relative and absolute. If set to relative, the encoders behave correctly with incremental values, but not with decremental. Decremental behaves like before: +-65 steps. So this is only partially working and still useless.

I will do the things, you suggest, but i would say, lets start with just the first 8 encoders. If you just turn on the device and use nothing else, then the encoders goes from cc 0 to cc 31 (i have 32, not 24 encoders :) ) and have in/decremental steps of +-65. If i turn on the Commander software and use the midi-controller.xml i attached you, then the encoders will send absolute values in +-1 in/decremental steps. The cc that is send, depends on what cc is used in the Commander software for the individual encoder. With MTP and a virtual cable, i can send those values correctly to Cubase and everything works, like it should. I just can not send anything back, out of Cubase to my controller (or to the Commander Software in this case).

I am afraid, that this will be a hard nut to crack :/ , because i think the Commander software does not send anything that would be needed for the LED-rings. This software was not meant to do that. If you hardware-control your hardware-synths, you would not normally need that, hence why i think, it does not expect any feedback or send out data that is relevant for the LED-rings.

Steve-Bome Forum Moderator

2020-05-20 17:08:09

OK, but instead of using the first 8 V-POTs, pick maybe the second 8. I'm trying to figure out if what they send is similar to Mackie MCU protocol.

 

u-man

2020-05-20 17:25:56

First encoder (top, left) if not using Commander software, sends this if turned CW:

1: MIDI IN [Port 1 on MTPAV]: B0 00 01
2: MIDI OUT [Port 1 on MTPAV]: B0 00 01
3: MIDI IN [Port 1 on MTPAV]: B0 00 01
4: MIDI OUT [Port 1 on MTPAV]: B0 00 01
5: MIDI IN [Port 1 on MTPAV]: B0 00 01
6: MIDI OUT [Port 1 on MTPAV]: B0 00 01

If turned CCW it sends:

7: MIDI IN [Port 1 on MTPAV]: B0 00 41
8: MIDI OUT [Port 1 on MTPAV]: B0 00 41
9: MIDI IN [Port 1 on MTPAV]: B0 00 41
10: MIDI OUT [Port 1 on MTPAV]: B0 00 41

First encoder (top, left) if using Commander software (in this case CC70), sends this if turned CW:

1: MIDI IN [Port 1 on MTPAV]: B0 00 01
2: MIDI OUT [Port 1 on MTPAV]: B0 00 01
3: MIDI IN [Bome MIDI Translator 1 Virtual In]: B0 46 0D
4: MIDI OUT [Bome MIDI Translator 1 Virtual Out]: B0 46 0D
5: MIDI IN [Port 1 on MTPAV]: B0 00 01
6: MIDI OUT [Port 1 on MTPAV]: B0 00 01
7: MIDI IN [Bome MIDI Translator 1 Virtual In]: B0 46 0E
8: MIDI OUT [Bome MIDI Translator 1 Virtual Out]: B0 46 0E
9: MIDI IN [Port 1 on MTPAV]: B0 00 01
10: MIDI OUT [Port 1 on MTPAV]: B0 00 01
11: MIDI IN [Bome MIDI Translator 1 Virtual In]: B0 46 0F
12: MIDI OUT [Bome MIDI Translator 1 Virtual Out]: B0 46 0F

If turned CCW it sends:

13: MIDI IN [Port 1 on MTPAV]: B0 00 41
14: MIDI OUT [Port 1 on MTPAV]: B0 00 41
15: MIDI IN [Bome MIDI Translator 1 Virtual In]: B0 46 0E
16: MIDI OUT [Bome MIDI Translator 1 Virtual Out]: B0 46 0E
17: MIDI IN [Port 1 on MTPAV]: B0 00 41
18: MIDI OUT [Port 1 on MTPAV]: B0 00 41
19: MIDI IN [Bome MIDI Translator 1 Virtual In]: B0 46 0D
20: MIDI OUT [Bome MIDI Translator 1 Virtual Out]: B0 46 0D
21: MIDI IN [Port 1 on MTPAV]: B0 00 41
22: MIDI OUT [Port 1 on MTPAV]: B0 00 41
23: MIDI IN [Bome MIDI Translator 1 Virtual In]: B0 46 0C
24: MIDI OUT [Bome MIDI Translator 1 Virtual Out]: B0 46 0C

u-man

2020-05-20 17:32:16

It is not only similar to MCU protocol, it can even use it. But the displays are not adressed, so you are basically blind in the woods and you do not know what you are doing. I tried for weeks, to get anything on the displays if abusing the MCU protocol in Cubase. In this mode everything works with feedback. I know that for sure, because i can reproduce pan settings for tracks 1-8 (but thats all).

Also my third encoder row (16-24) are the same Vpots 1-8 from the MCU protocol. Same CC, same settings.

u-man

2020-05-20 17:38:40

AFAIK the whole Mackie DAW controller line, has no "memory" for settings/encoders. This must be provided by software. The MCU protocol, does this on the fly, i would not need the Commander software anymore. If no software is present/running in background, the encoders are "brainless" again and behave like i described above.

Steve-Bome Forum Moderator

2020-05-20 17:51:37

Turn VPOTs in second row without commanders and lets see what you get?

u-man

2020-05-20 17:57:26

First encoder, 2nd row, turned CW send this:

1: MIDI IN [Port 1 on MTPAV]: B0 08 01
2: MIDI OUT [Port 1 on MTPAV]: B0 08 01
3: MIDI IN [Port 1 on MTPAV]: B0 08 01
4: MIDI OUT [Port 1 on MTPAV]: B0 08 01
5: MIDI IN [Port 1 on MTPAV]: B0 08 01
6: MIDI OUT [Port 1 on MTPAV]: B0 08 01

and this if turned CCW:

1: MIDI IN [Port 1 on MTPAV]: B0 08 41
2: MIDI OUT [Port 1 on MTPAV]: B0 08 41
3: MIDI IN [Port 1 on MTPAV]: B0 08 41
4: MIDI OUT [Port 1 on MTPAV]: B0 08 41
5: MIDI IN [Port 1 on MTPAV]: B0 08 41
6: MIDI OUT [Port 1 on MTPAV]: B0 08 41

 

Second encoder, 2nd row, turned CW send this:

1: MIDI IN [Port 1 on MTPAV]: B0 09 01
2: MIDI OUT [Port 1 on MTPAV]: B0 09 01
3: MIDI IN [Port 1 on MTPAV]: B0 09 01
4: MIDI OUT [Port 1 on MTPAV]: B0 09 01
5: MIDI IN [Port 1 on MTPAV]: B0 09 01
6: MIDI OUT [Port 1 on MTPAV]: B0 09 01

and this if turned CCW:

1: MIDI IN [Port 1 on MTPAV]: B0 09 41
2: MIDI OUT [Port 1 on MTPAV]: B0 09 41
3: MIDI IN [Port 1 on MTPAV]: B0 09 41
4: MIDI OUT [Port 1 on MTPAV]: B0 09 41
5: MIDI IN [Port 1 on MTPAV]: B0 09 41
6: MIDI OUT [Port 1 on MTPAV]: B0 09 41

and so on....

Steve-Bome Forum Moderator

2020-05-20 18:57:19

Hi,

Try this.

On Cubase, set up for 4 Mackie MCU controllers. I think when you do this the first will be Mackie4 and the last will be Mackie 1

If I figured it out right, the top row will control Mackie 1 (which I set to BMT1), the next row, Mackie 2 etc.

VPOT\'s only no faders.

I\'m assuming that the encoders may indeed use similar feedback as Mackie VPOTS

I\'ve set it up that the same V-POT messages go out for each row of encoders but on a different MIDI Port (virtual Mackie Controller).

On return messages I look at the incoming port to convert the CC back to the original that was sent.

Let me know if this helps!

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

P.S. And I added a MIDI Thru path from  and to your C4 to Mackie1 only so other messages should still work.

I\'m still not sure what messages would go back to the scribble strips though.

 


Attachments:

C4-2020-05-20.bmtp

u-man

2020-05-20 19:39:58

I did like you say, but i do not know how to setup your project in MTP. What should i put in:
Mackie1 INPUT/OUTPUT
Mackie2 INPUT/OUTPUT
Mackie3 INPUT/OUTPUT
Mackie4 INPUT/OUTPUT
MackieC4 INPUT/OUTPUT
What is the right assignment here? Should i create 5 virtual midi-cables, with these names?
What do i assign as midi input/output for the four Mackie Control units that i have in Cubase?

Steve-Bome Forum Moderator

2020-05-20 19:43:24

Aliases

Mackie1 - BMT 1 - First Cubase Mackie Controller (last on the list in Cubase)

Mackie2 - BMT 2 - Second

Mackie 3 - BMT 3 - Third

Mackie 4 - BMT 4 - First (top of the list in Cubase

Mackie C4 - To and from your Mackie C4 controller.

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

u-man

2020-05-20 19:54:38

Believe me, you will not be able to display anything on the C4, because the MCU protocol do not support the C4 displays. They need to be adressed differently, which the MCU protocol (in Cubase) do not do.
I know this, because i asked Sonar DAW developers, how they did this and they said that. To do the scribble strips outside of the MCU protocol, you would need sysex-messages. Sadly the C4 lacks of documentation, but that is how you would do it with a Mackie Control unit outside of the MCU protocol and believe me, that is not something we want here.
Since the MCU protocol of Cubase is not open source in any form, we simply have no way to adress the scribble strips for the C4.
This is the last documented form for MCU protocol: https://usermanual.wiki/Apple/Logic.1909626546
Starting at page 239
Like i said, the adressing for the displays of the C4 is different (sounds even logical to me somehow).

Steve-Bome Forum Moderator

2020-05-20 20:09:14

comment

It looks like someone has started reverse engineering this. It looks like he is trying to translate Mackie MCU scribble strip to Mackie C4. http://www.sawstudiouser.com/forums/showthread.php?14866-Mackie-C4-Progress

u-man

2020-05-20 20:15:18

Ok, i hope i did setup everything like you told. To describe what is happening now, is pretty hard, but i will try :)

The first row acts for pan setting in tracks 1-8, but is reflected on the rings of the third row. And the pan setting is working in reversed way. So if turning right, the pan is going left and vice versa.

What the other rows are doing, i am not able to tell, but the send the usual data according to the midi-monitor.

u-man

2020-05-20 20:39:24

The best document for the displays of a C4 i found, is this: https://github.com/Cakewalk/Cakewalk-Control-Surface-SDK/blob/master/Surfaces/MackieControl/MackieControlC4TxDisplay.cpp

This is not much code and works very well.... in Sonar  :/
Tracktion and Logic DAW are obviously the best, in supporting the C4.

But i do not mind to use the MCU protocol, because you see it would be tremendous work, to get this working in Cubase. The best way, is still the Commander software route. It just misses the feedback and you are not bound to a protocol that is not intended to work on a C4. With the Commander software, everything is working already, except the feedback from the DAW. It is way better to focus on that.
I spend already weeks now and i can say that i have learned a lot, but also a lot frustration and the MCU protocol was by far the most frustrating thing. I read the whole www... so to say :) .

Steve-Bome Forum Moderator

2020-05-20 20:40:35

If on the wrong channels then you probably do not have the ports assigned correctly.

If the v-pots are turning the wrong way, comment out these lines in the translators.

 

if qq>64 then tt=qq&15

if qq<64 then tt=qq|64

 

And then add this line

tt=qq

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

u-man

2020-05-20 21:31:05

pan settings are working correct now. everything else, is like before (obviously :) ).

i attached pictures of the setup. so you maybe have a clue, what else could be wrong.


Attachments:

C4 connection_1.png
C4 connection_2.png
C4 connection_3.png
C4 connection_4.png

Steve-Bome Forum Moderator

2020-05-20 21:46:47

comment

Can you post a screenshot of how your aliases are set up in MT Pro? Also disable any ports that are trying to connect directly to your C4 from Cubase.

u-man

2020-05-20 22:01:25

I am sorry, but what do you mean by aliases in MT Pro?
I think there is really nothing in Cubase that uses the ports for the C4. I checked it right now.
In the picture it is Port 1 on MTPAV. That is where the C4 is connected.
I am sorry, that there are so much midi-ports in the Cubase picture :/ .

Here again the midi-setup in Cubase, comparing to before, this time Port 1 is \"inactive\" for both midi in and out, so nothing uses it.


Attachments:

C4 connection_5.png

Steve-Bome Forum Moderator

2020-05-20 22:15:20

comment

In MT Pro click on the menu item MIDI then Edit Project Port Aliases. You will see a screen shot of how your aliases are assigned.

u-man

2020-05-20 22:21:52

Here it goes:

 


Attachments:

C4 connection_6.png

Steve-Bome Forum Moderator

2020-05-20 22:29:15

That looks correct. I just tried this with the following project file although my devices sends 41(65) for positive and 3F (63) for negative. Just disable my presets and enable yours and it should work although you might have reverse encoders again.

After disabling the conflicting ports on Cubase I had to shut down Cubase, the MT Pro, then open MT Pro first then Cubase.  I tested with just virtual devices though.

What gets returned to the controller is the same CC it sends however the values are the same as the Mackie MCU doc calls out of encoder rings.

So for the first 8 you should see B0 00 qq  through B0 07 qq - qq will be a value from 0-12

For the second at it would be B0 08 qq through B0 0f qq

and so forth.

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 


Attachments:

C4-2020-05-20.bmtp

u-man

2020-05-20 22:47:40

Ok, i opened your project. I guess your presets are the ones with the EC4 label. Those are already disabled.
Pan settings are reversed again, but this time, i do not even have the feedback/rings in 3rd row or better said no rings at all :/ .

You seem to have this thing here: http://faderfox.de/ec4.html
If i just have bought this, instead of my C4 :)

Steve-Bome Forum Moderator

2020-05-20 22:51:34

comment

You could buy one if you want, however the translations would need to change in both directions. It is a nice little unit. Much smaller than a C4 but it IS a bit spendy. You might also want to consider a MIDI Fighter Twister which is a bit less expensive (probably about 1/2 the price of an EC4).

u-man

2020-05-20 23:02:04

No display, no way i buy it :) . EC4 is cheaper then my C4. I might sell it, if i can not use it, to my like and buy a EC4.
Otherwise, i am pretty amazed by the C4. It is really outstanding haptics and quality.
In combination with MTP and this Commander software, i can do already things, i only dreamed off.

Steve-Bome Forum Moderator

2020-05-22 01:52:06

Did you ever get your VPOT rings to do anything? If there was any movement at all, it would be promising and maybe just a matter of scaling what is coming back from Cubase. Mackie sends values of 0-13 but you could scale that up to 0-127 using the technique shown in this tutorial.

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

 

 

u-man

2020-05-22 11:16:13

Ok, lets say the last project you send me is v03, then v02 was promising because the third row encoders had feedback/working LED rings. Everything i did on first row encoders, was reflected on third row encoders RINGS with feedback.

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. Again, if i rotate first row encoders, it is reflected on third row encoders rings and they have feedback.

I am not sure, but maybe Mackie does that on purpose, to avoid a feedback-loop. I think i read something about that in the Cubase forum, but i need to find it. Although there is this "flip" button on a Mackie Control, where you can change Vpots vs. Faders and vice versa.
I hope i could help :) and i will try to find that Cubase post, that describes that the Vpots send and receive on different CC. From my memory, they send from CC 16-23  and receive from CC 48-55.

u-man

2020-05-22 11:47:38

Oh and to answer your question: If i do not use any programs like MTP or Commander software (or both), i am basically lost. I would need to work with just Generic Remote and this thing is kind of broken. The only thing i could achieve with Cubase alone is, to have the encoders partially working. CW rotating works, CCW not and that is all. No rings, no feedback, no display. But i admit, that i did not spend much time, as the encoders are not working properly, so everything else is not much of a use.

Steve-Bome Forum Moderator

2020-05-22 17:47:30

comment

I'm pretty sure we can get all your encoders to work with MT Pro. The main issue I see is V-POT feedback. and of course scribble strip feedback. We simply make your C4 appear as three generic Mackie devices and route encoders from each row of V-Pots to a different Mackie interface in Cubase.

u-man

2020-05-22 20:29:21

I do not want to sound like a douchebag here, but i really do not see, what our end-result will look like. I am not a fan of the MCU protocol. It has only two features, i would consider nice.

First is the feedback of all settings.
Second is the read-out of every parameter-name, track name, labels etc. (i am a lazy dog :) )

But other then that, i have nearly no interest in this protocol. Ok, i admit, how can i say that, if i never saw it in action. I have a Yamaha 01v96i for remote control the mixer in Cubase.  I mean if you can solve this mystery of a C4, you would not only make me happy. There are many Cubase-users, who would like to see that thing rocking. But in nearly 15 years, no one could find a solution, except the one with the Commander-software i described. Even that, is pretty unknown.
You should not underestimate this Commander software, because you can control both: software and hardware. Something that a MCU protocol can not. You can switch 32 labeled paramter settings to the next 32 parameters, with just a button press. Same for switching between hard and software. I can have dozens of pages. I am even not limited to 6 character labeling. My names can be 55 letters long, if i really need that, and so on etc.
I have plenty of hardware and they all love the C4 :) :D .

I attached you the software. You can try it, even without a real C4. To get a feeling.

But i am to dumb, to make feedback possible, maybe it is impossible to do, i do not know. Steinberg needs more people like you :) .
The Faderfox guy lives in Hamburg, like me....and he like problems...  who knows :)


Attachments:

C4_Commander.zip

Steve-Bome Forum Moderator

2020-05-22 20:56:03

comment

Yeah the faderfox has displays but right now you can update the display text remotely. He tells me he is working on that feature for a future firmware revision.

Steve-Bome Forum Moderator

2020-05-22 20:58:00

comment

Also, MT Pro has the capability to send serial messages to serial port and I've done a few projects using it. See this video. https://youtu.be/PZevp3vgcAo

u-man

2020-05-22 21:58:17

I like your product, i bought it right now.
Many people compare it to Midi-OX, but that is really not the same.
You should make more encoder presets :) . I will spread the word ;) .

Challenge: Make just one encoder work properly, with feedback on rings and one label. I would be happy enough.

Steve-Bome Forum Moderator

2020-05-22 23:02:44

I would do that if I had a C4, but for now I would rely on C4 users (you to test).

 

u-man

2020-05-23 15:54:31

I am really tempted to send you that thing :)
While buying MTP, i saw that the company is in Munich/Germany. I am curious, if we can talk in german?

Back to topic: Yesterday i tried to get some LED rings working, by using the Logic manual and MTP only. It worked right away and i would need what you already suggested, to convert the absolute values (1-127) from Cubase to a 1-11 range.

B0 20 06 to B0 27 06 creates a centered LED on the ring for the first row encoders.
B0 28 06 to B0 2F 06 creates a centered LED on the ring for the second row encoders.
B0 30 06 to B0 37 06 creates a centered LED on the ring for the third row encoders.
B0 38 06 to B0 3F 06 creates a centered LED on the ring for the fourth row encoders.

So that could be used, for the feedback on the LED rings. Since the rings are just a visible feedback, we need to do the same with the \"real\" values of a parameter too.

So we need a Translator that recognize which encoder (and CC value) is rotated in Cubase and translate the 1-127 value to a 1-11 value. That would be the basic work for the rings. How we would do the \"real\" values of a parameter, is something i do not know right at the moment. The same goes for the various types of a ring (single dot, boost/cut, wrap, spread). Other then that, i have hopes now and i am optimistic :) .

I also tried the example of writing \"Hello\" to the LCD displays and this worked too :) .
The example in the manual shows:

F0 00 00 66 10 12 00 48 65 6C 6C 6F F7
for writing \"Hello\" in the top left of the display in the master section of the MCU protocol.
Of course, this example is for a MCU not a C4.

The sysex for my C4 is:
F0 00 00 66 17 01 00 00 00 00 00 00 00 34 31 06 00 F7.

If i did understand the manual correctly, i would make a new sysex from the bytes that are in bold here, to make it look like this: F0 00 00 66 17 12 00 48 65 6C 6C 6F F7
and indeed it wrote \"Hello\" in the top left corner on the display of the first row encoders.

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

The maximum offset to write \"Hello\" to the top right would be 32 and for bottom right 6A, but considering 7-chars per channel/encoder to stay in this standard: 6-chars + 1-char as a seperator, it would be 31 and 69 (last label to the right, can only display 6-char).

So the thing here is, we need to know, in which section we are. From the example in the manual alone, i could not manage to display \"Hello\" in any other display, but the one from the first row. Only when i was starting to change the bold number from \"12\" to \"30\" - \"33\", i was able to show \"Hello\" on the other three displays. Obviously i have no clue, to which \"section\" this number belongs, but it seems that the protocol really makes differences here. Be aware, i still just use the C4 and MTP here (no Cubase or Commander software involved).
Maybe the numbers 30-33 are really reserved for the C4 and the manual means with \"master section\" only the display of a MCU, because that would be nice for us.

I still see this as a huge success, because the manual tells the truth, i only needed to change the sysex header from a \"MCU\" to a \"C4\" header. We can access all displays and write something in it, without creating additional code for just that. Hooray!!!

I will stop here and continue, if i find out anything new, that also could be interesting. So far, so good.

Steve-Bome Forum Moderator

2020-05-23 18:11:46

I am really tempted to send you that thing :)
While buying MTP, i saw that the company is in Munich/Germany. I am curious, if we can talk in german.

SJC> The company is based in Germany, but I\'m a contractor working out of the USA.

Back to topic: Yesterday i tried to get some LED rings working, by using the Logic manual and MTP only. It worked right away and i would need what you already suggested, to convert the absolute values (1-127) from Cubase to a 1-11 range.

B0 20 06 to B0 27 06 creates a centered LED on the ring for the first row encoders.
B0 28 06 to B0 2F 06 creates a centered LED on the ring for the second row encoders.
B0 30 06 to B0 37 06 creates a centered LED on the ring for the third row encoders.
B0 38 06 to B0 3F 06 creates a centered LED on the ring for the fourth row encoders.

SJC>
In Mackie Mode on Cubase, you will see the following for encoders in each row for LED rings.

B0 3i XX

Where i is the V-POT number 0-7
and the last 4 bits of xx is a value of 0 (all rings off) to 11 (All rings on)

You will likely need to strip out bits 4-7 as these are used to define whether the dot is on (bit 6) and the type of ring (dot,boost/cut,wrap, or spread)

To determine which ring on your C4 you want to light up, it depends on the port from Cubase.

So you would need something to convert from.

B0 3i xx on the first MCU device to B0 20-27 XX

Coming from the second port same incoming to B0 28-2F XX

and so forth.

You can also use raw MIDI on incoming Sysex to confirt you MIDI messages, just remember from Cubase standpoint it sees for MCU devices so you will need to do Sysex conversion similar to V-POT ring conversion based on the attache MCU port (from Cubase perspetive)

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

u-man

2020-05-23 21:46:38

I understand your theory: "convert from B0 3i xx on the first MCU device to B0 20-27 XX"
This basically means, make the third row from the C4, the first. Am i right?

You expect way to far from me. I have a basic to average understanding of these stuff, but i can not make this working on my own. The routing alone, is a headache for me.  We have four MCU units in Cubase, to adress the four displays of a C4. You seem to forget, that we can not tell Cubase to adress the LCD displays. I have not found a way to do this. There is no file or data that we can manipulate, none that i am aware of. So we would need to emulate display read outs and that would be a infinite amount of rules. Ok some things would work, but parameter-names of a VST-instrument i.e. How would you do that?
You can correct me if i am wrong.

I can only help to provide as much as info i have or by doing some tedious work, like Character Sets i.e.
I created and attached you the Character Settings for a C4. I write now, a updated version, that will include all zones (encoder 1-8 labeling/names) and the needed offsets to label the displays.


Attachments:

C4_character_set.txt

Steve-Bome Forum Moderator

2020-05-24 02:31:45

Hi,

If you want me to write the project for you I can do so for a fee as it is really beyond the scope of free support here.  Just drop me an email.  You will still need to define as 4 Mackie MCU devices in Cubase, each with it's own defined MIDI Virtual ports. In MT Pro we look at which virtual port the message is coming from to do the math and tell which encoder to send the message to. I will be able to show you how it is done using my device type however since I don't have a Mackie C4.

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

u-man

2020-05-24 03:40:18

How much of a fee would that be, you asking for? I have no problems with it, depends how high that fee is.
But, i am not the one who makes that project that big and i do not "see" how you will manage the displays, because i do not know a way. What is a MCU protocol worth in Cubase, if everything is blank on the displays?
You do not understand, that there is no message to "catch" regarding the displays. All this display stuff is handled, somewhere deep in binary/code you simply can not access. The MCU component you choose in Cubase in the Studio Settings Menu, is not editable. It is impossible to tap that sysex and to change it. At least by "sniffing" the MCU behaviour, i do not see any sign of display access or sysex.  This approach looks like a dead horse to me.
You do not see, that not the C4 here is the problem, it is the MCU protocol of Cubase. It is not open in any way.

The current status of the project, is the same, as if you would just use a single MCU unit. The results are the same. I did not won anything new, by using 4 MCU units, even if i understand your intentions behind that. You need something to convince me, regarding how you want to get the displays working, because they will not working magically, just by translating third row to first row etc., if you really think that.

Steve-Bome Forum Moderator

2020-05-24 18:59:48

You are probably right. I think I should only take on the project if I actually had a C4 (which I don't). If I did, I could probably make it work. Without a C4, I would rely on a user with a C4 to do testing for me and this would increase the number of hours quite a bit.

 

Reach out to me via email if you want to know my pricing.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

u-man

2020-05-24 19:41:42

Since you can not explain how you would make the displays working, i can safely say you can not. Even if i can pay you weeks, you will not be able to do this and even if you would have the C4 right on your fingertips.
Let us finish here, because i told you twice, that the MCU protocol in Cubase is a dead end. The C4 is not a supported product for this protocol and the protocol is not open. The displays are controlled sending binary information encapsulated within the MIDI messages, and it's different between the MCU and the C4, which is why we do not see anything on the displays of a C4 and there is no way to change that, as it happens internally of Cubase.
You are somehow possessed by the idea, that you can still do this and you sadly do not believe me or listen to me.

I wanted rather simple things and my approach is fully working, except feedback. Simple things, like we start with just one single encoder. Feedback and the right rules/translator for inc/dec values +-1 on the encoders. Nothing more. Not a gigantum of 4 MCU units and what not.

All the invested time, was for nothing good, because of this useless MCU protocol approach.
Right now, i am rather frustrated and start to regret the purchase.

Steve-Bome Forum Moderator

2020-05-24 22:31:46

I could do it for encoder feedback if I had a C4. The attached should work correctly if you set up your C4 correcty and the feedback that was required is as you described.

Without adequate documentation or a controller, it would be difficult to set this up with any controller let alone a C4.

If you set up Cubase for 4 Mackie controllers with the port numbers as I previously described  and set you C4 knobs to 0-31 then it should work. If it doesn't then the specification or requirements you described are incorrect and without proper documentation or a C4, there is nothing much more I can do.

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 


Attachments:

C4-2020-05-20.bmtp

Steve-Bome Forum Moderator

2020-05-24 22:38:38

comment

And it will require the MCU protocol unless you want to define your own control surface. We provide the tools (MT Pro) and guidance here for free. I could probably get it working but it would be cost prohibitive for you which is why I’m declining any paid services. I provided a project file with instructions on how to make it work with Cubase, but I cannot change the way Cubase behaves. I have to program withing the boundries of what it supports.

Florian Bome

2020-05-24 23:58:16

Hi u-man,
I am sorry you got frustrated during the course of this discussion. This is the last thing we want!

Steve\'s only mission here is to assist and guide MIDI Translator Pro users. My experience is that he always tries his best. Without looking into the details, I can see that he did care a lot about your issues with the best intentions. After all, he is getting payed by Bome!

Now if a provided solution doesn\'t work, there are many possible causes: lacking the exact hardware, Steve cannot test the solution himself. And he is not present in your studio, to make sure that the MIDI setup is 100% as expected by him. And it often takes multiple iterations of trial and error to find out what works and what doesn\'t. You\'re doing ground breaking stuff here!

And even if an approach will not work after a lot of trial and error, I can still only see good intentions. In this particular case: Steve knows MCU very well, has a working project for Cubase, so he can leverage work he has previously done.

I hope this clarifies a bit.
Best regards,
Florian

u-man

2020-05-25 04:20:40

Ok, this will be a rather long post and i apologize right from start.
First, i got not frustrated during the course of this discussion, it is just one of these days where everything wents downhill. A day where you only hear negative things, especially on that C4 topic.
I already spend a huge amount of time, just for all the stuff i found out regarding the C4. Registered in many forums etc. just for a little piece of cake-info, till a point where my friends are asking me, if i am ok.
I got frustrated, because even with all the infos and the new exciting find outs, i feel only exhausted. I am not able to transform all that into something usefull or something i consider real progress.
It is a passion that drives me, because i really like this thing. Maybe there are other hardware controllers, that do the same, but i did not see one that is like a C4.
Sadly Steinberg did not had the same passion. I really doubt that any of their staff-members wrote the MCU protocol, it is more likely they hired someone who did that, because there are things, that really makes no sense otherwise.

But back to topic: A forum member told me, to take a look into MTP and try my luck there. Indeed, i was amazed by the product and i already can do things, that would otherwise be impossible. For example, the Commander software can layout a encoder, but you can only use one function. So either you have a rotary encoder or a push button, but you can not have both. With MTP i can do both easily and i can connect the Commander software with Cubase which is 5 of 5 stars worth for MTP.

Of course i tried many things with the C4 and the MCU protocol, as someone might think the protocol should be similar and indeed it is to a huge degree. But as i said, the protocol is closed to public view. There is no way to change the adressing of displays. Cubase supports MCU+XT and that the XT is working, is just coincedence being the same like a MCU just without transport and assignment buttons. A evidence for that is, how Cubase is unable to distinguish between the two devices. They will have the same name, just with a number at end. No other DAW will treat the devices like this. In other DAWs there is a unique name for MCU and for XT, because they did their homework and they know by sysex handshake, with which device they are dealing with and if a XT is left or right from a MCU etc. etc.
Something that Steinberg did not care about, hence there is just MCU1, MCU2 etc. A unacceptable pain for a user, if you ask me.
There is a reason why Mackie (or other DAWs) did this, because all units (MCU+XT+C4) should also work as standalone. This is not so relevant if there would be only MCU and XT, but in case of a C4 it is relevant. If a C4 is used standalone, you could split encoder rows i.e. use two encoder rows for software and use the remaining two encoder rows for hardware. Many possibilities, many options. Too many for the poor staff-crew at Steinberg. They simply did not include it into their protocol and because they surely paid a lot for this protocol, they kept it close and only hardware vendors are allowed to ask for a remote SDK, paying licence fees and their first born son.
This all happened at a time, where the biggest rival for Cubase was Logic. Both companies from Hamburg. Since Logic already had a perfect working Logic Control (basically a MCU), it is obvious why Steinberg really needed a MCU protocol, if they like it or not. Especially when Apple announced to buy Logic.

Coming to the point (and end): I really hope, that it is now somehow clear, why i do not believe that you can get the displays working with a MCU protocol. If we would talk about devices that support the MCU protocol (Cubase) like Behringer X Touch etc. , i would believe that, because all these devices copy/emulate a MCU unit.
But till today, i have not seen a device like a C4 that works with a MCU protocol or a device that can adress more than one single display with the protocol (in Cubase).

I am no expert and maybe i am doing something wrong with midi-monitoring, but i do not see any messages coming or going into that protocol, that looks like names, labels etc. with display adressing including offsets and what not. That is the only reason, why i wrote to Steve that he needs to convince me, show me something, why he is so sure that he can make the displays working.

I would even ship this thing to him and i guess shipping alone would be like 80-100€.
Maybe are able to pay him 2-3 days (depends how much), but i have a strong feeling, that he will fail with the displays. I am not questioning his skills, i am questioning Cubase and this damn protocol.

This was told to me by a member that has a lot experience with MCU product line and Cubase:
"Another issue you would have with using the C4 is, even if running smoothly, when multiple Mackie controls are in use the controls spread across them and there is no way to mirror. i.e. if you had an MCU for faders and a C4 for plugin control, the first 8 vpot parameters would be on the MCU, and vpots 9 and onwards would be on the C4. There's no option to put 1-8 on the second surface (i.e. mirror).

This is a real pain if you have an MCU and a second controller (Such as keyboard controller) that utilises Mackie protocol. It really can not be that hard to setup a mirror option, surely?! "

This brings us to adequate documentation. Well, there is no more than this Logic Manual and all the other findouts by trial and error, that i already posted to you and the more i think about, it does not need much more.
It is the responsibilty from the host (Cubase), to create necessary connections and what the vendor want to provide to the users. What this means for Cubase or our case, is written above. There will be no documentation, unless you go the remote SDK route, paying fees and giving away your first born son. The only thing we can do, is reverse engineering the protocol, which we already partly did in this thread.

My initial plan was, collect as much as possible info. Find out as much as possible on your own. Depending on this, going to Steinberg, pay a developer to include the findouts of the C4. I will not describe what kind of experience that was, just talking about it in the Steinberg forum (awful).

I hope it is more clear now, from where my frustration comes. If you know, that you are so close, but still can not manage to make it work + all the other bad experience i had on this long journey.

Again, i am not questioning the skills of Steve. I am happy to talk to a person like him. Someone who understand encoder settings (2´s complement example etc.), because Steinberg developers can not. Again a evidence how ironic this alone is. If they really have written the protocol, why there is no working option (in Generic Remote) for these kind of encoders??? And this has not change since a decade, even if the forum is full of people begging for it.

How a proper encoder support should look like, is shown here:
https://www.cantabilesoftware.com/guides/controllerEncoding
This DAW cost 69$ and has excellent encoder support, a thing Cubase will likely never ever have, cause only dumb people work there.

I am pretty sure that Steve knows this stuff very well.

Steve-Bome Forum Moderator

2020-05-25 17:04:25

Hi,

I'm hoping this will help.  You can use this as an example if you want to use your C4 with Cubase as a generic controller instead of Mackie MCU.

For sending to Cubase, I'm converting relative CCs from the controller to absolute to send to Cubase.  I use MIDI Learn in Cubase and as far as Cubase is concerned they come in as absolute values.  I only programmed CC0-3. I store the calculated absolute value of the CC in global variables g0-g3 on messages going out to Cubase (Alias Application). (Translator 0.0)

 

----

For LED ring feedback, I again capture the feedback absolute value in g0-g3 so that the CC values stay in sync.

 

For conversion,  I take the absolute value and convert it to what the M4 should expect.

(Translator 1.0)

I leave the center detent off and the LED ring type to wrap. I left a line that can be uncommented if you want to change the center detent to on which is bit 6)

I also set the LED ring type here (bits 4-5)

I then scale the incoming value of 0-127 to a value of 0-B which is what I believe the C4 needs. ( I have no way to verify this as I do not own a C4).

I then OR the incoming value from Cubase with the LED Ring type and send it to the C4.

---------

It also seems that Cubase does not send feedback when turning the knob on the controller.

For this I use the same logic for local LED feedback (Translator 0.1) as I did for Cubase feedback (Translator 1.0). Note if you need to change the detent and ring type you will need to change them to match in translator 0.1 and 1.0

--

I made no attempt of updated text display since in generic Mode you will not see text coming from Cubase.  I guess if you know the proper SysEx format, you could convert standard CC messages to various SysEx messages to have some control of your text displays.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

 


Attachments:

C4-Generic-with-Feedback.bmtp

u-man

2020-05-25 21:49:37

Thank you so much Steve.

Here is what is happening:

Absolute values work, but in reversed. So turning left is inc. and turning right is dec. other than that, steps are +-1, so this works. Thumbs up.

The Feedback works, but only the one i do with my mouse. So turning i.e. Cutoff with the mouse, reflects correctly on LED rings. But turning the encoder, has no effect on the rings. Could be something i did wrong, either in MTP or Cubase or both (nah!).

Pictures of setup are attached. Nice work :)


Attachments:

Generic_1.png
Generic_2.png
Generic_3.png
Generic_4.png
Generic_5.png

Steve-Bome Forum Moderator

2020-05-26 00:34:56

No, I think you are doing things OK and both issues are related

I added the following rule to reverse (in bold)  the direction sent to Cubase.

tt=qq&15
// Reverse direction since last iteration
tt=tt*-1
if qq<64 then tt=tt*-1

Give it a shot and let me know what happens.

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz


Attachments:

C4-Generic-with-Feedback-a.bmtp

u-man

2020-05-26 01:49:25

Ok Steve, i already owe you one. My e-mail: u-man@arcor.de, send me your paypal name, so you do not have just  virtual cupboards of beer ;)

I am in contact with a Cubase forum member, who claims that he got working displays with a C4, similar to your initial approach (also used MTP for this :D ) and used a sysex rule that change the adressing of a MCU to a C4.

To test this, i would need a global rule that changes any outgoing sysex from Cubase from:

F0 00 00 66 17 12

to

F0 00 00 66 17 30

but leaves anything that comes right after this untouched. I hope i described that good enough.
Yes, i am aware, that this would be just one display, but for a start it would be good enough.
I feel so sorry now, but you need to understand, that i never monitored any incoming sysex, with the exception on turning on the C4 device.
Anyway, it seems that if you enter the \"instrument\" mode of the MCU protocol, Cubase will indeed send sysex out. It must be bad karma, that i never saw a sysex, so i thought that the whole display stuff, is happening somewhere else, somewhere unreachable for us. You were right, with everything, right from the start.
I attached you the project, that was the most promising from you.

I will test your last post, right away. You are the best.


Attachments:

V02_C4-2020-05-20.bmtp

Steve-Bome Forum Moderator

2020-05-26 05:58:26

Oh yea of little faith. Yes, I pretty much know what I'm doing as I've been at this stuff for a long while. ;-)

 

Well what you ask now is not as easy as you might think. MT Pro determines the start of a message by the status byte (high bit set) and cannot break up SysEx into different pieces.  I've added translators in case Cubase always sends the full 56 text bytes (plus the header and end of SysEx bytes) for each message but my guess is the length of the messages from Cubase might actually be shorter. It requires LOTS of global variables.  So what you will need to do is see how long the messages are, that are coming from Cubase and take off the extra bytes from the end (but not the F7) .  My guess is the messages will likely be much shorter than 56 bytes.

Also, I assume we are always starting at the first byte of each line which may not be the case. The variable rr is the start byte of the line and should translate correctly if left untouched.

The variable qq is the C4 display number 0x30 to 0x34 for displays 1-4.

Bottom line is for every virtual Mackie device, you need to put in translators like this for every possible length of bytes that Cubase  might send as the pattern and number of bytes will need to match exactly.

See translaters 4.4 through 4.7 for 56 data byte data messages. We use all global variables from ya-yz y0-y1 and za-zz z0-z1.  DO NOT USE THESE GLOBAL VARIABLES ANYWHERE ELSE IN YOUR PROJECT.

I would suggest monitoring Cubase and see if it is sending a consistent length of bytes and you might not need 56 combinations of byte lengths for every virtual Mackie devices. You might be able to get away with just shortening the existing patterns to something much smaller.

Remember the pattern length must match and the variables within them must also match.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz  (This is my paypal account)

 

 


Attachments:

V02_C4-2020-05-25-text.bmtp

u-man

2020-05-26 18:49:19

Hello Steve,

I think i understand what you are saying. That is indeed a little sad, so what is easy to see for us humans, is not easy for MTP. Damn.
The next problem and that is kinda big is, i can not catch any sysex coming out from Cubase/MCU protocol. This problem is what lead me to believe, your approach will not work in first case. So first i need to know, what i am doing so fundamental wrong here. I see sysex when i turn on the C4 or the Commander software for example.
I see sysex if i choose \"MCU\" from the Studio Setup preferences in Cubase and click ok.
But i do not see any other sysex coming out from Cubase/protocol, once the setup is made :/ and i seriously do not know why. From what other Cubase forum members told me, this is not right. They receive outgoing sysex, each time they enter a different mode. The only difference i see is, they have a real MCU unit.
Could it be that we need the stuff that is described on page 240 of the Logic manual:
https://usermanual.wiki/Apple/Logic.1909626546
Since this is not really happening on my side here. This is only happening with the Commander software, but not with Cubase/MCU protocol.

Since we both work pretty much handicapped: You, for not having a C4 unit and i for having only a C4 unit and by far not your experience.
I have some suggestions: I have a friend, who can borrow me a MCU. I think that will help us a lot, because i can better understand the protocol and i do not work completely blind with this protocol.
I mean if we are seriously need to catch any case where a sysex is send by the protocol and have a rule/translator for that case, we simply can not do this completely blind. If that makes a sense for you.

So for now, i think it is better to wait until i have such a MCU unit and then continue with this project.
I only have the fear, that once i have that MCU unit, you will have no time to help me further.

The last thing would be, please contact me privately via e-mail, unless you have no problems with discussing fees here. I have no clue, what you would normally get for such help.

Please consider that i am just a normal person with high ambitions. Covid-19 has ruined my financial situation. I have plenty of time, but nearly no income as a freelancer. Still i pretty much know, that your work should be valued, but i need to have some clue, lead, indication what would be ok for you.
I hope we can find a solution that is good for both of us. If my missus would know this, she would turn the living room into a war-room... i do not care :D
If this project lead to a success, i can convince other people that wants to use their C4 with Cubase to either buy MTP or collect some money from anybody who wants to use the final MTP project (like a small kickstarter project) that in the end belongs all to you.
I stand to my word, just make me some offerings, that are ok for you. I also stand to my word, that i want to help you anywhere i can in this project. I feel really dumb or like some child, to ask for all these things that i already did, but all the formulas and code, is not really something i could learn easily or in no time.
I still hope that all the findouts collected here, are showing you that i am not a total noob or fail. I really, really tried my best. The whole project is only possible for me, because i have a lot of time and need to keep my brain busy and far away from Covid-19 thoughts, if you know what i mean.

Greets, u-man :)

PS: The variable qq is the C4 display number 0x30 to 0x34 for displays 1-4.
Should not be that 0x33 (instead of 0x34) ? Would not that be 5 displays?

Steve-Bome Forum Moderator

2020-05-26 19:28:58

comment

Hi, I do not have your email but you have mine so reach out to me there for further discussion. Yes 0x30-0x33 not 0x34.

Steve-Bome Forum Moderator

2020-05-26 20:44:14

Hi, I did a little testing this morning.

It seems that Cubase likes to put out text of length 55, 3, 2 and 1 (not including Header and trailing F7)

So I created 4 additional translators (for Mackie 1 only) with these lenghts and am posting it here.

I also added a generic Mackie handshake answer which I use and works. I actually have a APC40 MKII Mackie emulation.

 

 

I modified the incoming text Sysex from Cubase for the new device ID of 14H instead of 10H.

Again, No way to completely test without an actual C4.

I hope it works!

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

I'm also attaching a text log file of the example capture I used. I was merely turning V-Pots to get updated display.

This whole project  should work only in Mackie Mode only (Not generic mode).

 

 

 


Attachments:

cubase-output-mackie-text-2020-04-26.txt
V03_C4-2020-05-26-text.bmtp

richardwhite

2020-08-14 01:38:32

I\'m so glad you guys are looking at this problem. I\'m having the same problem with my Mackie C4 and Presonus Studio One 5. I  had been working with Bome MTP trying to develop presets that would help me integrate these via C4Commander software -- and then I discovered this thread! I will follow your progress with interest..

 

Richard.

Steve-Bome Forum Moderator

2020-08-14 02:46:40

comment

Yes Richard, I think you mean thread and not threat but you might be right on both counts ;-) Steve

richardwhite

2020-08-14 08:47:07

But of course!  Lol. (I just corrected the typo)..