I found that the code is for JUCE 5.x and I of course am using 6.0.8.
Obviously the code is not compatible with that JUCE version. “juce_audio_processors/format_types/juce_VSTInterface.h” does not exist. But including the *.h that provides VSTCallbackHandler does not compile, either.
Is there an example for JUCE 6.x using VSTCallbackHandler (or whatever provides that functionality) ?
I don’t find anything about this in the changelog.
Deriving the plugin’s audio processor from both juce::AudioProcessor and juce::VSTCallbackHandler seems to be the correct approach to implement custom VST-specific calls.
The VSTCallbackHandler is included automatically in projects which use the juce_audio_plugin_client module. No additional includes should be necessary.
They did not include “juce_audio_plugin_client.h” .
After I did it in fact compiles, but I get a linker error about
guiEmbedComponent
not found.
Moreover they used the symbol “plugInOpcodeDrawEditor” which is nowhere to be found and which I replaced for now just to check if I can compile the sources.
Edit:
I see that guiEmbedComponent is in their code and not part of juce. So Ill have to check why it’s not found by the linker …
Edit:
This of course was a problem with the CBuild control file
Now it does compile and link.
But I get a ton of warnings and still I have no idea regarding “plugInOpcodeDrawEditor”
I think that’s a name that was used in the Juce codebase in their internal VST2 implementation, which has since been removed from Juce. You need to figure out what is the equivalent in the official VST2 implementation. If I had to guess, it would be effEditDraw.
(By the way, if you are working on a VST2 plugin, remember that you are not allowed to publicly distribute those anymore, if you didn’t sign the license agreement with Steinberg back in 2018.)
“effEditDraw” seems to be depreciated in the Steinberg SDK, as well
Right now the thingy is just for my personal use. When I am about to distribute it (other than the sources), I’d need to move it to be a VST3. Hoping that this is possible with JUCE…
-Michael
I could in a decent way do a source that does compile as a VST2 and at least shows some Reaper specific behavior (if we can call using a depreciated symbol in the SDK “decent”). The menu tags to “embed” the GUI in the MCP or TCP are enabled now, I suppose I’ll be able to get the real functionality working.
It also compiles as a VST3 and to do this the Steinberg SDK is not necessary to be installed. But the VST3 does not show any Reaper specific behavior. I did not yet try to debug this. @Xenacios: could you provide some pointers on how to patch JUCE to allow for Manufacturer specific communication ?
Thanks,
-Michael
I’d rather not, this is a thing that should be implemented by the Juce team into Juce. I haven’t looked into this stuff for over a year now and I’d need to rewrite, test and debug the solution I got working for VST3…(I am not using my edited version of Juce that had those changes anymore, those were done for Juce 5 and I switched to Juce 6 and I didn’t incorporate the changes.)
(Are there even any other hosts besides Reaper that allow using extended functionality via VST3 plugins? And if there are, do they implement using the API extensions in the same way?)
Of course I am not expecting that you might do a working patch for the current version of Juce.
But I might try to do that, and hence I’d like to have some hint on where to start.
I suppose the DAW needs to offer some means to have the VST plugin communicate in that way. Obviously this is implemented in Reaper as well for VST2 as for VST3. I do believe that other DAWs provide similar extensions of the VST API.
Thanks,
-Michael
Just to clarify : are you looking for a VST2 or VST3 solution? The VST2 one can already be done with the official Juce code. (But it’s not hugely useful because new developers can no longer release VST2 plugins.)
If course on the long run I am looking for VST3, as I’d like to provide the tool to the community (free & open source).
But as I know that there are some obstacles with VST3, I am just starting the project on VST2.
-Michael
Nothing I am not positive can be solved.
I was able to upgrade a project from using JUCE 5.x to the current 6.x. Works as a VST2. Compiles, but does not work as a VST3.
That project uses Reaper’s feature to embed the GUI of a VST (2 or 3) (or JSFX, and supposedly other plugin formats as well) in the TCP or MCP. The plugin is informed about that and supposed to show an appropriate minimal GUI.
Hence I suppose I can go on instigating on how to access the Reaper API from a VST2. I certainly need some help and / or documentation on that, but knowing that as well you as Helgoboss (ReaLearn) have been able to do this, I suppose I’ll be provided with this.
The VST3 issue will be considered later…
Thanks again,
-Michael
Yep.
I am not perfectly sure, but I think there are VST3s that do work with Reaper’s embedding freature. But those supposedly are not based on JUCE .
-Michael
When compiling to VST3, the functions handleVstPluginCanDo() and handleVstManufacturerSpecific() that we did override in struct VSTCallbackHandler , never are called.
I suppose this needs to be fixed somehow…
What do the VST3 specs say on that behalf ?
The VSTCallbackHandler in Juce only works for VST2 plugins. VST3 would need another class or the VSTCallbackHandler would need to be extended to support VST3.
That is what my guess was, and why I am astonished, that when building a VST3 these - seemingly useless - functions still are there to be overridden by a derived class, and not are rendered undefined to allow a compiler error to occur.
Obviously the VSTCallbackHandler needs to be enhanced with VST3 support. Maybe I can do this even if of course it would be much better if the JUCE team could come up with a solution.
Can you point me to a VST3 documentation that might show a way for doing so ?
