Hello, lately I’m thinking to adapt as many as possible of my instrument plugins by using the remote editor, so that I get a persistent way of assigning their parameters to my controller’s encoders, faders and buttons.
The way I see it, I should try to “fix” controls to certain plugins’ parameters. For example, I think I should have the envelope’s ADSR in a set of four faders which will be the same for all my plugins in a (sub)page, while getting my LFOs in another subpage and so on.
Even more, I think that I should map all (OK, maybe not all, but at least the crucial ones) in a way that fits my surface, i.e., a fader style param, mapped to a fader, a toggle mapped to a button, you get the idea.
This thread is about asking opinions/ideas on how we could or should implement a, say, “Standard” or “Universal” approach for the main parts of our plugins. I do know there are “exotic” params here and there and I also understand that every user may have his/her own preferences, BUT there should exist (in my opinion) this “Universal/Default” mapping.
IF such mappings exist already, I would appreciate a link so that I can test how to proceed.
If it is of any help, I’m thinking to follow the assignments of a hardware synth.
There are so many out there, I should choose one, or maybe combine the “best” of more than one.
The plug-in developer sets the order of the parameters. Then you can see the order at Mackie device or if you switch the plug-in to the Genetic Controls view.
Yes, ok. But do parameters know what “type of control” they are? Does a parameter that resembles a fader in the GUI “know” that it’s a fader? Or a knob? Or a switch?
For example, Helix Native. I was demo-ing that plug-in about a week ago. The parameter list was Knob1, Knob2, Knob3…Knob16. Switch1, Switch2, Switch3…and then a loooong list of CCs. And then the user decides from within the plug-in to connect a parameter in the GUI, e.g. Wah, or amp Gain, to a RCE parameter, e.g. Knob 1 or Knob 2. This is a breeze to setup with a controller. Knobs go to knobs, switches go to switches, use some CCs for faders, all done!
But in other plug-ins, the parameter list is just a list of parameters (Llfreq,Lhfreq,Llgain…etc etc). I need to see which parameter resembles what control, and decide that “the most important parameters resembling a knob will go to encoders 1-8. The most important parameters resembling a fader will go to faders 1-8”. If I have free space, I could assign a knob to a fader, if that could save me a page-turn and only if it is an intuitive mapping.
So, if we knew that “parameter 1 is a knob”, and “parameter 2 is a fader”, couldn’t we somehow sort the parameters in such a way so that “Knob parameters are assigned to knob pages, fader parameters to fader pages, and switch parameters to button pages.” Then we could shift those parameters around if we wanted, to bring those of “higher priority” to the first pages of each control, but it would be an easier task to do this for each control instead for the entirety of the parameter list.
However, lately I tend to think that even this way,I couldn’t “automatically” do the assignments the way that I want as described in this thread here. I could obviously search the parameters’ names and do something, but it wouldn’t be stable enough.
After all, I think that it should be a 5-10minutes (an hour? ok, an hour) for a user to map in a “standard” way one plugin. And then we could have a big lib with all these mappings
Steinberg could learn a lot from Automap , Automap does precisely this , you have an empty controller template , press learn to what ever you want knob/fader/switch/ and move the parameter ,unlearn . save template , open new plugin and do the same with all your plugins , once they are done they are saved as one big template and automatically switch to what ever you have in focus . How can Novation get it right 12 years ago and Steinberg can’t even get half of the job done in thier own Daw
Does we can not use the remote device editor for exactly these things? It was said we could and I assumed this. If we can’t use it, I would suggest to follow user mchantzi: using a good synth template with at least two OSCs. A good example would be a Roland JD-800 setup or a Novation Peak.
Hi @Highly-Controversial,
I most probably didn’t explain the scope of this thread good enough. It is not about how to make our life easier when we midi-learn (I know about automap and the fact that it makes things easier, and after all I own a Nektar Panorama P6 which comes with many many plugins pre-mapped), but on what would seem as an optimal mapping.
I mean, before even we decide to midi-learn, how our layer should look in order to stay inside a universal context. Say, for example, you have 2 plugins, which both share a 80-90% of the same properties, envADSR, LFOs, other OSCs and so on. My idea (and quite sure I’m not the first to had this one) is that we should have a layout which would fit with both plugins so that our muscle memory will always guide us towards the control we need without too much thinking.
Now, the way to midi-learn these, comes afterwards, and I do agree that things could be easier on this side, however the mapping system of Cubase (with pages) is very suitable for implementations as mine. After all, I see many many plugins having the midi-learn functionality without the need for Cubase to be in the middle. But I would prefer to stay in the pages context. If they make mapping easier would be a big plus, no question about that, I agree
I think I can understand the idea and philosophy but …
The strong point of MIDI Remote is just that is customizable at individual user level.
Even if you would invent today your own ‘Standard’ I predict it would not stand the test of time.
I read about the envelope (ADSR) and LFO’s. That’s pretty much focused on Synths. But other people use libraries from Native Instruments or SpitfireAudio - just to name a few, that do not benefit from ADSR or Filter alterations. (or standard mappings)
I never came up with a ‘Standard’ for myself, let alone a more global (Universal as you called it) ‘ideal’ standard. Nevertheless, I bookmark this thread for further reading.
Cheers!
Well spotted! Actually I should really make my intentions clear. I’m mostly concerned about synths!
Very true! On the other hand, when it comes to synths as you obviously know, we tend to place our fingers where we think they’ll touch an Attack or a Resonance for example. And being able to do this for many synth plugins, at least for me, would get us out of the “trouble” to look at the screen, or try to guess where something is mapped
I quite like the way Nektar tried to standardise their mappings for instruments, i.e. first four faders for Env1/Filter, second set for Env2/Amp. Then the 8 rotaries for macro style controls, which normally would be Cutoff/Filter etc.
I do like working in 8s because it can scale across more devices… Trouble comes when you get hardware with 9 faders, do you break the mold or do you leave the 9th out of it and leave it for selected track volume outside of this scope? It’s more a problem when dealing with organ instruments where a 9th fader is nice to have.
For most synths I have an initial macro page of most useful params, then I’ll have a page for each oscilator, then envelopes, and then effects. I think to pair them out into 2x8 blocks as best as possible to allow for rotary-only or rotary+fader hardware in the same mapping would be relevant for the most amount of users.
As a side issue, I don’t think you can pick which RCE (Remote Control Editor) mapping the MR script uses can you? I think it’s fixed to the default/MCU one isn’t it?
There’s still quite a few loose threads in the new MR, just hope it keeps progressing and we can be more confident in helping each other out. Last thing you want to do is create a load of mappings and something changes that throws it on the floor.
In addition to this, I know back on the Logic forum we’d build automator scripts to scroll through plugins and save presets into the native Logic library - which provides you prev/next parameter control for third party plugins via remote. (Ref)
Cubase has the media bay and the similar options, yet another area where there’s no community activity.
I find the remote editor pretty mature to expect changes to this, but, sure, you never know!
I have another, alternative approach instead of changing the template using the remote editor.
We can actually remap it inside the script, and I’ve already experimented with it on the channel strip’s stock effects (compressors, limiters etc). This approach however has two weaknesses: 1) If a user changes the remote mapping, it won’t work, and 2) if a manufacturer changes the default layout, by adding new parameters, again it won’t work and will need an update.
Anyway, this is how it works: I have a small script just for sniffing the default mappings. It spits out for every parameter, its index/bank ( I do too use the 8-params/bank approach). Then we create an array of the form: [ourKnobIndex1->paramIndexN1, ourKnobIndex2->paramIndexN2…].
So, when our plugin is loaded, we translate the original knob to another one and we have everything correctly mapped. I’ve abandoned this approach (at least for now).
Back to the original, using the remote editor. My new way of thinking is to create banks based on the parameter’s type.
My Keylab has 8 faders, knobs and buttons (I don’t count the 9th column, because I want it to be used in another way). So, using the remote editor, I’ve arranged parameters I like to be connected with faders to, say, bank1, the ones to knobs in bank2, and for buttons in bank3. And so on, for all parameters/bank. This way, the script knows at which type of control to assign what, making understanding the layout easier.
Ohhhh, nice idea. So you step through the params on track change and place them in a JS object which can then be used directly for MR value binds?
You could achieve that even if it’s not default mappings couldn’t you? By parsing the instrument slot banks into objects. God knows what performance would be like and what page you stop at though!
When you say bank, do you mean pages (in RCE)?
Sorry, Just trying to get my head around this approach! …I think it’s what I do, too, but the term banks has me curious if I’ve missed something
.