# Forward unhandled VST vendorSpecific() calls to AudioProcessor? **URL:** \ **Category:** Audio Plugins\ **Created:** [February 12, 2016, 9:14am UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650 "2016-02-12T09:14:43Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\ **Post date:** [February 12, 2016, 9:14am UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650/1 "2016-02-12T09:14:43Z")
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?   ---
**Author:** ![fr810](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/fr810/32/841_2.png) [@fr810](https://forum.juce.com/u/fr810)\ **Post date:** [February 15, 2016, 9:33am UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650/2 "2016-02-15T09:33:47Z")
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. ---
**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\ **Post date:** [February 15, 2016, 11:18am UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650/3 "2016-02-15T11:18:00Z")
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.   ---
**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\ **Post date:** [February 19, 2016, 2:49pm UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650/4 "2016-02-19T14:49:06Z")
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. ---
**Author:** ![ujam](https://avatars.discourse-cdn.com/v4/letter/u/2bfe46/32.png) [@ujam](https://forum.juce.com/u/ujam)\ **Post date:** [April 8, 2016, 7:46am UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650/5 "2016-04-08T07:46:05Z")
[deleted - somehow ended up in the wrong thread] ---
**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\ **Post date:** [January 27, 2017, 4:44pm UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650/6 "2017-01-27T16:44:12Z")
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: > [@Juce 4.2 broke VST3 over-shadows VST2 (Cubase)](https://forum.juce.com/t/juce-4-2-broke-vst3-over-shadows-vst2-cubase/20391/8): > > 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?](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650)) 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 Audi… ---
**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\ **Post date:** [February 1, 2017, 12:09pm UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650/7 "2017-02-01T12:09:53Z")
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. ---
**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\ **Post date:** [February 1, 2017, 3:32pm UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650/8 "2017-02-01T15:32:39Z")
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? ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [February 1, 2017, 3:36pm UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650/9 "2017-02-01T15:36:12Z")
> [@yfede](#): > > Do you think it is safe to rely only on that nowadays? As far as we know there aren’t any widely used compilers that don’t support it. ---
**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\ **Post date:** [February 1, 2017, 3:41pm UTC](https://forum.juce.com/t/forward-unhandled-vst-vendorspecific-calls-to-audioprocessor/16650/10 "2017-02-01T15:41:33Z")
> [@jules](#): > > As far as we know there aren’t any widely used compilers that don’t support it. I must admit it makes me a little uncomfortable, but I’ll take your wise word for it, it’s your library after all 🙂