Linux VST3 & JUCE: many extra parameters, via "emulate MIDI CC with parameters"

[GModal]

This is an issue with Camomile VST3 plugins (Pure Data) in Carla. Extra parameters are instantiated, 128 parameters per MIDI channel (2048 total -- beyond Carla's parameter limit, apparently):
pierreguillot/Camomile#194

Apparently related to JUCE option JUCE_VST3_EMULATE_MIDI_CC_WITH_PARAMETERS. It's set at compile time. Documented here in a JUCE thread:
https://forum.juce.com/t/what-is-the-intention-of-macro-juce-vst3-emulate-midi-cc-with-parameters/17858

[falkTX]

Seems to me it is working as intended.
Carla has the parameter limit in its settings. The plugin has too many parameters, so carla hides those that get above the user-configurable limit.

Plugins that want to handle CC internally really should not exist.
They try to automate their own parameters and thus end up bypassing the host.
MIDI CC mapping to parameter is something that should be done on the host side, I guess Steinberg realized this too.

My recommendation is to simply not have that "juce hack" enabled.
VST3 plugins can receive MIDI CC, if they enable the legacy-midi option. If hosts support this option or not is a different matter.

[pierreguillot]

What is the legacy midi option? How could I enable that? What would be the generic approach to receive the MIDI CC with this option?

[ryukau]

Perhaps this topic on VST 3 SDK forum is related.

• VST3 and MIDI CC pitfall - sdk.steinberg.net

On VST 3, IMidiMapping is the way to recieve MIDI as VST parameter. Link below is the relevant part in JUCE code:

• https://github.com/juce-framework/JUCE/blob/a30f7357863a7d480a771e069abf56909cdf0e13/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp#L706

I haven't used JUCE, so not sure how midiControllerToParameter is defined. But if a plugin tries to recieve all possible MIDI, it's likely unavoidable to add VST parameter for each MIDI message type.

Latest VST 3 SDK (3.7) provides kIsHidden flag to hide parameter from host. This might be used here. Though VST 3 SDK is updated only recently, so kIsHidden may not be supported by JUCE for now.

• VST 3.7 SDK Released - sdk.steinberg.net - kIsHidden is mentioned in New Flags/Enums

On Carla 2.2.0-RC-1, there's a setting to increase the number of parameter displayed by generic UI (Configure Carla -> Engine -> Max Parameters). However, Max Parameters can't exceed 1000 on my environment.

[pierreguillot]

So I guess the best would be to wait for juce to update the VST SDK to 3.7 and to use the kIsHidden flag for the MIDI controller parameters. Is that it?

[falkTX]

Please dont do that.

This seems the typical "before asking if you could, ask if you should" situation.

What exactly are you trying to accomplish here?

[pierreguillot]

I want to receive Midi CC in a Juce Vst3 plugin. I don't understand why I should not use what is suggested by Juce (they could have made a mistake but I don't understand what it is, I don't know very well this domain so I don't know the "risk"). And what would be the alternative because if there is no sustainable alternative, I prefer to use an approach that is not ideal but that works in most of the situations.

[falkTX]

receiving midi cc is fine. mapping midi cc to parameter changes on the plugin-side is not.
it is actually not even allowed with lv2 control ports, as plugins are not allowed to change their own inputs.

if you have a parameter mapped to a midi cc, the host is not able to know this information.
the host can be automating a parameter (which is something the plugin does not know) and then the plugin at the same time also trying to automate the same parameter.
it creates a conflict, by having many sources of automation, many ways that can do the same action that can mess up with each other.

I have developed both a host (Carla) and some plugins (through DISTRHO-Ports and DPF stuff).
The plugin really should be an actual plugin in the end. That is, something that is self-contained, and is controlled by a host.
Plugins that automate their own parameters bypass the host, which is racy and ugly at best, can cause crashes at worst.
For plugin UIs, the plugin spec usually has a way for the UI to inform the host about a "grab" or "touch" operation, so the host knows that the user is holding down a parameter and likely a parameter-change-event will be triggered.
There is no such thing in the plugin DSP side, by design.

As I see it, plugins should choose one of these options:

1. expose their parameters and let hosts be in control of them
2. do not expose parameters and handle things internally, triggered by MIDI CCs
3. a bit of both, where relevant parameters are exposed and things more traditionally related to MIDI CC are not

Trying to both expose parameter to the host, and handle them internally too with MIDI CCs is a design mistake and/or a hack.
Plugins that try to do too much are abusing their role as a plugin.
Of course, this is just my opinion, but it comes after many years dealing with many issues on both host and plugin side.

[ryukau]

I think adding kIsHidden falls into option 2 or 3.

kIsHidden | parameter should be NOT displayed and cannot be changed from outside the plug-in (implies that kCanAutomate is NOT set and kIsReadOnly is set) [SDK 3.7.0]

• VST 3 Interfaces: ParameterInfo Struct Reference

@pierreguillot After looking up a documentation a bit, I think hiding parameter from host is possible by removing kCanAutomate and adding kIsReadOnly. So this may be solved with VST 3 SDK 3.6 or earlier. It's probably better to contact JUCE developers about this issue. I'm just a random person who happen to watch this repo, and a bit curious about how JUCE handle this.

[pierreguillot]

@falkTX I think I understand your view but I agree with @ryukau, using hidden parameters should solve the problem. I will try to contact the Juce team. Thank you both for your feedback!

[falkTX]

Closing this issue since there is nothing to do from Carla's side.
Unless the VST3 flag is not being seen by carla? though that would be a different ticket/issue anyway.

[atsushieno]

It seems a bit old thread before JUCE indeed started to hide those CC parameters in the recent releases, but anyways.

Unless the VST3 flag is not being seen by carla?

I figured this exact issue is causing the issue at Zrythm (which is based on Carla plugin hosting). It is showing extra parameters, and there is no way for it to know which parameters should be hidden: https://todo.sr.ht/~alextee/zrythm-feature/577#event-214808

I'm not sure if there should be a different ticket/issue though. Things discussed here seems to precisely describe the issue. What information would be needed further?

[falkTX]

Might depend on the plugin. Carla is reading "is hidden" attribute for vst3 parameters, and unsets the PARAMETER_IS_ENABLED on those.
But not all plugins set that flag..
https://github.com/falkTX/Carla/blob/main/source/backend/plugin/CarlaPluginJuce.cpp#L804

On JUCE hosted plugins we do not get access to the full VST3 object, which makes implementing this a bit tricky.. Once the native VST3 implementation is finished this will stop being an issue, since then Carla has full control of the plugin hosting.
But I dont expect it for 2.6.0 yet.

[atsushieno]

Oh, definitely. What I tried with Zrythm was my custom build of jpcima/Hera with JUCE7, but to make sure I confirmed with surge-synthesizer/surge as of commit fab28b3d on Ubuntu 22.04.
JUCE AudioPluginHost from 7.0.2 and Bitwig 4.2.5 (somewhat older) on the same machine hid those CC parameters.
I seem to have carla 2.6.0-alpha1.

Though if the existing JUCE based implementation did not work yet it is already supposed to, then it would make better sense to wait for native VST3 implementation. At least it is not blocking Zrythm at all.