How to map a MIDI CC to multiple parameters?

Hi,

In u-he products it was possible in VST2 to map a single MIDI CC to multiple parameters. It seems that in VST3, a MIDI CC can be mapped to only one parameter. Is it correct? If yes, what would be the solution for u-he?

Thank you.

Alex.

Normally the host should implement MIDI-CC to Parameter mapping, tho not all hosts do this especially not mapping multi parameters.
Plug-Ins should only provide defaults.
The reason why the host should be responsible is that the user of the host should have a consistence workflow and not learn how to map Plug-in Parameters for every plug-in.

u-he is trying to provide a consistent user experience across different plugin interfaces, hosts and operating systems.
Offering a standard way for the user to map MIDI CC through the host, should not exclude the plugin from doing it as well.
Same idea, but from two different point of view, isn’t it?

Sure, one view of the plug-in developer and one view from the host developer.
I’m not entirely sure, but I think it’s more common that a user is using one host application with multiple plug-ins than one plug-in in multiple hosts.

If you as a plug-in developer want to implement this feature, you have to provide a proxy parameter and if the host maps a MIDI-CC to that parameter you can alter as many of your other parameters as you like.

And one more thing, when you do implement this yourself, you most likely will have problems with automation. What if the user had a recorded automation of one of the parameters and now records an automation for the proxy parameter. Both automation will fight against each other which value will be the correct one. So it’s still the best to let the host do it.

Do you recommend to create 16 * 128 parameters and map each of them to a single MIDI CC?
We’re fine with the ambiguous case of concurrent parameter automation and MIDI CC, as it is already “solved” for the other plugin format.

Interesting, how did you “solve” it ?
And I cannot recommend something here as I think that this is the wrong way.

cheers
Arne

I also think that having 16 * 128 virtual midi cc parameter is the wrong way.

If the user has two MIDI CC going to the same parameter (it is possible with IMidiMapping right?), then you can also have a race if there are two concurrent automation on that MIDI CC. If I’m correct, then hiding the MIDI CC to the plugin does not solve the issue as well.

No, the host records parameter automation, not MIDI-CC automation. The IMidiMapping only tells the host which MIDI-CC maps to which parameter.
If the user turns a knob on his MIDI remote control then the host maps this change to the parameters in the IMidiMapping and as the host knows about which parameters it changes and which automation is active, it can handle parameter changes accordingly without a race.

We did a customer survey recently. Turns out, our Cubase users averagely use 2.3 hosts.

You also get a race condition when there’s automation while the users turns a knob on the user interface with his mouse.

In our view, MIDI Learn is a means to set up control surfaces for sound design and live performance. Parameter automation is a means for a production scenario.

Back to the original topic, we allow for MIDI Learn of multiple controllers to the same parameter because users requested this. For instance, they have one setup with a foot pedal and another setup with a knob on a controller keyboard. One is in their studio, the other one is on stage.

You won’t get this race condition if you let the host do this stuff.
If the user turns a knob on the UI-Editor of the plug-in the plug-in sends this change to the host. The host sends this change to the audio processor in the process call and can temporarily turn off sending automation changes until the user ends editing the knob.

The VST3-Spec does allow to set multiple parameters with the same MIDI CC.
If this doesn’t work in the hosts, than I would think that this is a bug in these hosts.

According to IMidiMapping:

class IMidiMapping: public FUnknown
{
public:
	virtual tresult PLUGIN_API getMidiControllerAssignment (int32 busIndex, int16 channel,
															CtrlNumber midiControllerNumber, ParamID& id/*out*/) = 0;

	static const FUID iid;
};

We can only map one parameter to one MIDI CC.

If you agree to provide an other interface where we would have:

virtual tresult PLUGIN_API getMidiControllerAssignments (int32 busIndex, int16 channel,
															CtrlNumber midiControllerNumber, List<ParamID>& ids/*out*/) = 0;

That would be the solution to this topic.

The point is, we are letting the host handle the stuff in VST3. We are just asking that Cubase (et al) support assignment of multiple MIDI Controllers to one single parameter.

We have actually rewritten our VST3 implementation to fully conform with your designs. We just ask for simple improvements where the design of VST3 does not allow for the same user experience as our implementation of other plug-in formats.

To clarify: In our previous installment of VST3 we published 2048 proxy parameters to the host, in order to allow for MIDI Learn. This could lead to race conditions as you describe.

In our current installment, parameters are linked directly, as per your specification. Hence we let the host handle things and all is good.

But we still need the N to M assignment of controllers and parameters, where N and M are >= 1

I stand corrected, I did read the spec not the API.

We will discuss this at Steinberg how we can put this into an API.

Ideally we would need something like this:

/* implemented by the host */
class IMidiLearnProvider: public FUnknown
{
public:
  /* starts a midi learn from the host */
  virtual tresult PLUGIN_API startMidiLearn(ParamID id) = 0;

  virtual tresult PLUGIN_API stopMidiLearn() = 0;
};

/* implemented by the plugin */
class IMidiMapping2: public FUnknown
{
public:
  virtual tresult PLUGIN_API getMidiControllerAssignments(int32 busIndex,
                                                          int16 channel,
                                                          CtrlNumber midiControllerNumber,
                                                          IList<ParamID>& ids/*out*/) = 0;

  /* callback from IMidiLearnProvider::startMidiLearn().
     the plugin must check the status (in case it has been canceled by the host. */
  virtual tresult PLUGIN_API midiLearnFinished(int32 busIndex,
                                               int16 channel,
                                               CtrlNumber midiControllerNumber,
                                               ParamID id,
                                               tresult status);

   static const FUID iid;
};

Thank you very much!

Where does this issue stand right now ? I need several parameters all map to the same 4 CC’s (NRPN) just sending different values.

You’re best chance is to create a bunch of virtual parameters to capture the MIDI CCs…

@Abique, Thanks for your reply. Yes that works fine for receiving NRPN’s. The issue I am having is how to send the CC’s out. So far in the DAWs I have I don’t see CC been transmitted when changing an automated parameter (Live, Bitwig in Windows). Posted the issue here as well.
https://sdk.steinberg.net/viewtopic.php?f=4&t=158