Novation has a famous feature called AutoMap for its Remote Zero SL midi control surface. It allows you to store presets for your applications and when your applications becomes the active window, it automatically loads that preset.
So for example, when Propellerheads Reason becomes the active window, your Reason presets automatically load. Then if you click on Pianoteq, your Pianoteq midi assignments would automatically load.
Right now, this feature is implemented for Windows on the application level via an AutoMap Server that developers must code into their apps.
Is it possible for Ardour to create such a feature without requiring devs to recode their apps?
This can be done, but it would be stupid to make it an Ardour feature.
You’d want some small standalone app that watched for window-manager-related events concerning top-level window focus (X11 doesn’t have a direct comparison to the concept of “active window” - the closest is “window to which key press and release events will be delivered”). it would then do what was necessary.
Defining what is necessary at any point in time is the hard part.
The function of AutoMap (according to your description) is to change the function of the controller based on the selected app. As Paul said, this is not something you would put into Ardour itself, but into the controller mechanism.
It looks like maybe what you are after is the “reverse” of AutoMap. You want multiple controllers to have “presets” that control Ardour. This is certainly possible. There is already a framework to map MIDI and/or OSC controls to Ardour, and someone could create a mechanism to switch between control maps on the fly.
However, because Ardour is an open-source project, there is even more flexibilty than you will find in a proprietary app. It is possible for manufacturers to control Ardour in a very “deep” tightly integrated way. When the ramifications of this becomes clear to the controller manufacturers, then we will see some serious innovation in this field.
I’ve been thinking on and off about this sort of thing for a while. Let me get one thing clear first – Ardour is not the place for the lion’s share of the work. That is a background daemon/server process that effectively runs an event and messaging subsystem.
Basically Ardour will listen to events, do something and possibly give feedback
when something under Ardour’s control changes (e.g. if you move a fader in Ardour with the mouse, and e.g. a rotary encoder on a BCR2000 is mapped to it, the rotary encoder should be notified of the change). How exactly depends on the design of the automapping system, and doing a fully general system is not easy.
There needs to be a separate project that talks with developers of audio applications to think this out. Certainly it shouldn’t distract from other pressing issues with Ardour.
Is anybody interested in discussing how a free automap like system should work? (As an Automap Universal on Mac user myself, I consider the current implementation far from perfect, and a free open system is the way to go.)
JohnAllSup, I just have to say that this thing is actually the thing I’ve been hoping for for a long time! That would really be a superb piece of software.
the closest i can get to an understanding is that people want multiple apps connected to a single controller, and some way to make sure that only one app at a time gets events from the controller, without changing the signal routing. as the GUI “focus” moves from one app to another, the target for event delivery would follow it.
as i mentioned above, this doesn’t need any interaction with audio apps at all. you need an app that interacts with the window system (on X11, with the window manager) to track changes in whatever should be considered the “active” window. that app would also be the only place that MIDI (or whatever) would arrive; it would route the events out to the relevant app based on the window state.
this is not an ardour feature, and it doesn’t require any work by ardour developers or developers of other music apps.
I kind of see paul’s point. What I am about to write makes heavy use of the word virtual…
What you really want is to virtualise the control surface so that each app sees a different virtual control surface. You connect the virtual control surface to the app, rather than the real one, and this virtual surface remembers the values of its virtual controls. When an app becomes active, the active virtual surface changes and the virtualiser then updates the hardware to reflect the selected virtual control surface.
That much requires no additions to ardour, though would require creating and destroying midi ports based on the apps currently running.
What e.g. Novation Automap allows is multiple ‘control clients’ per app, so that each plugin also gets its own mapping to the hardware, and the automap server lets you choose between them. Currently Automap accomplishes this with a hacked workaround that involves wrapping AU and VST plugins and using a wrapped version of the plugin in place of the original.
If you had a client-server virtualisation system you could do something similar, and that too would require no work in ardour.
I’d envisaged a much more comprehensive system, though couldn’t figure out the best way to go about designing one.
I know this isnt the solution that your looking for,
but as a workaround for the time being, can we not use MIDI
channels to route one Keyboard/controller to every App we want?
I mean, Hyrdogen (or whatever) on channel 16, then start
a Qsynth on channel 1, 3 ZynSubAdd’s at 2-4?
Im doing that at the moment and it works perfectly!