top of page

GRIM SYNC - Advanced REAPER to Wwise bridge system

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


Comments


bottom of page