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 also 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 also 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
[msg] - Music Segment
You can enter these prefixes to region/track 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, 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 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 also 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
Cool thing is that, even if REAPER is not opened, 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 SoundSFX objects within Wwise. This accomplishes two things. First, it allows ReaOpen to find original blocks even if you moved 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 SoundSFX 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 checks in Wwise if these links are still valid. Since links are based on GUID (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 SoundSFX 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 SoundSFX object
Defining metatags is possible per Render Block and all properties listed within 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 are working, 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 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 middlewares by introducing features that allow flexibility and automation. Hopefully, it will help sound designers to 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.
Learn More about Grim Sync: https://www.lkctools.com/grimsync