Wwise Plugin Resource File Plug-In Not Installed

Question

Hi, I've been following boilerplate Wwise plugin doc, and I eventually generated 2 faders (without GUI) and connected random attributes to them(using VS2022 and building by VS also). So far there was no problem, all working with DSP side as well. But, after I tried to add up resource.h and GUI (as it shows in documentation), after I build the solution again, in Wwise, I started getting "The selected Audio effects plug-in is not intalled." error. While I can see the plugin on the list, when I choose, it only shows that error on the page.
class TestFXPlugin final
    :   public AK::Wwise::Plugin::AudioPlugin
       ,public AK::Wwise::Plugin::GUIWindows, public AK::Wwise::Plugin::PluginMFCWindows<>
is the frontend class, when I leave it like that (even without other function overrides) it gives the error. It might be an initializing thing of those maybe.
I think it's GUIWindows class, if I delete that inheritance, it (at least) shows 2 basic faders without GUI

So far;
- I tried to build it with VS2019, still the same
- I changed Premake lua file and added resource header and .rc file, still the same (also it's not necessary)
- I tried building it with wp.py commands, both for Authoring and Win64, still the same error
- I didn't change any ID of the plugin xml file, but when I change it doesn't even show the previous (without GUI) version
- Also, when I comment/delete those GUI related codes, it returns to 2 basic faders (non-GUI) version and it works normally
So, how can I add that GUI functionality and what could I be missing?

Answer 1

The issue is that you are implementing both AK::Wwise::Plugin::AudioPlugin (the backend plug-in interface) and the AK::Wwise::Plugin::GUIWindow (the frontend plug-in interface) in the same class. This does not yield a compilation error, but Wwise is unable to determine if your class is a backend or frontend instance and fails loading as the plug-in is malformed. I'll take note in the system that this can be improved on to provide better diagnostic and details in Wwise as to what went wrong when loading the plug-in.

You can remove AK::Wwise::Plugin::AudioPlugin from the inheritance list and only implement AK::Wwise::Plugin::GUIWindows (with PluginMFCWindows only if you need MFC to automatically instantiate the CWinApp class).

You can refer to samples under SDK/samples/Plugins for fully functional plug-ins with a GUI (see the Win32 directory for the GUI files).
You can also refer to the Wwise Up on Air - Creating Plug-ins for Wwise Part 2, which covers GUI creation for Wwise plug-ins.

Comments

I've tried that also, even emptied the class functions, just to see if that shows up on effect, but still the same plug-in is not installed error.

I've been following that youtube video, its GUI creation is old, such as class names or places to inherit. That's why I find those placeholder functions in documentation and tried.

For instance, I inherited GUIWindows only, it has constructor/deconstructor/GetResourceHandle/WindowProc/GetDialog and DECLARE_AUDIOPLUGIN_CONTAINER function at the end/out of class.

Same goes for .cpp file with documentations boilerplate and those functions;
DEFINE_AUDIOPLUGIN_CONTAINER, EXPORT_AUDIOPLUGIN_CONTAINER, ADD_AUDIOPLUGIN_CLASS_TO_CONTAINER, DEFINE_PLUGIN_REGISTER_HOOK, DEFINEDUMMYASSERTHOOK

I can send the files even, or you can send me a boilerplate proven file that I can look at it.
Thanks

---

Your best bet is to compare your code with SDK/samples/Plugins/AkDelay/Sources/WwisePlugin/Win32/DelayPluginGUI.h/.cpp. This sample comes with a Visual Studio solution you can build yourself and use as comparison. For example, if I remove all the content of the class, the plug-in loads fine (with the default UI, since the default GetDialog implementation provides no dialog to Wwise), so this is expected to work.

On the plug-in container: it's used as a repository that exposes all of your plug-in classes to Wwise (you can think of it as a list). The container itself only needs to be instantiated once, and this is usually done in the backend part of the plug-in: the boilerplate to declare, define and export the container should not be reused for the frontend part of the plug-in. If you used "wp.py new" to create your plug-in, this is already the case by default.

Then, in the frontend .cpp file, you can just register the GUI class with AK_ADD_PLUGIN_CLASS_TO_CONTAINER. Again, this is the case by default in the files generated by "wp.py new".

---

Thanks Samuel, I'll check up this file, that sure helps about further development for myself.

Edit: It worked, I've been missing Win32 file components

---

Glad you were able to make it work. Happy coding!