handleVstHostCallbackAvailable(), handleVstManufacturerSpecific() and friends

Follow up to the thread " Attaching to the Reaper API VST2 vs VST3 "

By more research I found That the problems I described are not specific for the use of the plugin in Reaper, but the functions

and most important

can be used to attach to any VST host that provides the appropriate functionality in the VST API.

These functions just need to be overridden in a class derived from struct VSTCallbackHandler. By doing this, they are supposed to be called, (e.g) when the plugin is initiating.

I found and happily verified in an example I found and ported from JUCE 5.x to JUCE 6.x, that this works fine when I compile the code to a VST2 and load it in Reaper. I did not try other VST hosts, but I am sure that the same kind of code will work as appropriate.

When compiling the same code to a VST3 everything compiles perfectly OK, but these functions are not called using the same DAW.

I am positive that this is not because Reaper does not implement these functions in it’s VST3 API. I found discussions in Forums claiming that there are working examples of VST3s using this functionality on Reaper.

Moreover I found discussions in Forums that explicitly state that the JUCE framework nicely provides these function perfectly working for VST2 but not workable for VST3. This seem to be the currant state (since some four years).

Moreover I found discussions in Forums that claim that a rather simple patch for JUCE (5.x at that time) - seemingly not needing to deal with the complexity of COM interfaces that the VST3 API introduces, as this already perfectly is provided by the JUCE framework - would suffice to allow for enabling these functions when compiling to a VST3.

It seems the interface stuff needs to be provided in a host specific way. From the docu for “embedding” a copy of the VST GUI in Reaper’s Track or Mixer control panel:
" * to support via VST3: IController should support IReaperUIEmbedInterface "
(looks intimidating :frowning: )