My doubt about the meaning of the JUCE_VST3_EMULATE_MIDI_CC_WITH_PARAMETERS macro is which “direction” it applies to: when enabled, does it mean that…
a) Every CC received by the plug-in as MIDI input, will be interpreted as if the corresponding automated parameter were moved by the host, and the plug-in setParameter() is called accordingly
or
b) That for every automated parameter that is moved (i.e. every call to setParameter()) a corresponding CC is sent from the plug-in as MIDI output
?
P.S. it would be nice if we could write such a long macro verbatim in the title of the topic rather than replacing underscores with spaces not to trigger an error
Cubase strips all CC messages from the MIDI stream, i.e. with JUCE_VST3_EMULATE_MIDI_CC_WITH_PARAMETERS=0 your processBlock function would not get any CC messages in the midi buffer.
To workaround this short coming, you can enable JUCE_VST3_EMULATE_MIDI_CC_WITH_PARAMETERS: this will create a bunch of VST3 parameters (which is hidden from the AudioProcessor but can be seen in the Cubase’s generic editor view) and tell Cubase to associate them with corresponding CC MIDI messages. When these parameters change, we generate the corresponding MIDI cc messages and pass them on to your processBlock’s midi buffer.
This way, cc midi messages arrive at your plugin’s processBlock as expected just like in VST2 or AU.
Yes that makes very much sense, I was not aware of this filtering of CC messages and thus such an “emulation” feature looked strange.
Now that I have looked at the documentation it is clearer now, and also it seems that this is not really just a Cubase thing, but more a limitation of the whole VST3 format. Can you confirm that?
Also, does the VST3 format prevent Program Change messages from being sent to plug-ins as well?
From what I could understand of the VST3 documentation, it seems that only Note messages are intended to be passed by the host to the VST3 plug-in “natively” (i.e. not resorting to workarounds like the CC emulation in JUCE).
Yes your spot on. Please replace Cubase with VST3 in my answer above. In fact, there is not even a mechanism for the host to send midi to plug-ins in the VST3 specification. You can only send a variety of note events - see for example this file which converts between note events and MIDI in JUCE.
As you will see there is no program change event. The way VST3 deals with this is that you set a “program change” flag (Vst::ParameterInfo::kIsProgramChange) on one of your plug-ins parameters. MIDI program changes will be routed to this parameter.
So, in order to receive Program Changes, one more additional parameter should be added just like it has been done for all those added to receive CCs with JUCE_VST3_EMULATE_MIDI_CC_WITH_PARAMETERS…
Is there any chance that this feature will be added to the VST3 wrapper, perhaps with a similar macro?
(JUCE_VST3_EMULATE_MIDI_PROG_CHANGE_WITH_PARAMETER ?)
On the latest develop commit, I’ve added support for the program change parameter. However, this parameter will map to the AudioProcessor’s setProgram callback instead of injecting a midi program change message. I hope this will also work for your use case.
No, I am sorry but that will not do (and not only for my particular case).
The problem is that such implementation is inconsistent with the one in all the other plug-in formats, and that breaks the “wrapper” paradigm/abstraction.
IMO, you should inject them as MIDI messages exactly as it is being done for CCs, because that’s how every plug-in made with JUCE to date expects to receive them, in all other plug-in formats.
When that code is in place, if you wish to offer the "map to setProgram()" feature, it should be left at the user discretion to enable that and, again, that should be offered across all plug-in formats for consistency, not just in VST3 (again, to preserve a format-agnostic abstraction)
I agree, I’m just not sure how to do this with VST-3. It could be that it may not even be possible with VST-3. Any VST-3 experts out there? Please help!
I’m not sure I agree as we do support this mechanism with all other plug-in formats - i.e. we map a native program change call to a setProgram callback. We support this in VST-2 and AU but didn’t fully implement this in VST-3 yet. My latest commit fixes this. BTW the program change parameter is normally invisible to the end user in most DAWs. The parameter is usually mapped to a native program chooser control of the DAW.
I’m not sure about this: for a fact I am sure that in many of the hosts we test plug-ins in, there is the possibility to directly add Program Change events in MIDI sections/piano roll views/etc, and in the corresponding plug-in formats (with the exclusion of VST3), those events are passed to the plug-in in the form of a MIDI Program Change
This certainly includes at least Logic, Cubase, SONAR, Reaper
I don’t understand the difficulty of this.
To me, it seems that this could have been esaily added just as an additional case in the addParameterChangeToMidiBuffer() that already exists in the VST3 wrapper:
if the incoming id is the one of the parameter that is mapped to program changes, then a corresponding Program Change message should be added to the midiBuffer that’s already used for CCs.
I know this is a 9 months old topic yet I think it can still be improved
Adding 2048 parameters by default is quite interesting.
Wouldn’t it be better to use JucePlugin_WantsMidiInput for deciding if JUCE really need to set JUCE_VST3_EMULATE_MIDI_CC_WITH_PARAMETERS those parameters? or am I missing something?
(so if it’s undef it should define it based on if plug-in actually consume midi…)
Another issue here: took me a while to figure out that automation issues for a certain parameter occured because that parameter was falsely seen as a MIDI controller parameter. I think it’s wrong to have JUCE_VST3_EMULATE_MIDI_CC_WITH_PARAMETERS = 1 by default when the plugin config states that it will not accept MIDI input nor produce MIDI output.
