Learn Mode for linked macro parameters

Here's the reason I'm having issues finding some VST parameters:

Certain VSTs (I'm looking at you, Massive), allow users to rename macros on a per-patch basis. By default, these are named Macro 1, Macro 2... and this is what it presents to the host. However, as soon as you select a patch that has new macro names, the names the host sees change as well. 

This methodology certainly has its advantages. However, it also means I can't simply assign something like: inst/1/plugin/MACRO 1 as a linked parameter to knob 1 and have it work across all patches. Each Unify preset needs a uniquely assigned set of linked parameters with names that match the names given to those parameters in each Massive patch.

I don't know how Ableton does it, (I'm guessing they probably use the index to the parameter rather than its name) but Live is able to retain mapped parameters even as patches change. Any ideas or suggestions?

@karlfranz

Adding an ability to choose "the last parameter you adjusted manually" as the target for parameter linking is a great idea, which has been requested before. Your idea to add a "learn" function would basically be the same, but would involve an extra step, so I'd prefer the first approach. It's something I have been wanting to add for quite a while. It's a bit complicated, but certainly doable, even for plug-ins that dynamically change their parameters list.

It's on my list, but I'm facing some really serious high-priority issues right now, so I may not get to it for quite some time.

@getdunne, I agree. I like the "Link last used parameter" as it saves a step.

Any thoughts on how to deal with VSTs renaming parameters between patches? I suspect that this might be impossible to deal with programmatically unless you store a parameter's index and that might be a nightmare.

I like your elegant solution of using editable text for linked parameters but feel it needs a little more flexibility to make it easier when creating/porting entire libraries of Unified patches. This, like a new patch browser concept, may be something to consider for a Unify v.2.x product. In fact, these features, along with a utility for easier conversion of libraries to Unified format could improve the marketability of Unify as an all-in-one VST host.

@karlfranz

Parameter names are already checked dynamically, so if they are changed, that should be no problem. Parameters are always accessed by name, not index.

If you have any suggestions for what to do to assist in creating/porting entire libraries, I'd like to hear them. I do a quite a bit of custom coding in support of this right now (in a dedicated bulk patch-modification program), but this is not a very scalable approach.

@getdunne

I'm not sure if I was clear. Yes, parameters names are checked dynamically, but they are not re-mapped dynamically. Here's a scenario trying to "Unify" the PluginGuru Massive Power Pack library*:

• Create a blank Unify preset and load an instance of Massive.
• Select the PAD - Frozen Pictures patch in Massive.
• Link all the macro knobs in Unify to the corresponding macro parameters in Massive.
• Because Massive renames its macro parameters per patch, the first macro parameter is called "WAVE". So, in Unify, we must link to the parameter using inst/1/plugin/WAVE.
• Save the Unify preset. 
• While keeping this preset open in Unify, select the next patch in Massive. The intent here is to retain all the tedious parameter mapping, rename the Preset in Unify to match Massive's next patch name and select Save as... to save the next Unify preset.
• However, the next preset in Massive renamed the first macro to "Pitch LFO" which means that Unify's linked parameter no longer matches.
• We must again re-link all 8 parameters using the new names.
• Repeat for each of the hundreds of patches. Ugh!

Essentially, VSTs that rename their macros don't allow the re-use of one preset's linked parameters as a template to create other presets. This also means that, for VSTs like Massive, a bulk import utility would have to use an index in order to get the correct name for the linked parameter.

*I use the Massive Power Pack as an example because John prides himself in the extensive use of macros to do useful things in PluginGuru libraries. However, in the Unified version of this library, none of these parameters have been linked to Unify's macro knobs.

@karlfranz

If I understand correctly, the issue is that you want to map our Macro knobs to e.g. Massive's macro parameters, but Massive changes the parameter names (but not the index values) per-patch.

That should be straightforward to handle, but I'll need to think about how to do it.

Thanks for clarifying.

@getdunne

To throw a follow-up idea onto your probably overflowing thought process:

Maybe allow the assignment(s) to be mapped not to a specific plugin, but to a layer and slot - essentially mirroring the concepts/syntaxt you introduced in the MIDI controller files. e.g.

• inst/1/vstparam/1
• inst/2/insert/1/vstparam/1
• inst/3/auxsend/1/vstparam/5
• aux/1/insert/2/vstparam/2
• master/insert/2/vstparam/4

For example, I might map the first page of Unify Macro Knobs to the first 8 VST automation parameters of the first instrument. And then I get the 8 most important mappings (as defined by the sounds designer of the instrument or patch) regardless of loading Massive or Reason Rack or Omnisphere, etc. into the first instrument. And then the second page could be mapped to the second instrument. etc.

---

Alternatively - or ideally in addition: Would it be too much extra effort to add midi control change messages to what the Unify Macro Knobs can send to plugins, rather than only VST automation parameters? I seem to remember the odd plugin that has implemented more midi CC control than VST automation control. The other advantage might be that quite a few plugins have midi learn, so one could "train" one's plugin to work well with a common Unify layout.

Side Note: Typically I much prefer VST automation control, since it seems bi-directional by default and therefore allows

• recording changes in plugin parameter values into my DAW recording by moving controls in the plugin,
• (at least in Cubase), I can get the current state of the VST back to my hardware midi controller (via a bi-directional midi to vst mapping mechanism), allowing
  • smooth modification of current settings from external controller without such workarounds as pick-up or increase/decrease
  • displaying currently applicable plugin parameter values on external controllers that have that capability (I have a few of those).

However in the case of multi-target macros, the one-to-many mapping (one control into the host sending many controls to plugins) makes those macros a one way control. So midi based control from host macro knob to plugin control knob is just as good or better (due to midi learn in many plugins).

Hope that made sense 🤣

@nico

Accessing plug-in parameters by index has been deprecated in JUCE for some time, possibly because newer plug-in standards may not support it. This doesn't mean it can't be done, but issues could arise with some plug-ins in future. As to the keyword "vstparam", bear in mind we have to support VST3 and Audio Units as well, and possibly other formats in future.

A future version of Unify will definitely allow macro knobs to send MIDI CC messages. They actually do this already, but only for the CC number which is also assigned to control the knob. In future this will be made more explicit, and you will be able to send more than one CC (or none), use response curves, etc.

@getdunne

Sorry - should have just called it "param" instead of vstparam in my example.

Accessing plug-in parameters by index has been deprecated in JUCE for some time, possibly because newer plug-in standards may not support it.

And also sorry for making it sound like I was asking for for indexing in communicating between Unify (as host) and it's plugin.

In reality I meant being able to ask Unify: Map to the Nth (e.g. 1st, 2nd, 3rd, ...) parameter of the list exposed by the plugin in the currently active plugin patch.

I'm using Cubase as my DAW, and it has something called Quick Controls as roughly analogous to Unify's Macro Knobs. And there, every time I change a patch in Massive X (to continue using that as a relatively modern example plugin), the Quick Controls listing of parameter names in Cubase gets updated on the fly and the first Cubase Quick Control is mapped to the new mapping as specified by Massive X. So it would seem the host (Cubase) somehow finds out from the plugin (Massive X) that the exposed parameter list has changed.

So it seems like Cubase changes which plugin parameter it controls on the fly, when the plugin changes that assignment. So to the end user it looks positional (the 1st Cubase Quick Control controls the 1st exposed plugin parameter, etc.), while internally the host and the plugin perform additional communications and the host automatically re-maps after each plugin patch change to figure out who's on first and what's on second, etc 🤣 

This behaviour is a huge workflow saving for end users, since more and more of the better designed instruments (hardware and software) expose the most useful parameters (as defined by the sound designer patch by patch) as hardware or software controls, and the end user gets to fiddle with the so defined knobs for sensible instant gratification.

p.s. Very happy to hear about macro knobs sending explicit midi messages in the future. Yay! That might even be at least a partial solution to the above discussion for some older plugins and plugins that have a good midi learn implementation. Massive X does not have that, so it's automation parameters or nothing.

Posted by: @getdunne

A future version of Unify will definitely allow macro knobs to send MIDI CC messages. They actually do this already, but only for the CC number which is also assigned to control the knob.

I wasn't aware Unify was doing this. At first I got excited while reading about this because I thought I could then use Bome MIDI Translator to capture the CC messages and send feedback to my controller's encoder LEDs. Alas, it seems it's only done "privately" between Unify and the VSTs it's hosting. The world outside Unify cannot "see the CCs".

Sorry if this is a bit off topic, but it applies to Macros and Massive that have been discussed above.
I am not able to get Massive to open with the desired midi cc setting by default. 
It always opens with the same setting (se clip) and I have to change it every time.
Can't find where I can change this in Massive. Do you have the same problem and have a solution?
Made a short clip to illustrate the behavoiur:  https://www.dropbox.com/s/x0qtv9zo1r402qk/Massive%20CC%20Mapping2.mp4?dl=0 

Edit: Creared a new topic here,  https://forums.pluginguru.com/questions-about-unify-v1-0/midi-controller-mapping-in-massive/#post-6167 

Creating new topics on the forum is free. Please try not to hijack other threads. It's usually considered bad netiquette.

Cheers.

@karlfranz
Since the whole thread is basically about different aspects of Macro controller and Massive, it was not so far-fetched to raise the issue here I though. But again sorry, You will not se me in any of ”your” threads in the future.

Posted by: @getdunne

A future version of Unify will definitely allow macro knobs to send MIDI CC messages.

For those who can't wait - there is a free Melda CC Generator that can send any cc message (including aftertouch) + all the cc values can be modulated with built-in LFOs. All you need to do is to map Melda CC value knob parameter to your macro knob.