Forward unhandled VST vendorSpecific() calls to AudioProcessor?

Audio Plugins
1

As per subject, I'd like to respond to some custom vendorSpecific() call received by the VST wrapper.

Currently, the only way I could do this is by manually adding the code that handles my cases to the body of the vendorSpecific() call that already exists in juce_VST_Wrapper.cpp.  

It's easy to do, but I'm not very much a fan of modifying JUCE code unless there is REALLY no other way around it.

So, wouldn't it be possible for those calls that are not directly handled in the VST wrapper, to be forwarded to the underlying AudioProcessor to give it a chance to respond to them with a aptly named virtual callback?

 

2

This sounds like a good idea. I'll discuss this with the team on how to do this best in a wrapper agnostic way. If you have any recommendations or code to share that would be great.

3

Well, in my case I only needed it for VST so my changes are tailored towards that format and are quite straightforwarded:

in juce_VST_Wrapper.cpp

VstIntPtr vendorSpecific (VstInt32 lArg, VstIntPtr lArg2, void* ptrArg, float floatArg) override
{
    // original code here

   /* this was a 'return 0', but we let the AudioProcessor handle
    custom vendorSpecific() calls (and provide a return value accordingly) */
    
    return filter->handleVstVendorSpecific (lArg, lArg2, ptrArg, floatArg);
}

then, in juce_AudioProcessor.h

/* by default, return 0 for unhandled vendorSpecific() calls in accordance to specification */
    
virtual int handleVstVendorSpecific (int lArg, int64 lArg2, void* ptrArg, float floatArg) { return 0; }

I haven't checked if something similar is available in other formats in order to "merge" all those callbacks in one "agnostic" one.

Also, I'm not sure that'd be a good thing to do anyway, because I expect all the cases where this is needed, to be very specific to the format being used, so it may actually be good for the AudioProcessor to know that a "vendorSpecific" is coming from the VST and not from the AAX, for example.

Also, for example, in the case that a VST vendorSpecific() and a hypotetical such call for the AAX serve the same known purpose (let's call this "some feature"), I think that this peculiar case should be handled by the wrappers and, if specific behavior by the AudioProcessor is to be expected, this should belong to another entirely different callback, called "someFeatureCallback", if you get my point.

 

4

While building this also on Mac, some warnings have shown that int64 is a better fit for the second argument of the callback inside AudioProcessor. I have changed the code in my previous post to reflect this.

5

[deleted - somehow ended up in the wrong thread]

6

Any chance to see this implemented?

It’s almost a year now and, as explained in the other post linked below, the recent release of JUCE 4.3.1 has made it even more difficult for us to modify JUCE in order to achieve the desired result.

It really would be appreciated if the JUCE team were willing to implement one of the proposed solutions, which are also mentioned in the linked post:

7

I’ve just pushed some changes to the develop branch.

Now, if your custom AudioProcessor class inherits from a new interface class, VSTCallbackHandler, then your AudioProcessor will receive VST vendor specific calls via the corresponding pure virtual method.

8

Thank you very much.

I see the newly added header for VSTCallbackHandler does not have “traditional” include guards, it only relies on #pragma once.

Do you think it is safe to rely only on that nowadays?

9

As far as we know there aren’t any widely used compilers that don’t support it.

10

I must admit it makes me a little uncomfortable, but I’ll take your wise word for it, it’s your library after all :slight_smile: