Implementing VST Extensions

Thanks! I’ll figure something out. Since this might be an issue affecting several users at the moment, maybe the JUCE devs can figure something out for the future. :slight_smile:

I’m interested in a solution too since i also want to add NKS support…

Would it be possible to add NKS support if the host callback was supplied to the plug-in after the plug-in’s constructor was called? I’m not familiar with what needs to be done.

I could add another callback along the lines of

void hostCallbackAvailable (VSTHostCallbackPtrType hostCallback) = 0

which would be called immediately after the constructor finishes.

1 Like

That would cover only VST2 though, right?

Correct.

What’s needed from the other SDKs?

In VST3, I have needed the FUnknown* hostContext pointer passed for the JuceVST3Component::initialize method. (That’s for using the Reaper API, I don’t know if that would be useful for NKS etc.)

I’ve made VST3 Extension as an example:
https://github.com/soundradix/JUCE/commit/6905c59655ef9e98d32383504531173a8dd56e03

VST3 uses some Steinberg COM-ish way.
It seems currently there isn’t an elegant way to implement specific format features without modifications.

Hello!

I’m using JUCE 5.2.1 and I have cherry-picked the commit

Added a “plug-in can do” callback to the VSTCallbackHandler interface

so I can handle vendor specific vst host->plugin “can do” callbacks.

I have implemented (override) the virtual methods of the VSTCallbackHandler ( handleVstPluginCanDo and handleVstManufacturerSpecific ) as public methods of my PluginProcessor.

When the handleCanPlugInDo method of the JuceVSTWrapper class receives unhandled plug-in “can do” calls from the host, the

auto callbackHandler = dynamic_cast<VSTCallbackHandler*> (processor)

returns a NULL pointer, so the

if (auto callbackHandler = dynamic_cast<VSTCallbackHandler*> (processor)) return callbackHandler->handleVstPluginCanDo (args.index, args.value, args.ptr, args.opt);

doesn’t call the handleVstPluginCanDo method.

Any idea why? Maybe I’ve missed some other commits after the tag 5.2.1 that I need to cherry pick before the Added a "plug-in can do" callback to the VSTCallbackHandler interface commit?

Thanks!

Hello!

I found the problem! My code was:

PluginProcessor.h:
Inheriting from VSTCallbackHandler:
class MyAudioProcessor : public AudioProcessor, VSTCallbackHandler

and it needs to be:

PluginProcessor.h:
Inheriting from VSTCallbackHandler:
class MyAudioProcessor : public AudioProcessor, public VSTCallbackHandler

I’ve enabled access to the host callback for VST2:

https://github.com/WeAreROLI/JUCE/commit/1d56cfe04a04b67df4a5dbcf8ad52a469562dc4d

That is awesome! When get we expect a new JUCE release? It has been a while now and a few things like this in the official release would be VERY welcome.

We’ve not got anything scheduled for the near future. There’s a significant HiDPI scaling improvement coming soon that we want to give a good long run on the develop branch before the next release.

1 Like

If you have your JUCE fork repo, you can cherry-pick critical fixes or improvements needed for your product.
That’s the true power of JUCE being git and open-sourced on that scale.

Sounds like a plan then. We would like to play with NKS integration soon, so these callbacks are kinda important :wink:

Thanks.

Any chance to get a similar thing for VST3, as described in my above post?

edit : I dunno if it would be too dirty to change the signature of

virtual void handleVstHostCallbackAvailable (std::function<VstHostCallbackType>&& callback)

to

virtual void handleVstHostCallbackAvailable (std::function<VstHostCallbackType>&& callback, void* vst3hostcontext)

?

Yes, that’s on the to-do list.

A cleaner way is making a new interface, VST3CallbackHandler.

1 Like

My only wonder is what you’d get and how much useful would that be for the Steinberg COM flow?
My example above is using pretty simple gain reduction example.

If I get a VST3CallbackHandler , how do I define additional DECLARE_CLASS_IID ?

I’ve not yet thought about the best way of achieving that - I added the VST2 callback because it was an easy modification.

Exposing the FUnknown* hostContext pointer should be similarly easy, but obviously that doesn’t appear to help your use case.

If I want to send a custom message (“handshake”) to a host from my VST3 plug-in and wait for a specific response with which I can decide if I will instantiate the plug-in or not, at which point should I do it and how?

I am stuck inside:

  • juce_VST3_Wrapper/JuceVST3EditController class
  • juce_VST3PluginFormat/VST3HostContext struct

I know that I have to create a custom Steinberg::FUnknown interface class which will specify the DECLARE_CLASS_IID in order to create a query to the host and that I have to use the hostContext pointer to access the host. But, how do I combine all these and where? It seems very complicated to me.

Hi, this forum post is a useful reference for adding VST3 extensions…

3 Likes