I am running Ardour 6.9 on Fedora FC31 and I have a problem with the solo LEDs on my control surface. The subgroup (audio bus) solo LED gets out-of-step w.r.t. the correctly working indicators on the GTK interface (mixer end editor). The problem arises whether I change the solo status from the GUI or the control surface. In other words the problem is only on output from Ardour to the control surface.
I am using the genericmidi control surface and have simple bindings for the solo leds of all channelstrips
The problem I have is that when I solo a channel that feeds to a bus, all is fine and that bus is solo’d as well in audio terms, so that I can hear the solo’d material through the monitor. But when I unsolo that channel, Ardour is turning on the solo led on the control surface for the subgroup. This is wrong, since no solo is then active and all solo indicator’s are off on the GUI.
The silliest manifestation of this is that I can press the solo clear button on the top of the centre top of the editor GUI and it turns spuriously ON the subgroup solo LED on the control surface, but works fine otherwise.
Does anyone else have this problem and how can I change Ardour (I am happy to patch the src code) so that this behaviour goes away? I just want it to reflect what it is displaying on the GUI to a genericmidi control surface.
I doubt that this can be made to work correctly for generic MIDI support. Solo is a deeply complex area (much more so than most people would think), and representing the state correctly via a simple on/off msg for an LED is not likely to be able to follow the logic.
It works for Mackie devices etc. because there is explicit code to handle the complexities of solo status (and thus to decide when/if to turn on the relevant LEDs).
Although I agree solo is quite complex, I believe what I want is perfectly achievable. Afterall, I’m just seeking to remotely echo some of the state of indicators already on the GUI.
The underlying control surface I am mostly using is a gang of three Mackie Controllers, but these are combined with others and multiplexed over a variety of devices using an intermediate alsa midi routing program of my own creation. This enables me to adjust quite a few other devices, such as fluidsynth detailed parameters and the alsa mixers exported by my focusrite interfaces (with augmented device driver) used for foldback.
Having written it myself, I have complete control over the behaviour of my ‘control surface’. It already includes code that gives correct LED Ardour behaviour for the rec ready, solo and mute leds for a given channel (perfroming local integration of surface button presses to control the solo and mute leds while responding to absolute value updates from Ardour when the same features are adjusted via the GUI). I’ve also already augmented the generic midi Ardour surface code so that I can control many more things: the automation mode of a track, control the click, global solo clear and remote VU metering). I perform scribble strip update using a backdoor that watches for the track names of visible strips in the most recent ardour save file. Everything is working very well within a channel.
So you can see I’ve already made a massive amount of progress on top of the generic midi code provided. It’s just the inter-channel solo LED that seems odd at the moment.
I exepect I can look at the solo_control.cc file to understand why Ardour seems to be emitting a solo ON message when solo is turned off, but I would expect you to have a better idea of which lines of code to look at! Many thanks for any pointers.
The problem is that if you use busses, the state of the GUI solo buttons is a tristate. There is not just on/off, but “explicitly on”, “implicitly on” and “off”.
If these are Mackie devices, I don’t know why you would not use (and potentially modify) Ardour’s mackie support, which is far more capable and flexible than the generic MIDI support (which essentially simply mirrors back inbound messages).
Ah yes, user interface design is certainly a matter of personal preference.
One reason is that with my approach I can keep the transport controls jog/shuttle wheel and time code display connected to Ardour while using the faders to control external devices (such as foldback) and then, at a touch of button, have the same faders connnected to Ardour’s automation.
Another reason is I can have multiple control surfaces active at once in different rooms, whereas I think Ardour’s built-in support only supports one active control surface at a time. [I know I can bind MMC and MTC to several devices using the midi patch window, which would be another way. Or even use OSC I exepct.]
I don’t really need the tri-state indication of the solo indicators to be reflected on the control surface, (although the LEDs the Mackie ones have are tri-state too, having a flash mode): I want the three states projected down to two and certainl not for the subgroup solo light to be turned on after I’ve cleared a solo.
Also, as we discussed before, the built-in Ardour Mackie mode made my surfaces give a “bad control code message” and lock up. This is possibly because they were in the wrong one of three operation modes, determined by powering-up while holding down various keys. But I did not know which mode you supported and I was not interested in debugging that because I want the increased flexibility of my approach.
Anyway, I’ll look further at my problem and see where the source is. I don’t think it’s something I’ve done, but it could be.
Our Mackie support allows for any number of Mackie devices, with explicit physical layout so that you know which faders are which.
There are no “modes” for Mackie Control. There is one protocol, defined by Mackie. I don’t know what “bad control code” could be (that error msg doesn’t exist as-is). If there’s a problem with an actual Mackie Control device, we want to know about it.
What is being referred to here are surfaces that allow them to switch between a couple of different protocols, in this case it could be that the surfaces were in the logic control protocol, as opposed to the Mackie protocol, which are actually different protocols, but very similar. I can’t remember the third protocol supported on Mackie surfaces and don’t have mine in front of me right now but I believe it was specific to ProTools IIRC.
Logic Control is identical to Mackie Control except that it has a handshake at the start.
The “modes” are normally just a remapping of certain buttons so that they send different messages. The protocol remains the same, the total set of all possible buttons remains the sames, etc.
There may be only one protocol, but the surfaces that I own have three operating modes, so I’m saying I perhaps had the lock up problem owing to the surfaces being in the wrong mode. The three modes are briefly described below.
On the message shown, I’ve just checked back and the actual error message displayed on the LCD of the Mackie units before they lock up was ‘Security Unlock Failed’. Sorry for not being more accurate just now.
Another use case is when you want to have duplicated control surfaces in the control room and live room; with the old Mackie interfaces using 5-pin DIN midi, you can parallel the midi out and use a midi merge on the midi in. Because the interfaces are stateless, this worked perfectly. With USB control surfaces it is not so easy to solder up the equivalent wiring! Having two copies of a given channel strip is probably not one of the ‘explicit physical layouts’ you support…
Anyway, there will always be lots and lots of use cases in various scenarios and this is irrelevant to my posed question. If the Mackie and other customised surface options work correctly for subgroup solo LEDs then I expect it is a simple matter for me spot the difference between a working one and the current generic midi surface code which seems to be misbehaving. Then I can patch it.
Power Up Mode Change
Hold down both the Ch 1 and Ch 2 SELECT buttons during power up.
Hold Ch 1 V-POT and SELECT buttons during power up.
then
Press V-POT 1 for "Mackie Control Universal - by Mackie Designs, Inc"
Press V-POT 4 for "HUI Emulator Mode" ... Gives a lines and bars view on the big display.
Press V-POT 7 for "Mackie Control Universal - for Emagic Logic Audio"
So, 3 different modes: Mackie, HUI, Logic Control. HUI is a different (though similar) protocol designed by the same person for Digidesign, and is not Mackie Control. Logic Control is the same protocol but requires a “security handshake” because Apple/Emagic designed it that way. However, even Logic has normal Mackie support now and the so the handshake thing is really dead at this point. That leaves “V-POT 1” mode as the only relevant choice here.
Yes, it’s long been desirable to potentially run > 1 instance of any of our control protocol modules. However, we’ve deferred this because we/I’d like to do a complete refactoring of all related code first (there is way too much code duplication among modules, and we could make creating new ones much easier).
I now think it’s all my fault. Ardour is behaving perfectly. The code that I am using to receive the midi messages must be faulty, since Ardour’s own reporting of what it is sending and also routing the midi to another program both show the expected messages.
Sorry for beign silly and wasting everybody’s time and any implied criticism.
