VST3 Host Menu / Class Access

Hi!

I’m in the process of porting Surge from hand rolled wrappers and vstgui to juce. It is, as you would expect, a joy - I mean that non-sarcastically. Thank you for providing quality well documented software. Our release in 3 weeks will be the last one on our hand-rolled code base, and after that Surge XT will be JUCE.

There’s only one feature gap which is in Surge we support VST3 menus. This lets Reaper and Bitwig and so on add things to our parameter menus and is great. I don’t actually use the host menu UI, I scan the data and add them as extensions to our built in menus. Super duper.

There’s no reason I can’t do this in JUCE also if I can get access to the VST3 classes. So in Surge I’m writing code which looks like this

  Steinberg::Vst::IComponentHandler *componentHandler = getController()->getComponentHandler();
    Steinberg::FUnknownPtr<Steinberg::Vst::IComponentHandler3> componentHandler3(componentHandler);
    Steinberg::Vst::IContextMenu *hostMenu = nullptr;
   if( componentHandler ) 
   {
       hostMenu = componentHandler3->createContextMenu(this, &param);

in my menu callback then iterating over that host menu, making little lambdas, and sticking them in my popup.

I could basically reuse that code completely if I can get access to that IComponentHandler

My project has a function which is compiled only in the VST3, it is called in the plugins, etc… so all the conditional compile / conditional call stuff with plugin type is all fine.

But given an AudioProcessor and an AudioProcessorEditor reference, even knowing full well they are inside a VST3, I can’t figure out how to break the JUCE abstraction and give me a reference to the IEditController I know is there.

I read all the code in juce_blah_VST3* and I see the classes I want, but they are in a .cpp not a header and are all private. I’m happy to dynamic cast and stuff but to what?

So is there a good example of, if you need to, a plugin-side break-the-glass where we can get a reference to the raw VST3, VST2, AU API with some set of casts and checks?

Thanks so much!

3 Likes

I’m not sure about exposing the VST3 types directly. Even in the example you posted, it looks like we would need to expose the IComponentHandler and the IPlugView, along with some mechanism for retrieving the VST3 ParamID for a given parameter. I think this could be quite confusing for users, and it would be very easy to use these interfaces incorrectly.

How would you feel about some new function on AudioProcessorEditor which allowed querying and possibly displaying host menu contents for a JUCE parameter index? Although this would be a bit less flexible, I think the resulting interface would be much easier to use, and also more maintainable for us.

1 Like

That would be infinitely better! I just didn’t think you would be willing to add it

In an ideal world, something which i sent a param to and it gave me back a tree of functions is ideal.

I have that code written - we used to use it in surge - and can wedge it into juce or share it with you. It’s a wee bit annoying (because: VST3SDK) but it’s clear how you would translate it to a structure.

Or even better an API like extendMenuWithHostMenuItems(juce::AudioProcessorParameter *, juce::PopupMenu &m) and showHostMenu(juce::AudioProcessorParameter*, juce::Rectangle<int>) would be perfect. No-op everywhere except VST3 but on VST3 the first reads the host params and adds it to the menu; the second just shows the menu directly at location.

If you want to see the code we used to use, when I stripped it out of our old VST3 handler on our way to JUCE I kept it around in another file ifdefed out.

I’m the sole author on that file. Feel free to use it in any and all contexts you want, including of course none :slight_smile:

But also if you have API points you like I’d even be happy to rough em out or test them for you based on our experience making it work in surge 1.9

Fwiw, it is probably the most popular VST3 feature we implemented. It’s really nice in hosts that use it well (Reaper being one such example).

1 Like

Thanks for your patience. Things have been quite busy here so it’s taken a while to review this change, but I’ve merged this feature now:

Please try it out and let us know if you run into any problems.

2 Likes

Thank you - this is wonderful. Let me pull right now and see if I can make it work in surge!

You folks are awesome. Here’s the context menu running in Surge XT alpha using the develop branch in Reaper. Thank you so much.

This will be in 6.1 sometime this summer or so? Can’t wait. Really appreciated.

1 Like

Yep, this will be part of the 6.1 release, which should be out in the near future.

1 Like