OSC and plugins

First I’d like to thank all developers of Ardour, you have build up a system I REALLY love.

I’m using Ardour as a mixer and recording engine during live performances. By using a 16in/8out USB audio interface (Tascam US-16x08), Ardour gives me all the functions for managing small-medium band setups without high-cost pro-audio equipment.
Stage monitors are driven by dedicated bus-strips and internal sends feeds them with per-track audio source.

In the past, I performed mixing directly via the Linux box on-screen, but without a necessary multicore and limited space it has to be placed on-stage, which isn’t very handy over the time. To solve this, I started to use Ardroid but it gaves me only limited access. So I began develop my own Android app based on Ardours OSC interface which grows more and more to a full ranged remote control.
(https://github.com/onkelDead/ardmix screenshots at http://www.paraair.de/ardmix/)

What I miss regarding OSC communication is the list of effect plug-ins and internal sends each channel of an Ardour session owns. First, I am forced to use a fixed setup, and each time something changes, I’ve to modify the app to fit the current needs. As another solution, I’ve made some changes to the OSC implementation of Ardour, serving these information on request, but I’m not really comfortable living on this possible weakly Island.

REGISTER_CALLBACK(serv, "/strip/sends", "i", get_sends); REGISTER_CALLBACK(serv, "/strip/plugin/list", "i", route_plugin_list); REGISTER_CALLBACK(serv, "/strip/plugin/descriptor", "ii", route_plugin_descriptor); REGISTER_CALLBACK(serv, "/strip/plugin/reset", "ii", route_plugin_reset);

Please, do not understand this post as a deficit point-out, I only would like to discuss others thoughts about it.

Thank you very much for your interest in OSC control. I have probably done most of the recent work on OSC in Ardour. I would be happy to extend OSC to include your ideas. If you could do a feature request on mantis - http://tracker.ardour.org/my_view_page.php that includes the patch that would be best, but email to len@ovenwerks.net if it’s not too big will work too. I have recently added “AUX” separation in prep for “Cue” surfaces which are meant to be useful from a phone by talent to set their own cue/monitor mix. The phone would send /cue/set i Aux_number which would get the reply of all channels with sends to that Aux bus as well as a list of auxes (Aux = bus with no output to master). So the phone would able to set their own send levels.
Most of what you have I have added to the /select set of feedback. I have done this because most well used OSC surfaces like touchOSC work best that way. You are a step or two ahead of me.

As far as discussion goes, you have a working surface right now that looks very good. There is no reason for Ardour not to support it. If we can change it slightly to make other surfaces also able to use it, even better. I had not got to plugins aside from the Mixbus channel strip eq/comp. The little bit of work that had been done returns the wrong information too. So I would certainly like to see your Ardour code changes. I think I should be able to just add your code and then expand on it.

When will you make this mixer available to the masses :wink:

This app looks great; it could be very useful as a secondary controller as well!

Oh yeah, that sounds better as expected.
Yes, I’ll create a feature request on mantis. Due to your explanation, I guess separating aux sends and plugin control in two different requests is a good idea.
Offering the app for masses will lead in some additional work on documentation and usage requirements. I’ll proceed on it and will update the github repo asap.
If other users send me their experience with it will help me improve and/or extend the app for mine and other use cases. Please feel welcome:)

.onkei.; This looks good. I’d be interested. Great work so far.

@.onkel. I will drop the patches in as is and then make sure that they work for banks/strip_types as well. It has been suggested that it would be nice to see this in Ardour 5.5. So that is my goal.

@.onkel. Just so you know, The plugin and plugin parameter numbering is now 1 based. So the first plugin is plugin 1 instead of 0. So far as I know I have gotten all the /strip/plugin/* commands/feedback. If your SW only creates controls that /strip/plugin/list returns, it should not be affected. Do let me know if I have missed something or there are other bugs. Thank you for the time spent doing this, I have spent most of my time working on things for “mappable” control surfaces (AKA dumb surfaces) which can not create controls dynamically. I am still trying to figure out the best way to support things like plugins on a static surface… it will probably be a set number of controls where only those that are needed are active or in the case there are more controls than the surface has, bank them. There are already special case controls for Mixbus’ eq and compressor, but I am hoping we can extend that to the a-plugins for at least those two as well.