One of the least known characteristics of the Wwise ecosystem is its extensibility. Companies create their own plug-ins for their projects, and vendors migrate their own plug-ins to Wwise, sometimes with our help. With the new version coming soon, our venerable system is about to get its first major overhaul!

In this series, I will be discussing the design choices for authoring plug-ins for Wwise, as well as showing the new API for the first time.

• Part I: History and Goals
• Part II: Anatomy of a Plug-in
• Part III: Creating a Plug-in

Part I: History and Goals

Plug-ins are at the center of the Wwise vision. The ability to use effects, sources, and to add that extra feel to your project. If you're not happy with the dozens of optionally installable plug-ins available through the Wwise Launcher, there are more available than meets the eye. You can choose from over two dozen bundled plug-ins, and the number of community plug-ins continues to grow.

There are two parts to every plug-in: one in Sound Engine, which gets bundled in your product’s executable; and one in Authoring, allowing you to set up exactly what you need.

Legacy

For the past 15 years, the system for creating plug-ins has been refined and kept tightly integrated with both Authoring and the Sound Engine. So integrated, in fact, the structures and functions of the plug-ins have been the ones used internally to build everything else!

This is obviously a double-edged sword. It means the system is tightly integrated and there are no unoptimized paths. But it also stops us from doing any kind of refactoring and modification in internal structures. The opposite is true, while we couldn’t change internal structures, we tried to gel the plug-in interface to make things compatible between versions.

Now, for the Sound Engine, this currently makes sense, as your product needs to run efficiently and fastest. But in Wwise Authoring, this became a liability, as everything was based on Windows APIs.

The Times, They Are A-Changin’

While our bread and butter is to support every platform, current generation and next generation, this got sidetracked for the Authoring side. In the Sound Engine, our team works tirelessly to support new SDK, new platforms, while trying our best to support customers who are shipping products in need of fixes and improvements. If you believe your product has a huge support matrix, you haven’t looked at our build machines! But in Authoring, for many years, our customers were content with a Windows version, as well as a ported Mac version.

In our dreams and priorities, it became increasingly clear that we need to get better at being cross-platform. Fifteen years ago, with the Xbox and Windows PC being our first supported platforms, it was easy to choose for simplicity and tightly integrate with Windows. Slowly, over the years, the Internet became mainstream, games started being streamed, and developers started using Linux as their back-end servers, while iOS and Android hijacked the smartphone world, and Mac took back its past glory of being a creative platform of choice. Having a single platform code base started becoming increasingly a liability.

Same for programming languages: According to the TIOBE Index, usage for C++ dropped to 6% from its more than 16% high, while newcomers such as R started progressing and Python became a destination of choice. Merely taking a piece of code in 15 years C++ won’t compile in C++17. Or even programming methods: the unit testing method continues to gain traction, and the Scrum development method is now ingrained in many company’s cultures, while Waterfall in Microsoft Project used to be the norm. Apple has its own CPU and Microsoft Visual Studio generates code for Apple devices and can even run on Mac. We finally got ray tracing, and most users have at least four cores on their CPU. A lot can change in 15 years!

Baby Steps into the Elevator…

Four years ago we started working on weeding out the root causes of our issues, not only fixing the visible layers. One doesn’t change the 2.2 million lines of C++ code (2017) in 12,000 files by flicking off a switch, though. It takes time and dedication. The plug-in code alone now contains hundreds of functions, many of which had never been touched since the first version left the oven. All the pieces need to slowly fall in-place while production stability is maintained, things need to be fixed without people noticing.

A simple example: Authoring code is mostly Wide-char, which is two bytes per character. Our plug-ins have reflected that. Also, Wide are two bytes on Windows, but Wide are four bytes on Mac, so this means different results and code on different platforms. During those years, UTF-8 became an increasingly good and standardized choice for cross-platform development, so we began the process of migrating a lot of the infrastructure to UTF-8, the results of which have started to emerge in the 2019.1 & 2019.2 releases. It still has a way to go in the future.

Another example: The venerable WwiseCLI executable, which still allows Wwise to be run in a command line today, was an afterthought at the time it was created: that executable ran the full graphical interface in the background! That graphical interface is tightly integrated with Windows and so after two years worth of refactoring, where the interface got split into its cross-platform logic part and a Windows GUI part, WwiseCLI finally got its overhaul in 2019.1, running only the logic part and not just a command line front end. But we didn’t stop there, and continued to improve and modernize the code manifested in the WwiseConsole as part of the 2019.2 release. 

Plug-ins Revisited

In 2019.2, things started to get real for new plug-ins. Not known to the user, the first next-generation plug-ins started to be released while in production. Simple plug-ins, obviously, but still! We started gathering feedback about the stability of these and the best thing happened: we got very little feedback indeed! It meant there were no apparent differences between what is now called a legacy plug-in and a new plug-in! (Not even in performance) Although some functions are slower and everything is bridged, it also means that it’s much easier to implement new features in plug-ins, as well as to improve performance in Wwise Authoring.

This also means since 2019.2, we have been supporting legacy plug-ins as well as new plug-ins concurrently, and we will continue to do so for as long as it makes sense.

Goals for the new 2021.1 plug-in API

Bring Out the Crystal Ball

The first plug-in version was created alongside Authoring more than fifteen years ago. This version should allow Wwise Authoring to grow for the next fifteen years! This is the most important goal, what would a plug-in interface be if it constantly changed?

You will see this being reflected in all the other goals.

Allow Plug-ins for Any Platform

The plug-in code should be identical across all of the platforms that Wwise supports. Who knows how the Authoring experience will evolve in the future? When the cross-platform project started, we wanted to have a native Mac and Windows executable, and have a graphical interface as soon as possible. We initially thought it might be a good idea to have a version without a graphical interface. When we got the first results, it turned out our early adopters wanted to be able to generate their sound banks on Linux too. And this is only the start: efficient generation through the command line, WAAPI servers, headless, tighter integration in Unreal and Unity. With the increasing capability of handheld devices, who knows where this will end.

C++ Is Not for Everyone

As you’ve read before, C++ is only one of many languages that can be used for plug-in development. These days, people are interested in creating plug-ins using multiple programming languages. With 21.1, we will even provide example code running with Python for the Sound Engine! We don’t want to limit plug-ins. The idea that “Plug-ins should be in an optimized language” is still true for C++, but also for other languages.

As such, the new Authoring plug-ins have a C infrastructure, which is ABI and API stable. Even with newer versions, the entire interface brings stability to plug-ins created using any language. While the provided modern meta-programming bridge allows a C++ plug-in to be created simply and efficiently.

The Best Plug-in is No Plug-in

There will always be a need for a Sound Engine plug-in in-order to extend functionality. But if we could create an entire plug-in without having an Authoring side, it would be the best. With hundreds of available methods, creating a pipeline to allow for the simplest use cases is a high priority.

Backward Compatibility

It’s clear with all the changes happening to plug-ins that a lot of work on plug-in vendors is expected. Our goal is always for this process to be as seamless as possible. This is why Legacy plug-ins still exist: while it’s not optimal, and the plug-in won’t be cross-platform compatible, you can merely recompile the plug-in with the latest 21.1 SDK and it will work on Windows by default.

This is also true for all future versions: setting the wanted SDK version and compiling back with the latest version will make sure the interface stays compatible for as long as we can.

Since backward compatibility eventually becomes a liability, those temporary bridges will eventually be removed, but for as long as they aren’t causing issues, they will be kept.

Legacy bridging will be the first one to disappear, as it disallows cross-platform compatibility. But for 21.1, no fixes are needed.

Expandable, Now With Versions

Because the code will continue to persist and transition across releases, we should expect changes to interfaces including: additions, modifications, and removal. A really simple example: in 21.1, no cross-platform GUI is yet available, as we prepare to make the switch for Authoring first. Also, plug-in types could theoretically be done by third-party vendors, such as conversion and analysis plug-ins, but these are currently impossible to implement.

Test Everything

So many changes mean FUD (Fear, Uncertainty, Doubt). So many years of work aren’t free either, and we want to do the Good Thing™. This Wwise Authoring part is a great test bed for other parts of the plug-in. Maybe this will be a base for Sound Engine’s improvements. Who knows?

One of the least known features of the Wwise ecosystem is its extensibility. Companies create their own plug-ins for their projects, vendors migrate their own plug-ins to Wwise, sometimes with our help. With the new version coming later this year, our venerable system is about to get its first major overhaul!