What are the information that are sent back to a controller to sync it using the MIDI sync option ? The GP MIDI monitor doesn’t display what is sent back to the controller.
I just bought an Icon Platform M+ Control surface that I use in « user defined » mode, relying on the MCP protocol. I can control all my GP widgets with it, but only the motorized faders are perfectly synchronized, The knobs values are not updated, and the LED buttons states are not activated. At the end the MIDI zinc option will perhaps not work for me, as I also synchronize everything via OSC with the mixer software of my audio interface (TotalMix Fx). Well, I would like to learn more about the information I am supposed to send back to the MIDI control surface to eventually synchronize it by hand.
Right now we are only supporting basic CC messages (and just one per widget). At some point we will add support for some of the standard protocols but we just didn’t imagine many people going on stage with sophisticated control surfaces like that.
OK, I can do it by scripting, but I have no idea in which direction I have to look for to go on. I even have no details regarding the MCP protocol which seems limited to sending single CC, pitch bend and noté MIDI messages. What which kind of message am I supposed to send back? Is there a known standard protocol to follow ? What is sent back to the faders for exemple ? The faders are perfectly synchronized.
If the faders are perfectly synchronized then you can see from the widget MIDI learn what’s being sent — has to be just single CC events, a different CC number for each fader. I haven’t really looked at control surfaces much myself.
So if a fader sends a CCnnn with value xxx, the GP sync process consists in sending the same CCnnn with value xxx back when synchronizing ?
When this control surface is used in Mackie Control Protocol mode with a DAW, it seems that the DAW can light up the LEDs so I suppose this is part of the MCP standard. But unfortunately, I didn’t found any documentation about MCP.
On my Behringer X-Touch Mini, the CC values of the turning knobs are synced with the connected fader and knob Widgets, but any sync of the buttons and alike widgets (buttons, LEDs, switches) doesn’t work, even though they are using CC# too. Why is that?
@schamass, very odd. I always remember mine sync’d with buttons. I’ll have to try this afternoon. In the X-Touch MINI editor, do you have the buttons set to Latched?
The brief history, as I understand it, is that Emagic had Mackie build the Logic Control controllers that were the predecessor to what survives as the MCU Pro controller to this day.
After building the Logic Control unit for Emagic, Mackie built its own that it aimed to sell to the rest of the DAW world (e.g., everything other than Logic) so as not to directly compete with the Logic Control series it was building for Emagic. That was the HUI.
They later combined the Logic Control protocol and the HUI protocol into what is the Mackie Control Universal Protocol, which is what is still in use today. My understanding is that the “universal” nature was that it simply combined the HUI protocol and the Logic Control protocol.
Beyond that, it seems like Mackie has tried to keep the internet free of documents that fully detail the protocol, so everyone that builds some kind of “unofficial” software interface has had to recreate it. I’ve owned a Behringer BCF-2000 for a lot of years, and been through this nonsense in different DAWs.
Here’s an official document detailing the protocol from the original Logic Control boards. Somebody else linked the HUI protocol above. I’m not confident you’re going to find anything more instructive than those. (Or you could look at somebody else’s code, such as Klinke’s Reaper scripts.)
Having looked at all this years ago, let me pass along one other thought that might help.
As I recall (and it’s probably in those manuals) the details for the faders is easy. The fader sends a position value, and it responds to position values sent back to it. Not really much to get confused about there.
The rotary knobs are very different. They send relative movement info, but display something absolute on the light rings. So what they send and what they expect to receive back are different. I recall another layer of complexity on top of that as well. Like you can set them for different display modes. Such as just lighting up one point (where the knob pointer would be) or lighting up a portion of the ring, from say the 7 o’clock position through the 2 o’clock position.
And then you have the 7 segment LCD display and all the bank select stuff. All that stuff is what makes it hard, and Mackie seems to want to keep it hidden for some reason.
Yes, i am. I just checked it again: The Behringer is in standard mode (MC LED is off) and when i press one of the buttons, in the MIDI monitor the CC values come in as expected.
Sorry, I misread that last post - you’d have to use a Windows Midi Monitor to see for certain what GP is sending out but, assuming you have Sync turned on, GP widgets should be sending out exactly what they received (except for Note messages where we’ve just discovered an issue)
You should also take care to the fact, that during the MIDI learning association phase, only the last MIDI event is recorded. If you push and then release with the learn button activated, only the released info is learned.
EDIT: OK if it is a CC event it is different
FWIW I am using an x-touch mini and have had no issues with syncing the buttons with GP. I am using it in standard mode and converted the top row to CC (I think by default they were all note messages).
The x-touch mini buttons are set to latching, and in GP midi monitor I can see it sends the alternate value 127 and 0. After mapping widget buttons in GP and activating sync it works as expected, including on rackspace change.
The only time I saw an issue was where I realised I had accidentally set one button in the x-touch mini to send the same value for min and max. But the midi monitor quickly showed the issue.
