Clarification about midi parameter mapping

SDK for VST 3 audio plug-in and host development.
Post Reply
abique
Posts: 38
Joined: Tue Jun 21, 2016 12:43 pm

Clarification about midi parameter mapping

Post by abique » Wed Apr 10, 2019 8:44 am

Hi,

Is OK to map a MIDI CC directly to an automatable parameter like your filter cutoff or you should always create a "fake parameter which is not automatable" to receive the MIDI CC input and then the plugin will deal with the conflict between automation and MIDI CC itself?

How does Cubase deal with plugins creating 16 * 128 "fake parameters". Are there any shortcut to save resources? Because it looks like an undesirable situation right?

Thank you,
Alex

ygrabit
Posts: 119
Joined: Fri Jun 17, 2016 7:52 am
Location: Hamburg

Re: Clarification about midi parameter mapping

Post by ygrabit » Thu Apr 11, 2019 8:24 am

You could map directly a MIDI CC to an internal (exported) parameter by using the IMidiMapping interface. The DAW host should then handle the potential conflicts [MIDI CC - Automation].

In order to reduce the numbers of exported "fake" parameters allowing to make MIDI learn (which could lead to a lot of parameter, like you said), the plugin should use the new interface IMidiLearn (which is implemented in Cubase 10).

In order to check if the host supports such interface, the Plugin could ask in initialized () the host by using the new interface IPlugInterfaceSupport :

Code: Select all

result PLUGIN_API MyPluginController::initialize (FUnknown* context)
{
    // ...
    FUnknownPtr<IPlugInterfaceSupport> plugInterfaceSupport (context);
    if (plugInterfaceSupport)
    {
        if (plugInterfaceSupport->isPlugInterfaceSupported (IMidiMapping::iid) == kResultTrue)
            // IMidiMapping is used by the host
    }
    // ...
}
Cheers
YVan Grabit

abique
Posts: 38
Joined: Tue Jun 21, 2016 12:43 pm

Re: Clarification about midi parameter mapping

Post by abique » Fri Apr 12, 2019 7:37 am

Thank you for the clarification,
Alex

Post Reply