Using Vst2Wrapper in a project is currently not source compatible with using SingleComponentEffect for your VST3 plugin. The reason is due to the macro hackery in the SingleComponentEffect header and source files used to rename getState and setState in IEditController. The problem with this macro hack is that it only works when the interface for IEditController is pulled into any compilation unit via vstsinglecomponenteffect.h before any chance of being pulled in via ivsteditcontroller.h or any other child class of it in the SDK. When that’s not the case (such as with vst2wrapper.cpp), then you get v-table mismatches for the class between compilation units.
Vst2Wrapper either needs to become “SingleComponentEffect aware” somehow, or ideally best would be to just rename the getState and setState methods in IEditController to something that does not clash with IComponent. I realize that that would be a source-breaking change, but this code is always going to be fragile if it remains used the way it is in a multiple-inheritance situation.
I’ve been using the VST2 wrapper with the SingleComponentEffect object for about two years now. And, yes the issue you described is a problem. It forces you to order the #includes in a certain way. This is what mine look like in the SingleComponentEffect derived class’s .h file:
// — first
#include “public.sdk/source/vst/vstsinglecomponenteffect.h”
// NOTE: the wrapper include here MUST:
// be AFTER the #include vstsinglecomponenteffect AND
// PRECEDE any #include that references vsteditcontroller,
// which is #include “vstgui/plugin-bindings/vst3editor.h” below
#include “public.sdk/source/vst/vst2wrapper/vst2wrapper.h”
// — VST3EditorDelegate
#include “vstgui/plugin-bindings/vst3editor.h”
etc… followed by the derived class declaration.
Then, in the .cpp file, the #include “vstprocessor.h” is the very first #include statement.
An interesting solution! In my code, I renamed the getState/setState functions in my code and in the SingleComponentEffect class in the SDK, using separate proxy classes for the EditController and IComponent classes, deriving SingleComponentEffect from those proxies instead, and calling distinctly named functions for getState/setState, depending upon which proxy class was forwarding the call.
But I like the idea of just carefully arranging the includes, provided it resolves all issues. One of the issues I had wasn’t even with using the Vst2Wrapper, but with calls through the vtable going to the wrong function, causing crashes. Resolving the getState/setState conundrum got rid of that issue.