I am sorry, but the committed solution breaks some code of mine. I’ll explain:
What I need to do is forward a
vendorSpecific() call received by my VST2 to the underlying
AudioProcessor, which implements the proper response to it.
For that purpose, I asked a feature to be added a while back: Forward unhandled VST vendorSpecific() calls to AudioProcessor?)
Since nothing came out of that request, I have resorted to changing the JUCE code in a minimal way myself: added a virtual callback to
AudioProcessor, and called it from the
handleManufacturerSpecific() method that was part of the VST2 wrapper, instead of immediately returning 0 from it (this is described in my second post in the topic linked above).
Your fix has now delegated the handling of that opcode to a free function (
handleManufacturerSpecificVST2Opcode()) that is completely outside of the wrapper.
While I understand your reason for doing so, this strips away that callback from its intended context, and it doesn’t even receive a pointer to the underlying
AudioProcessor, which makes it completely impossible for me to call that virtual callback I added to
AudioProcessor for my purpose.
Now, I’d like if you could solve this in one of the following ways (preferred way comes first):
Provide a way for
AudioProcessor to receive and respond vendorSpecific() calls that are not handled by the VST2 wrapper internally, which was my original request.
After much fiddling I don’t think there is a good cross-format way to do that, so I think that adding a virtual callback to
AudioProcessor like I did, possibly guarded by
#ifdef JucePlugin_Build_VST2, is acceptable.
handleManufacturerSpecific() method back into the wrapper, and call from there your free function
handleManufacturerSpecificVST2Opcode(). This will at least allow me to rebase my code with minimal changes.
Add to your free function an additional
AudioProcessor& argument, that I can use to call my virtual callback.