**Originally posted January 15, 2019**
Developing audio plug-ins for Wwise is fairly different from developing audio plug-ins for a digital audio workstation (DAW). The interactive nature of Wwise, as well as the sheer amount of platforms to support, makes it quite complex for a newcomer to get a grasp of it all. Even with the tooling we had developed internally, our plug-in development pipeline was just needlessly hard to understand and made creating new plug-ins a chore. We thus decided it was time to simplify and / or rewrite some of these tools, taking the opportunity to make them available to the plug-in developers out there. Read on for a deeper look into these new tools and how you can use them to easily create your own audio plug-ins for Wwise!
Where Did I Leave My Tools Again?
The plug-in development tools have been introduced in Wwise 2018.1.3.6784, which is available for download today through the Wwise Launcher. If you want to follow along this article and create your own plug-in, I suggest that you install it on your system, along with the Windows_vc140 SDK platform. You will also need to have Python (any version is fine) and Visual Studio 2015 installed. The tools themselves are accessible through a single entry point, which is located in /Path/To/Wwise 2018.1.3.6784/Scripts/Build/Plugins/wp.py. For the sake of simplicity, wp will be used to designate the full path to wp.py throughout the article.
Scaffolding a Better Future
Samples are great. They give us a look into how a given framework can be used in the real world, which is crucial when you’re just getting started with such framework. But what happens once you’re done reading through the samples? Do you just delete the unimportant parts of the sample closest to the application which you want to build, and work your way from there? I personally find this process error-prone and would rather avoid it. To solve this issue and make creating new plug-ins a more pleasant experience, we created a plug-in generator with scaffoldings available for the most common plug-in types (effect, source, sink or mixer).
The generated project contains all the files you need to start working on your plug-in. It contains the code of mostly empty but functional Sound Engine and Wwise Authoring plug-ins, as well as some configuration files (which we will have a look at a bit later).
Build Multiple Times, Works Everywhere
Wwise supports a massive amount of platforms, which is both amazing and unfortunate for developers. On one hand, it makes it very easy for game developers to integrate Wwise into their engine without worrying that one of their target isn’t supported. On the other hand, it makes it really hard for plug-in developers to support all of these platforms, especially since some of them require a license. An alternative would be to create a Windows-only plug-in that can then be used inside of Wwise to pre-render effects, but doing so you lose the interactive part of the plug-in.
With the new development tools, managing and building for all of the platforms that Wwise support is much easier. You still need to install the development tools for that platform, but once that is behind you it is simply a matter of calling wp.
The result of the build is directly output into the Wwise directory from which wp is called, making the build-test-adjust cycle much faster than it used to be.
The Arcane Art of Packaging
Packaging is, in my opinion, the part of the development process that should just be done magically. There is no reason for a user to learn how our packaging system works, just to realize that they have to either re-implement it themselves or do its job by hand.
The package sub-command automatically retrieves the build artifacts from known locations for a given platform and archives them in the .tar.xz format. The generate-bundle sub-command is the last step and should be done after all of the platforms have been packaged. It generates a bundle.json file from the bundle_template.json that should be located at the root of your plug-in directory. The later is self-documented using comments and can be edited prior to running the command to fill some information about your plug-in (image, description, documentation links, etc.). The files resulting from these last two steps can then be shared and installed through the Wwise Launcher.
Beyond Wwise Plug-Ins
At the end of the day, audio plug-ins are audio plug-ins, regardless of their target host, be it Wwise or a DAW. Apart from some particularities of the target host, every audio plug-in has a user interface with parameters that can be edited in real-time in order to drive some digital signal processing code. This means that it would be possible to target both Wwise and DAWs using mostly the same code base.
I recently explored that possibility using the JUCE audio plug-in development framework and presented my findings at this year’s Audio Developer Conference (ADC’18).
Get the presentation slides here.
If you are interested into making an audio plug-in for Wwise using JUCE, I suggest you have a look at Voluminous, the case study that I presented, which is available on my Github.
Interested in featuring your plug-in on the Audiokinetic Store?
Comments
Denys Weng-Law
October 23, 2019 at 03:47 pm
This is really AWESOME !