Is there a way to map LV2 plugin parameters (knobs) to an external control surface?
More specifically, I’m using a BCF2000 (via Generic MIDI for now) and I can assign the faders and rotary controls to Ardour’s faders and panners, and even LADSPA plugin parameters via the Ctrl+middleclick mechanism. This works fine. However, I’m unable to do it for LV2 plugins which have their own GUI. Is there a workaround for this?
I’ve looked in the Editor, if I open the corresponding track’s Automation menu and open the automation track of the desired plugin parameter… I can see nothing there, that would allow me to assign that particular channel to a control surface button or fader. Am I missing something?
Sorry, forgot to say that I use Ardour2 SVN head.
However, I'm unable to do it for LV2 plugins which have their own GUI. Is there a workaround for this?
No. It is a shortcoming of AU plugins as well, the external UI means that Ardour literally knows nothing about it to bind to be able to bind to it in the same way it does in other plugins obviously. I think it would be possible to bind to the automation channel and have Ardour respond like that, but it is not currently implemented, in part because there is no applicable control to bind in A2 I am sure.
@Seablade: I don’t believe this has (or should have) anything to do with the external UI - the UI, be it external or otherwise communicates parameter changes caused by the GUI controls to ardour via ports which are described in the plugin .ttl file and registered with the host. Likewise, if ardour moves a parameter via automation it tells the plugin about an event on a port and the plugin has the responsibility of relaying this to the UI and DSP code via whichever mechanism it chooses.
So, in order to automate LV2 controls via MIDI or other external events, it is simply a matter of ardour binding an event to a port. After that the same logic that allows automation events to action controls (and for them to follow on the GUI) will take care of everything.
This could be implemented without modification to the LV2 standard or the plugins. It could also be done via a general ‘MIDI learn’ option in the host. e.g. click MIDI learn, move a control on a plugin, then move a control on the control surface. The host then binds the two events together. Thereafter, each time the control is moved on the control surface, the host passes the parameter change to the plugin just like an automation event. This is how its implemented in DAWs such as energyXT (using VSTs) and the plugin needs no extra information about MIDI etc, it just sees events come to it as automation events (that are actually being caused by an external MIDI controller).
So, in order to automate LV2 controls via MIDI or other external events, it is simply a matter of ardour binding an event to a port.
I _think_ it would be possible to bind to the automation channel and have Ardour respond like that, but it is not currently implemented, in part because there is no applicable control to bind in A2 I am sure.
We are saying the same thing in different words. My first statement was in reference to how MIDI binding is currently handled in A2, which involves interaction with the UI of the plugin, thus why it is not currently possible to do this in the manner that is standard for Ardour currently. This is directly related to using a custom GUI that Ardour has no knowledge or control over really. But you are correct in that I believe it should be possible to bind MIDI to the automation port itself within Ardour utilizing the automation track(And ideally a fader on the automation track IMO that would represent the data present for drawing in TOUCH or WRITE mode without a surface and without doing it via drawing in each point). But it is not currently possible in A2.
@linuxdsp: the “difficulty” with the solution you outline is that it ends up being a 1-Plugin-API-at-at-time approach. What you describe would work for LV2 but not for AU (for example). The approach for both of those would be different than what is required by VST. Etc.
But yes, the “two-event” binding model (1 from MIDI, 1 from the GUI, somehow) is probably the best solution to this for the user. Alternatives include (a) using the controller displayed in the relevant automation track for a plugin (b) using MIDI binding maps which allow direct specification of a plugin parameter © offering a “generic” (ardour-created) plugin GUI for all plugins as an option. The first two are implemented in Ardour3 already.
@seablade: you’re right, but when I saw the thread, I was just slightly concerned that it might develop into all kinds of notions that more LV2 extensions were required, or that some fundamental change to existing architecture was needed (which could also cause a lot more work for plugin developers etc) or that it was in some way thought to be a failing of the LV2 UI extensions. However (as I think we are both saying) the automation mechanisms in ardour could already provide all the functionality that is needed to bind an external event e.g. from a MIDI controller to a control (on a plugin or a control within ardour itself) without the need for modifications to any plugins. And the MIDI learn mode I suggested could be triggered by a generic option in one of the host menus so it wouldn’t require an extra button on the plugin UI etc.
I believe this subject came up briefly on the LAU list a while back and I put forward the same ideas, but Paul pointed out that although this isn’t available in A2, A3 allows you to bind (plugin) ports to MIDI controllers, which I think would / does provide the same kind of functionality.
@Paul: Yes I see what you mean - I guess really I was just saying that tapping into the automation mechanism seemed like a way to add this functionality in a ‘plugin agnostic’ way since I assumed that all plugins / controls etc could read / write automation events, and as I mentioned in my previous post, you did point out a while back that A3 allows mapping between MIDI events and controls in a way which should (I think) enable this functionality, so in theory, it will become less of an issue as A3 becomes more ‘mainstream’
@paul: also - out of the options (a,b or c), for what it’s worth, I favour option © the least - DAWs such as qtractor have a host generated UI which pops up in addition to the plugin generated UI and I find it leads to a lot of extra clutter on the screen if it is not managed properly. I think the behaviour of the UI is fine as it is, in that if the plugin provides a UI then it should launch, but with a fail over to an ardour generated UI if the plugin does not provide one. So that just leaves options (a) and (b) which as you say are already in A3.