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 
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)
?
1 Like
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/JuceVST3EditControllerclass -
juce_VST3PluginFormat/VST3HostContextstruct
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