Well, if you read that book, then maybe you want to hear about what I think about how MRs could handle this situation intelligently, without burdening the Script writer too much, and let there be an interface through the UI MR designer. Because that is what this book is about below.
Say you want to control Fabfilter pro-q3 with an MR. There is this concept of Object Oriented User Interfaces. This is distinct and different than Object Oriented Programming. In fact the naming similarity has a history that is inverted from our modern expectation. (PM me for references I don’t feel comfortable name dropping here.)
If you think of the pro-q3 as a Class, and each insert as an Instance then it becomes a matter of Focus. (And I am hoping that is where things are going here, because of the Focus Quick Control name.)
If you select a track and it happens to have 1 Pro-Q3 on it, then , that is the plugin under Focus. If there are more than 1 insert instance of the Pro-Q3 Class then you have to have some way of making the 2nd or 3ed etc. the one “In Focus”. A next/previous, or the user selects it with the mouse or arrow keys or whatever.
Whichever one is “In Focus” is the one being controlled.
In this way you could go to an instance of Pro-Q3 and right click and make assignments to whatever surface elements on a given page you want. Then it would be bound to the Class of Pro-Q3, not the instance of Pro-Q3 you used to make the assignment with.
This would greatly simplify everything, when making bindings through the UI, and would match the intuition of the user!
“I made this knob control the knob on Pro-Q3 and now it controls that knob for all Pro-Q3s depending on which one I am looking at., or focused on.”
It wouldn’t require any sort of list retrieval or filtering in the scripting. It would just be whichever instance of the given plugin was “In Focus”.
This could be achieved by providing more than 8 FQCs and it makes for a nice tidy way of defining directly which controls are mapped to what. But it requires indirection by the user!!!
The user has to think through which controls they are assigning to FQCs and how their layout maps to FQCs etc.
Why not map directly to the Surface already defined rather than some extra concept of Quick Controls?
This, would completely alleviate the need to create extra MIDI tracks just to pass controls along to an instrument or plugin. Well, it would if one could also define expressions through the MR as well!
So, what about expressions?
That is where the Idea of a Secondary Mapping would come in more handy than it does with quick controls. There is something secondary to map to rather than just an enumerated list of controls.
So the user defines a control on a given page as controlling Vibrato. Done, now it’s up to the VST Instrument to provide the appropriate mapping to The Vibrato Interface Class. And if they don’t then the extra controls for a given Class of Expression can be defined by the user.
The user’s experience would be:
“I want this control on this page to control Vibrato”.
Then they open a VST and move the fader they assigned to “Vibrato” and it works.
If it doesn’t work, then they can select the UI element on the VST UI that says Vibrato and select “Assign to expression” and select “Vibrato”.
But you say, there is no UI for vibrato in the VSTi.
That’s fine, you select the Exp icon at the top of the UI window right about where the F is now, and find Vibrato and assign it to ,(say it’s Spitfire?) ok that’s CC21. Done.
Now your “Vibrato” assignment in the MR will send Spitfire CC21 when Spitfire is In Focus, or when Focus is locked.
The complaint here is, well, what about “Tightness”? How do we assign that? Spitfire doesn’t even have tightness in every one of their instruments, Tightness is kind of unique, and it’s something different elsewhere, like maybe " Pizzicato Length" or something weird like that. Well. Pick a name, or better yet,
Let the User define the Expression Class and then define one or more instances to it.
You only need to know that Spitfire is what you call " Pizzicato Length" is CC18, not that it’s called “tightness”, and maybe they want to map more than one expression as well. Fine, let them pile it up as much as they want.
The point is, they either pick from a pre-defined traditional set of expressions, or they define their own and map a control to that expression. Then map Expression Classes to one or more specific controls or CCs for a given instrument.
For Amp Sims you have “Wah”, and “overdrive” etc. Either mapped automatically by the Amp Sim manufacturer to the available Expression or created by the user, as a mapping to a control already assigned to that Expression on their Midi Pedal.
With this there would be no need at all for those extra MIDI tracks all over the place, requiring so many extra PLEs to make sure the focus is correct. And it is really intuitive and easy for the user, who only has to occasionally think about what CC they are actually using when they do the initial mapping, and most of the time, they won’t even care about the CCs at all.