Version

menu_open
Wwise SDK 2023.1.9
Authoring Plug-in Library Format

This page describes the plug-in format as well as the parts that compose a Wwise Authoring plug-in.

Library Plug-in Container

A Wwise plug-in dynamic library is a library that exports a plug-in container, listing all plug-ins provided by the library. This container is added to your plug-in library using a set of macros, as shown below:

// Library "MyPlugin.dll"
// MyPluginLib.h
// MyPluginLib.cpp

These macros take a container name as argument that must match your library name without prefix or extension. Each plug-in can then be added using the macro AK_ADD_PLUGIN_CLASS_TO_CONTAINER. This is all done for you when creating a plug-in using the wp.py development tool.

A plug-in created using the command wp.py new will have a sound engine part that can be built as a static library and will be automatically linked into the Wwise Authoring plug-in dynamic library. This same sound engine static library can be reused for linking in your game.

For details on the sound engine plug-in implementation, refer to Writing the Sound Engine Part of an Audio Plug-in.

Authoring Plug-in Structure

The Wwise Authoring plug-in comes in two parts: a mandatory backend part, implementing the logic behind how the properties of the plug-in are written to SoundBanks and manages any custom data. A frontend part is optional and is created as a separate class. The latter part is responsible for implementing custom graphical user interface. Both parts are added to the plug-in container independently with the AK_ADD_PLUGIN_CLASS_TO_CONTAINER macro.

Details on how to implement those two parts are described in more details in the following sections:

See also Model of an Authoring Plug-in to learn how to work with the plug-in properties.

Request Components and Services

Components providing a service such as your plug-in model can be requested using "Request" interfaces, e.g., AK::Wwise::Plugin::RequestPropertySet (refer to Property Set). These services are provided to the plug-in instance by the Wwise Authoring application at instantiation time.

Some interfaces add pure virtual methods that must be implemented and that will be called by Wwise. For example, deriving from AK::Wwise::Plugin::Source requires to implement the method AK::Wwise::Plugin::Source::GetSourceDuration, which tells the Wwise Authoring the minimum and maximum duration that can be expected from the source.

Components to use as services in your plug-in are all prefixed by "Request". When these services deal with objects that are owned by your plug-in, they provide an instance added as a member variable in your plug-in for use with the service methods (e.g., AK::Wwise::Plugin::RequestPropertySet is used with the m_propertySet object). Here is the list of components that can be requested:

Note: Some of those services add notification handler methods that can be optionally overridden.

Interfaces intended to be implemented are not prefixed. Here is a list of interfaces that can be added:

Troubleshooting

If you run into any problems, Help is available in the Wwise Source and Effect Plug-in Troubleshooting Guide.

#define AK_EXPORT_PLUGIN_CONTAINER(ContainerName)
(C++) Exports the plug-in container for a shared library.
#define AK_DEFINE_PLUGIN_CONTAINER(ContainerName)
(C++) Defines the unique plug-in container.
#define AK_DECLARE_PLUGIN_CONTAINER(ContainerName)
(C++) Declares the plug-in container.

Was this page helpful?

Need Support?

Questions? Problems? Need more info? Contact us, and we can help!

Visit our Support page

Tell us about your project. We're here to help.

Register your project and we'll help you get started with no strings attached!

Get started with Wwise