Mackie Control - Security Unlock Failed

Installation & Configuration Linux
#1

I have a number of Mackie Control components that are working fine with other applications, but when connected directly to Ardour they close down with the ‘Security Unlock Failed’ message as soon as Ardour connects to them with the default control surface profile that’s provided with Ardour6.

By writing my own application gateway to service them and just exporting a few generic controls to Ardour, I can make most things work. But I don’t know how to get Ardour to send non-SMPTE data for displaying in time code display. My application translates MTC ok for the Mackie Control display, but I’d really like to get bars and beats mode to work.

You might wonder why I want to use my own application as a gateway between my control surfaces and Ardour. This is because I want a number of control surfaces active at once and to be able to rapidly switch between controlling a number of devices from them (including outboard and embedded mixers in my audio interfaces and remote transport controls by the piano and a large, home made meterbridge and so on…).

I have not debugged what Ardour is sending to the Mackie Control devices to make them shut down.

What I’d like to know is:

  1. Does anyone else have a security unlock failed message when using Ardour with any of the Mackie Control family? (There’s plenty of evidence of this problem when using other DAWs when googling for this issue). I am using Ardour 6 and the Mackie units I have are the original non-pro ones with various firmware versions in them (but with new LCD backlights).

  2. Is there an Ardour setting that will send bar and beat timecode display to a generic ALSA sequencer MIDI port in the same way that just turning on ‘Send MTC’ does ? (Clearly I can add this feature by recompiling Ardour).

Many thanks

DJG

#2

I have not used my MCU Pro in a bit, need to replace one of the faders that is sitting on my bench waiting, but had not run into this before.

Seablade

#3

I have an SSL Nucleus and Mackie MCU Pro. I have never ever seen this “security unlock” message.

Ardour can support any number of control surfaces at one time. The only limitation is that if you have more than MCP device, you need to create a device info file that describes them as a single unit, I regularly test with one of the MCP devices, a Faderport and a Push 2 device, all active at the same time.

Telling Ardour to sent MIDI Clock will do what you want. It’s not appropriate to use the term “timecode” for this, which is generally reserved for video-derived time formats.

#4

Dear Paul,

I’ve not debugged the unlock code. It could arise depending on which of the three modes the Mackie Control units are in. I use their ‘emagic’ mode since for this one I know how to control the LCD using exclusive messages. Hence I am not concerned about it. I can capture the full exchange of messages if anyone is interested.

The MIDI clock does not embody the time signature or time signature changes, as far as I know, so I am not sure whether MIDI clock is really helpful.

I’ve found another few things I’d like to be able to control with entries in my own custom generic MIDI map file, but I don’t know if they are controllable or if they are, what their name is, despite reading the Ardour source code. Two are click and loop: I note that ‘control middle click’ on metronome and loop play do not facilitate remote learning and hence control of these two buttons. I can possibly do loop play via MMC but I am not sure, but how to turn click on and off remotely?

Also, I’d like to send a ‘motor refresh’ command to Ardour over generic MIDI so it flushes out the value of all control surface values, such as Solo LEDs and fader/aux positions. Is there such a command?

I also have a problem with toggling Mute and Solo buttons, although I imagine this works properly with something like the nanoKontrol (1 and 2) that I have, so I can debug how that works if it does. For instance, for Solo, using generic MIDI, the problem is that Ardour correctly updates the control surface LED when operating a Solo via the Ardour GUI. Moreover, Ardour correctly updates its GUI when receiving a toggle for the Solo from the control surface. But, Ardour does not send a response update to the LED on the control surface when toggled from the surface, so the surface LED is then inverted. This can be solved by locally toggling the LED inside the control surface, but this is a poor approach since state is duplicated and can get out of synch. So better is for a DAW to echo or confirm such a command, as is done with MMC. Using a different confirm message is preferable, but using the same command is also no problem, since I am not in any danger or a feedback loop. Ideally, Ardour’s XML entries in the .map file should support an attribute to indicate whether a confirmation should be sent. Moreover, without a ‘motor refresh’ request, as mentioned above, the only convenient way of resynching the control surface seems to be a project save and reload, which seems a bit heavyweight, but does kick off with such a flush of all state down to the control surfaces.

Also, I casually wonder if anyone is working on the monitor section of Ardour so it supports both control room and studio outputs? An external studio controller does this job and also supports a foldback mic, but I would imagine someone might be building that in to Ardour? Actually, have a separate hardware foldback is a good idea since latency is lower and you can still communicate with the studio during a reboot.

Thanks for any suggestions.

#5

“Emagic” or “Logic” mode(s) do involve the “secret handshake”, and I don’t know that our implementation of this has ever been tested. It’s such a stupid design feature. Thankfully the Mackie devices I use do not use this mode (certainly not by default).

There isn’t really a good protocol for communicating time signature, particularly because the ones that do exist have no mechanism to say when it changes, only what it is “now”.

There is no MIDI controllable “parameter” for the metronome. MIDI learn works fine here for the loop control (but you need a loop range defined before the button is sensitive).

Looping via positional sync protocols is ugly. MMC cannot do it.

Generic MIDI feedback (which seems to be what you are using in the mute/solo case) isn’t really very developed or tested. It’s not really intended to be particular useful - generic MIDI support was developed primarily around devices that can’t use feedback. I imagine it would need some significant mods to work correctly with those that can use. Devices with LEDs and so forth have generally been supported with dedicated code, not generic MIDI support.

There is no “motor refresh” command.

Nobody is working on the monitor section. It’s not intended to have dual outputs - it’s intended purpose is to replace the master as the output routed to the monitors you’re actually listening to. You could just route the master the studio main room(s), for example, though I’m not sure what that would be useful for, or use foldback busses for in-studio monitoring.

#6

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.