# Need help understanding VST3 extensions **URL:** \ **Category:** Audio Plugins\ **Created:** [September 20, 2021, 2:49pm UTC](https://forum.juce.com/t/need-help-understanding-vst3-extensions/47879 "2021-09-20T14:49:18Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\ **Post date:** [September 20, 2021, 2:49pm UTC](https://forum.juce.com/t/need-help-understanding-vst3-extensions/47879/1 "2021-09-20T14:49:18Z")
I’m about to try out the recently added `VST3ClientExtensions` class, my goal is to implement the `Presonus::IContextInfoHandler` interface. This already worked a while by a patch in the juce codebase that predated the `VST3ClientExtensions`. But to be honest, my understanding of this VST3 (com?) interface stuff is a bit limited, I think I get the rough idea, but I’m lacking some understanding of how all the pieces work together. What I found out so far is that `VST3ClientExtensions::queryIEditController` is called quite a few times, always passing in iids and then in case the iid passed matches the iid of the extension interface that I want to implement I set the pointer to the instance of my interface and return. Looking at the call stack to that function all the stuff that the VST3 wrapper does looks more or less senseful to me. And this all works great in reaper and I can see `Presonus::IContextInfoHandler::notifyContextInfoChange` callbacks arriving after doing so 🎉 Now what’s confusing to me is, that `Presonus::IContextInfoHandler` is derived from `Steinberg::FUnknown`, so I need to override `tresult PLUGIN_API queryInterface` to make it compile. Setting a breakpoint into the overridden function shows me that it’s never called – at least when testing with Reaper. The function signature looks nearly identical to `VST3ClientExtensions::queryIEditController`. Looking at the [ReaperEmbeddedViewPluginDemo](https://github.com/juce-framework/JUCE/blob/master/examples/Plugins/ReaperEmbeddedViewPluginDemo.h) code I see that there, both functions are overridden and basically both do the same internally but both are implemented at a different hierarchy level. So, could someone explain to me under which circumstances `queryInterface` might be called by whom and if it’s a valid assumption that it’s just fine to put all my logic into that function and just forward the call to `queryIEditController` to that? Or am I mixing up concepts here or showing a massive lack of understanding how the VST3 API is intended to work? ---
**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\ **Post date:** [September 20, 2021, 2:54pm UTC](https://forum.juce.com/t/need-help-understanding-vst3-extensions/47879/2 "2021-09-20T14:54:40Z")
Bonus question: In the [ReaperEmbeddedViewPluginDemo](https://github.com/juce-framework/JUCE/blob/master/examples/Plugins/ReaperEmbeddedViewPluginDemo.h) example, `EmbeddedUI` implements `addRef` and `release` which increment/decrement an atomic counter. However, that counter is never accessed. So what’s the purpose of that variable? ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [September 20, 2021, 3:23pm UTC](https://forum.juce.com/t/need-help-understanding-vst3-extensions/47879/3 "2021-09-20T15:23:58Z")
> [@PluginPenguin](#): > > So, could someone explain to me under which circumstances `queryInterface` might be called by whom… `queryInterface` will _probably_ not be called on an extension class, but it’s probably a good idea to implement the function so that it does the right thing (i.e. increment the refcount and return a valid pointer to the current instance if the IID matches), just in case the host does something unexpected and needs to sanity check the interface. > [@PluginPenguin](#): > > if it’s a valid assumption that it’s just fine to put all my logic into that function and just forward the call to `queryIEditController` to that? That’s fine if you only need to implement a single interface. If you are implementing multiple interfaces, you might wish to implement them all as separate classes, in which case `queryIEditController` will need to forward to each of those classes in turn. > [@PluginPenguin](#): > > In the [ReaperEmbeddedViewPluginDemo](https://github.com/juce-framework/JUCE/blob/master/examples/Plugins/ReaperEmbeddedViewPluginDemo.h) example, `EmbeddedUI` implements `addRef` and `release` which increment/decrement an atomic counter. However, that counter is never accessed. So what’s the purpose of that variable? The purpose is just to return a consistent value from `addRef`. If we were to do things absolutely properly, we would probably place an `EmbeddedUI` on the heap and manage its lifetime using refcounting. This felt like overkill for the demo, where the implementation is fairly lightweight and it’s safe to call `handleEmbeddedUIMessage` at any point as long as the plugin is alive. If the implementation were more expensive to keep alive, it might make more sense to implement the refcounting properly so that the interface could be destroyed once the host is done using it. ---
**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\ **Post date:** [September 21, 2021, 7:38am UTC](https://forum.juce.com/t/need-help-understanding-vst3-extensions/47879/4 "2021-09-21T07:38:30Z")
Thanks, that clears up most of my questions. > [@reuk](#): > > If you are implementing multiple interfaces, you might wish to implement them all as separate classes, in which case `queryIEditController` will need to forward to each of those classes in turn. Indeed, after throwing all into a single class at first where both member functions looked quite redundant, I went this way in the end with my `VST3ClientExtensions` subclass holding a pimpl-like member to the actual extension implementation, which now seems a lot cleaner and also keeps all the VST and extension headers away from the public interface. > [@reuk](#): > > `queryInterface` will _probably_ not be called on an extension class, but it’s probably a good idea to implement the function so that it does the right thing (i.e. increment the refcount and return a valid pointer to the current instance if the IID matches) So `queryInterface` should increment the ref count? This wasn’t clear to me from reading the example code, where the ref count is not incremented if I don’t get it totally wrong 🤔 Am I overlooking something in the example or is there any good reason why the example doesn’t increment the ref count? But yes, the Steinberg code documentation says so too… And while we are there, is there any special reason that the internal atomic counter is an `int` but return values are always casted to a `uint32_t`? I probably would have made the counter variable itself an atomic `uint32_t` if the `FUnknown` interface uses that data type. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [September 21, 2021, 10:10am UTC](https://forum.juce.com/t/need-help-understanding-vst3-extensions/47879/5 "2021-09-21T10:10:15Z")
> [@PluginPenguin](#): > > So `queryInterface` should increment the ref count? Yeah, I think you’re right, I’ll fix this in the demo. > [@PluginPenguin](#): > > And while we are there, is there any special reason that the internal atomic counter is an `int` but return values are always casted to a `uint32_t` No, not really, I’ll fix that too. Thanks for the feedback! ---
**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\ **Post date:** [September 21, 2021, 10:41am UTC](https://forum.juce.com/t/need-help-understanding-vst3-extensions/47879/6 "2021-09-21T10:41:29Z")
Great, thank you too for your responsiveness 🙂 ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [September 28, 2021, 6:21pm UTC](https://forum.juce.com/t/need-help-understanding-vst3-extensions/47879/7 "2021-09-28T18:21:33Z")
The suggested changes are now on develop, thanks again! >