search

falkTX / Carla

Audio plugin host
https://kx.studio/carla
1.61k stars 147 forks source link

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

Closed GModal closed 4 years ago

GModal commented 4 years ago

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): https://github.com/pierreguillot/Camomile/issues/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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Perhaps this topic on VST 3 SDK forum is related.

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

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.

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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]

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.