As far as I can tell, it’s only possible to use a single Generic MIDI control surface right now. Would it be difficult to adapt Ardour to have multiple controllers with different binding maps active at the same time? That is, instead of one “Generic MIDI” interface under “Control Surfaces”, have, say, three of them, or as many as one needs? I can work around that limitation by creating a single custom binding map for all the controllers I want to use, but that’s a little inconvenient.
Well, after some searching the only other recent thread related to this subject that I could find is FYI, can use two MIDI devices as Generic MIDI Control Surface for "Incomming MIDI on", though GUI only displays one. Which discusses how to use more than one device but only with the same binding map.
I’m curious why this hasn’t come up before. Maybe the recent rise of budget controllers with lots of built-in switches, faders and encoders makes this more apparent? Or maybe it’s just me? I confess that I have a bad case of MIDI G.A.S., especially when it comes to those cheap and cheerful controllers from AKAI and Nektar. 
But with MIDI controllers being so cheap these days, I bet that most Ardour users have a couple of them lying around in their studios. Ardour has binding maps for many of the more popular ones, but you can’t use more than one of them at the same time, unless you cobble together a custom binding map from existing ones. Is that what everybody is doing?
Robin, I’ve been looking at the code to find where I could add another Generic MIDI surface, but to no avail so far. I see that you recently refactored some of the control surface code, maybe you can point me in the right direction?
Pretty sure it has come up before honestly, but not much since the support for the binding maps was put in. Sadly I can’t remember much about the code these days (I used to know that better) to give you a good starting point.
I will say, that I would think that multiple surfaces would work, if set to transmit different MIDI channels on the surfaces, it wouldn’t make any difference to Ardour in that case, as it would still see a single set of controls spread across 16 channels.
What I don’t think would work right now is needing multiple ports (So multiple sets of 16 MIDI channels) as I don’t think Ardour utilizes more than one MIDI port for this.
Seablade
I’m pretty sure that it’ll work. In fact, I have a little mioXM box in my home studio, so I could make everything look like it’s just a single MIDI controller to Ardour. But I’d still have to cobble together a Frankenstein binding map to have everything just work. Which is doable, but not exactly convenient, and would need changing around every time my MIDI gear changes.
Ok, here is an example of such a Frankenmap: AKAI_APC_MPKminiplus.map - Google Drive
This combines the maps I have for the AKAI MPK miniplus (which has transport controls and encoders, but no faders) and the APC mini (which has faders and a clip launcher grid, but no transport controls or encoders). It’s doable, but neither elegant nor user-friendly. Instead, the user (me) just wants to add two Generic MIDI surfaces for two different binding maps and be done with it.
Maybe the Generic MIDI surface was never intended to be used like this. If no one else sees this as a problem, then I’ll go away now. 
I should maybe submit a pull request for the APC mini and MPK miniplus maps that I have (not the Frankenstein one). Ardour doesn’t have any maps for these currently, and they are fairly popular devices, so some people might find them useful.
Currently each control protocol can have exactly one instance and has unique port-names.
For generic MIDI, rather than changing Ardour’s Control Protocol Manager and the Control Protocol Interface, it might be easier have the generic-MIDI surface itself handle multiple devices.
Well, the protocol settings might become a little crowded if multiple devices and their binding maps all need to be shown there. But either way would be fine.
For the UI, I could imagine tabs.
1 Like
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.