I don’t want to accept that it is not possible, but rather write a software that enables its full potential. I don’t know where this will be going and am seeking your feedback.
record arm for tracks (the whole “select action, then channel”-functionality the device is built for)
switch Ardour Editor/Mixer view
select a track and control a selected synth plugin without the need for manual remapping.
I do not have a Pitch wheel so far, so I want a knob to act as one on a different JACK Midi out.
Maybe transport buttons
I got inspirated by Jürgen Moßgrabers integration of the APC40 into Bitwig where he switches between different layouts with the help of a controller script for Bitwig (as I understand, that is not possible with Ardour): https://www.youtube.com/watch?v=rSNJHAGSeRo
The Launch Control XL sends MIDI note commands for all of its buttons/faders/knobs except for the 2 template buttons.
I am focusing on Linux/JACK and ideally it should work with any DAW.
I am a programmer, know C++ and a little C and would also be comfortable with the LUA scripting of Ardour if necessary.
My current plan is to write a JACK client that acts as a proxy. It would remember the “state”, light up LEDs to reflect the state and translate MIDI commands based on the state. On the Ardour side, I hope a MIDI binding map would be enough.
I am appreciating your input! How would you do it? Can I set an active channel in Ardour by MIDI messages? Do I need the LUA scripting?
What functionalities would you want?
Going via JACK will not work for Ardour users who do not use JACK (Ardour has not needed JACK for several years).
We do not currently support the idea that control surface support needs to be scriptable in a non-compiled language. There is a suprising resistance to working with a compiled language (such as C++, which Ardour is written with), and yet you can do do everything that way without requiring anything from Ardour itself. We have already implemented support for several devices in this way, and this is how we encourage development of “integrated” control surfaces now and into the future. For us, it is no better having a bunch of lua (or, as in Bitwig, Javascript) files floating around, just because “some people don’t want to have to compile”.
You can see all the code for the Push2 and Maschine (among others) in our existing source code. At some point in the future, we should probably consolidate quite a bit of the code used in these modules, because there is very significant overlap. But for now, feel free to just copy-paste-edit.
A binding map will not do what you want, I am fairly sure of that.
Hi Paul, thank you for the feedback. I don’t really get your point about compiling hesitance though. I AM compiling a JACK client, so it is not about to compile or not to compile And I do not WANT to use Lua, I just saw it mentioned in the manual. Let’s just say that I find Bitwig’s approach of control surface scripting very compelling. But I don’t care, at first I just want to use the device. If it fits Ardour’s needs or there is something reusable for somebody else - even better
Do you mean I shall put my device support inside the Ardour codebase? I am of course sure that would work nicely from a technical standpoint.
Sorry, I don’t know the community and development model yet. If that is the way the devs prefer device support, I might consider doing that.
What I have so far is a simple JACK Midi proxy that keeps state and can easily be made into supporting the special Mute/Solo/Rec Arm buttons for tracks with Ardour. I am nearly there already. I just translate 2 buttons pressed at the same time to another MIDI note output. I think that is a simple approach and the advantage is that it is not Ardour dependant.
If Ardour would output MIDI commands with the current selected track and maybe the number of plugins in the track I would be able to do the rest also in this way. Wouldn’t exporting the current DAW state be an interesting idea? Maybe via Lua… (just teasing ) - or in Ardour’s code? I feel that this would open nice possibilities for easy interfacing with Ardour.
I feel a little advantage in this approach in that we are not developing something too Ardour specific but more open to other programs.
(And sorry, in this project I do not care about Windows or Mac… yet)
Increasingly Ardour users do not use JACK, so implementing stuff as a JACK client cuts out more and more potential users over time. It also prevents easy cross-platform use, which you might not care about, but we do.
Yes, many people seem to think that implementing control surface support in a scripting language (i.e. without having to recompile Ardour) is a MUST. Ardour developers don’t agree, and we’re not planning on working to make this possible. Bitwig’s developers seem happy support Javascript for this purpose - we’re not.
Yes, you would put the support into the Ardour codebase, inside the libs/surfaces tree
There’s nothing about the Launchpad that I’m aware of that requires any special treatment that would differentiate it or make it eligible for such different treatment than, say, the Ableton Push2 or Native Instruments Maschine.
I do understand that “you must be able to compile Ardour” as a pre-requisite to “add support for a complex control surface” is a barrier to some people. But I personally like the barrier. I’ve read some of the JS surface support for Bitwig, and it doesn’t speak well (to me) of the people who wrote it, or even the basic surface support constructs that Bitwig exports.
Thank you. I understand your point and see its benefits.
I’ll probably go ahead and finish what I have in mind as a basic means to enable the Launch Control XL for all “learnable” DAWs within the Linux JACK environment.
If I stick with Ardour and want deeper integration I will implement it in libs/surfaces. I just compiled git-master (I guess you would want patches there) and peeked at the push2-code…
Note that at this point in time (sept 2017), git/master is undergoing a major re-design (6.0-pre) and it’s barely usable, but yes for contributions it is the way forward.
To elaborate a bit on paul’s point #2. Closed source DAWs do not have the option to expose the internal API directly, so scripting languages and/or an indirect API are the only option for them. Ardour (and its derivatives) does not have this limitation: tight integration is possible. Also the distribution model is different: Once support is in Ardour’s codebase, everyone just has it - you don’t have to get 3rd party scripts from someplace.
And I do not WANT to use Lua, I just saw it mentioned in the manual. Let’s just say that I find Bitwig’s approach of control surface scripting very compelling. But I don’t care, at first I just want to use the device. If it fits Ardour’s needs or there is something reusable for somebody else - even better 