Blog homepage

A Simplified Pipeline for Creating Wwise Audio Plug-Ins

Interactive Audio / Sound Design / Wwise Tips & Tools

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.

 

1

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).

3-4

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.

 

4
 
5

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. 

 

6

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.

7

8

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.

 

9

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. I will also post a link in the comment of this blog article once the the slides and the video recording of the conference are available. 

2018-10-22_20-33-32

2018-10-22_20-36-23

 

 
Screen Shot 2017-12-14 at 5.24.24 PM.png

Interested in featuring your plug-in on the Audiokinetic Store? 

Subscribe

 

Joel Robichaud

Software Developer

Audiokinetic

Joel Robichaud

Software Developer

Audiokinetic

Joel Robichaud is a Software Developer with a combined degree in Computer Music and Computer Science. He is part of the Wwise Experience team at Audiokinetic and works primarily on user-facing software such as the Wwise Authoring and the Wwise Launcher.

 @joelrobichaud

Comments

Leave a Reply

Your email address will not be published.

More articles

Loudness Processing Best Practices, Chapter 2 : Loudness, dynamics and how to process them.

Translator's Note This is the second chapter of the Loudness Processing Best Practice for Games...

26.9.2017 - By Jie Yang (Digimonk)

Using Wwise in Game Jams and Micro-Projects

Game jams, as fun as they can be, can be stressful and frustrating from an audio point of view....

15.5.2018 - By Yoann Morvan

Drichtel: How I used spatialized audio for immersive art performances

Immersive art could be viewed as inherently redundant in that the principle of art itself requires...

28.8.2018 - By Axel Hélie Fontaine

The Making of SoundSeed Grain

We have wanted to build a general purpose granular synthesizer for Wwise for a very long time due...

11.12.2018 - By Louis-Xavier Buffoni

Continuity Assured

It’s been 18 years since we incorporated Audiokinetic, and 12 years since we released our very first...

5.2.2019 - By Simon Ashby

Ring of Elysium – The Sounds by Watson Wu

Watson Wu is an award winning American sound designer, field recordist and composer. Well known in...

16.4.2019 - By Watson Wu

More articles

Loudness Processing Best Practices, Chapter 2 : Loudness, dynamics and how to process them.

Translator's Note This is the second chapter of the Loudness Processing Best Practice for Games...

Using Wwise in Game Jams and Micro-Projects

Game jams, as fun as they can be, can be stressful and frustrating from an audio point of view....

Drichtel: How I used spatialized audio for immersive art performances

Immersive art could be viewed as inherently redundant in that the principle of art itself requires...