This article was originally published on lkctools.com.

Introduction

This is a short overview of the features of Grim Sync, the latest system to connect REAPER and Wwise. It allows you to define file names, containers, Events, and even object properties. It is possible to import sounds, voices, and music with Grim Sync. The focus is on allowing you to create complex structures directly in REAPER and to iterate quickly. If you are interested in the idea behind the tool and the motivation for creating it, you can read more about it here.

Basic principle

Grim Sync is based on a custom REAPER workflow called Render Blocks. Those are groups of items, visually and functionally packed into blocks, which allow you to have rendering flexibility, better project organization, automatic naming, and various metatags that affect render settings. Using blocks saves time and speeds up the export process.

Example of packed and named Render Blocks

Tracks & regions as containers

One of the features of Render Blocks is to use the hierarchy of tracks, regions, and metatags to define file names. This way you can create a structure inside an rpp project, and then use it to name the files. If there is more than one file with the same name, they will be indexed. 

Track Hierarchy:
        Dragon
        Fire
                Burst
                Sizzle

Resulting file names:
        Dragon_Fire_Burst.wav
        Dragon_Fire_Sizzle_01.wav
        Dragon_Fire_Sizzle_02.wav
        Dragon_Fire_Sizzle_03.wav

Example of Render Blocks named using track + region nesting

You can also choose the order in which you want the file name to be created using different formulas.

Various AutoNaming formulas

With Grim Sync, the idea is to use the same structure to create Wwise containers.

Example:
        [a]Dragon
                [r]Fire
                        [b]Burst
                        [sq]Sizzle

Results:

• FILE: Dragon_Fire_Burst.wav
• PATH: \<Actor-Mixer>Dragon\<Random Container>Fire\<Blend Container>Burst\<Sound SFX> Dragon_Fire_Burst

• FILE: Dragon_Fire_Sizzle.wav
• PATH: \<Actor-Mixer>Dragon\<Random Container>Fire\<Sequence Container>Sizzle\<Sound SFX> Dragon_Fire_Sizzle

There are different prefixes that represent various Wwise objects, including music containers.

• [wu] - Work Unit
• [f] - Virtual Folder
• [a] - Actor-Mixer
• [r] - Random Container
• [sq] - Sequence Container
• [sw] - Switch Container
• [b] - Blend Container
• [msw] - Music Switch Container
• [mpl] - Music Playlist Container
• [msg] - Music Segment

You can add these prefixes to track/region names manually, but there are also toolbar and shortcut actions that you can use to speed up the process.

Custom Grim Sync actions toolbar in REAPER

Special red actions allow you to ignore specific tracks/regions so their names are not included in the resulting file name or hierarchy.

Once you are done with naming, you can run Grim Manager.

Using Grim Manager 

The manager is there for a number of reasons: to see the list of audio files to be rendered; to preview the designed Wwise hierarchy; to create Play and Stop Events from specific containers/sounds, and to validate existing links to the Wwise objects.

Grim Manager showing structure and audio files

Invalid Structures

If you try to create a hierarchy that is not possible inside Wwise, for instance, an Actor-Mixer inside an Interactive Music Hierarchy, you will get an error and syncing will not be allowed until you fix the problem.

Actor-Mixer is not allowed within the Interactive Music Hierarchy

Creating Events

Events can be created automatically from all objects except Work Units, Virtual Folders, and Actor-Mixers. You can simply check the box next to the container and you will see the resulting Event name inside the Event List section. Additionally, you can define which Events will have a corresponding Stop Event, which is helpful for loops. Event prefixes and suffixes can be defined within project settings.

Three Events will be created from two containers and one sound

Two Stop Events will be created for respective Play Events

Running GRIM SYNC action

Once we are satisfied with our sound design and structure design, we can click the GRIM SYNC button. This will render all files, import them to Wwise, and create containers and Events.

Resulting hierarchy in Wwise

Iterating with ReaOpen

When you decide that some sounds in Wwise need to be reworked, you can simply right-click them and call ReaOpen. It is a separate and free tool that works by finding the original sound inside REAPER. 

ReaOpen context menu

The cool thing is that, even if REAPER isn’t open, the tool will run the program, open the corresponding rpp project, and find the original sound. You can then edit the sound and run the GRIM SYNC action again, and the sound will be updated inside Wwise.

Customizing Import Locations

By default, all sounds will use Actor-Mixer Hierarchy\Default Work Unit as a root import location. However, you can use link regions, or link tracks to specify the custom location where you would like to create the structure. They can be defined for Event root location as well.

Wwise Link Region

Wwise Link Track

Linking sounds to Wwise objects

This feature allows users to permanently link blocks to Sound SFX objects within Wwise. This accomplishes two things. First, it allows ReaOpen to find original blocks even if you changed their location inside the timeline of a REAPER project. Secondly, it allows for changing the structure in Wwise. You can move sounds to different places, create parent containers, and even rename Sound SFX objects without losing the connection to the original REAPER sound.

Exported and linked blocks

Validation Process

This process is what allows linked sounds to be so flexible. Validation runs through track/region links and also through linked blocks and then checks in Wwise if these links are still valid. Since links are based on GUID (a unique id dedicated to each Wwise object), the validation process will report errors only when objects have been deleted from Wwise.

Block after failed validation process

Details of the validation report

Wwise Metatags

Metatags are a Render Blocks feature that allows you to specify certain render settings per block. For example, you can render mono, stereo, and surround audio files at the same time. You can specify desired loudness, or how long the tail should be.

Render Blocks with multiple metatags defined

Wwise Metatags are the same, but they affect Wwise Sound object properties like Volume, Pitch, Lowpass, Highpass, InitialDelay, etc. They are defined with a hashtag (#) prefix.

Naming editor specifying Wwise Metatags

Resulting changes in the Wwise Sound SFX object

Defining Metatags is possible per Render Block and all properties listed in the Wwise documentation should be available (except for read-only values).

Creating Timeline Group

Using Wwise Metatags and a special REAPER action called Add timeline delay metatags to selected blocks, you can keep a relative temporal relationship between a group of sounds in REAPER.

Timeline group created by using a custom script

After importing to Wwise, you can use them within a Blend Container to get the same resulting sound without baking silence into your assets.

Sounds will retain their relative temporal relationship

Smart Subpaths

There are two types of Smart Subpaths, one for the Originals, and one for Events. The idea behind both of these is to define a set of container types that will be taken into account when choosing where in the Originals folder to import sounds, or where in the Events hierarchy to create Events. The goal is to partially or fully mirror the container hierarchy within the Originals/Events hierarchy.

Track hierarchy in REAPER with predefined container types

Smart Originals Subpath settings

Resulting hierarchy in Wwise

Smart Originals Subpath affecting audio file locations

Smart Events Subpath affecting Event locations

In short, the Smart Subpaths feature allows you to predefine the level of depth that you want to keep for Originals/Events, and once you decide that, your job is done; everything will be done automatically. However, caution is advised when changing structure in Wwise post-import because that will also affect how Smart Subpaths work, so be careful.

Single Items & NVK Folder items

Although Grim Sync is based on Render Blocks, there is also support for single items and NVK Folder items. The prerequisite for those to be detected by Grim Manager is to name them with @ prefix. The idea behind this is to allow people who are not used to the Render Blocks workflow to still benefit from Grim Sync.

Single items named with @ prefix

NVK Folder items named with @ prefix

Conclusion

Since games are becoming more complicated and larger every year, there is an overwhelming need for optimizing all production workflows, including audio. Game audio still suffers from the legacy of tools that were originally created for music production and post-production of linear media. Grim Sync is an attempt to evolve the communication between DAWs and middleware by introducing features that allow flexibility and automation. Hopefully, it will help sound designers focus more on creating awesome sounds and spend less time on manual tasks like naming, dragging, clicking, and scrolling. Grim Sync has a free version, so if you are interested in trying it for yourself, you are more than welcome to do so.