VST3 and MIDI CC pitfall

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

VST3 and MIDI CC pitfall

Post by abique » Fri Apr 12, 2019 8:54 am

Hi,

I write this message to share my impression and understanding of how VST3 and MIDI CC has been working the last years.

Why VST3 does not provide MIDI CC input and output support?
  • VST3 wants the host to solve the conflict between a concurrent automation and a midi message affecting the value of a parameter
  • Maybe Steinberg believes that MIDI CC mapping inside the plugin is a legacy feature.
  • VST3 already has its own "MPE".
How does it work?
  • IMidiMapping lets the plugin maps exclusively one MIDI CC to one parameter.
  • IMidiLearn lets the plugin know that one MIDI CC happened, in order to let the plugin implement MIDI learn.
What are the problems?
  • It is impossible to map one MIDI CC to multiple parameters.
  • No NRPN (both 7 and 14 bits) support
  • No 14 bits CC support
  • It is impossible to define a modulation range, curve and smoothing.
  • To work around the above issues, the plugin would have to create "proxy" parameters, which would be virtual (not automatable) parameters created specially to receive one MIDI CC, and then dispatch according to the plugin rules to other parameters. In this case the plugin is responsible to deal with conflicts between MIDI CC and automation; which defeats the goal of letting the DAW deal with the conflict.
  • We can see today many plugins creating 128 * 16 proxy parameters in order to receive MIDI CC. Which is a waste of resources, and introduces unnecessary complexity. It looks like an "Anti-Pattern". What happens if with MIDI 3, there are up to 1024 channels and 1024 CCs, the plugin creates a million parameters? Does the host have to call IMidiMapping::getMidiControllerAssignment() a million time and cache it for each plugin instance? Because IMidiMapping belongs to the IEditController and should be called from the MainThread right?
Conclusion

To me it is unclear, if VST3 by design and specification do not want anything related to MIDI CC, because it should be entirely done by the DAW and it is pure legacy. Then I'd suggest to remove the IMidiMapping and IMidiLearn to make it clear that the plugin won't ever get MIDI CC, and don't give the opportunity for the plugin to cheat the design. Also that would force plugins to use VST3's note expression and not catch the MIDI CC to perform MIDI MPE.

Or, VST3 by design wants the plugin to work with MIDI CC. The current solution of having 16 * 128 proxy parameters being exactly the same as having full and raw MIDI CC input. As consequence I would introduce a ControlEvent (it might not be bound to MIDI CC limits) and finally I would deprecate, IMidiMapping and IMidiLearn because they would be unnecessary.

Please remember, that everything I said is according to my experiences and understanding of VST3. If I missed something important please let me know.

Regards,
Alexandre

bluecataudio
Posts: 5
Joined: Fri Jun 24, 2016 7:58 am

Re: VST3 and MIDI CC pitfall

Post by bluecataudio » Wed May 15, 2019 12:52 pm

Yes, please give us back standard MIDI support instead of hacks! having more than 2000 parameters just to support MIDI CC and program change message is ridiculous. And it slows down everything for both hosts and plug-ins!

blegoff
Posts: 18
Joined: Tue Aug 23, 2016 2:15 pm
Contact:

Re: VST3 and MIDI CC pitfall

Post by blegoff » Thu Jun 13, 2019 2:42 pm

Agreed, same issue for us, declaring thousands of proxy parameters is not a clean solution from our point of view.

Post Reply