RaiderPro: Engineering a Real-Time Automated Level Rider

---

The Pain

Audio engineers and music producers face a fundamental challenge: vocal tracks are naturally dynamic. A vocalist may whisper intimately in verse and belt powerfully in chorus—sometimes by 6–12 dB or more. Static compressors and EQ alone don't solve this problem:

• Compression flattens expression but often sounds unnatural or requires complex automation to preserve nuance.
• Manual gain riding is tedious, time-consuming, and difficult to execute precisely across entire sessions.
• Mixing balance becomes a trade-off: either the soft phrases get lost in the mix, or the loud phrases dominate.

RaiderPro's core mission: Provide intelligent, real-time dynamic gain riding that adapts to the signal without sacrificing expressiveness or requiring producer intervention.

System Architecture

The core design combines several processing stages:

• Vocal sensitivity analysis
• Adaptive noise gating
• Music/sidechain sensitivity
• Main rider processing
• Target-based level riding
• DAW automation integration

Rather than relying on a single detection mechanism, RaiderPro uses a two-path sensitivity system.

One path differentiates vocal content from low level noise bleeding & the second uses SideChain to ride the vocal above or below a reference track.

DSP Design

Vocal Sensitivity

Vocal Sensitivity controls how strongly the rider responds to the relationship between the input signal and the adaptive noise gate.

The system derives a reduction value from the gated signal:

const auto reductionFromGateRMS = noiseGatedRMS - inputSignalRMS;

The sensitized output signal is then shaped according to the selected sensitivity and the noise gate reduction:

float sensitizedRMS = sensitivity*reductionFromGateRMS + inputSignalRMS;

Conceptually, the process can be represented as a linear relationship:

y = mx + b

where:

• y = Sensitized signal
• m = Vocal Sensitivity
• x = Reduction produced by the gate
• b = Input signal level

This provided a controllable way to determine how much the adaptive gate should influence the rider's detection signal.

Music Sensitivity

Music Sensitivity extends the detection model by incorporating a sidechain signal.

Instead of treating the sidechain as a conventional compressor trigger, RaiderPro uses its level to modify the sensitized output signal:

auto sensitizedRMS = inputSignal - normalizedSCRMS * sensitivity * 6.0f;

The sidechain signal is normalized so that stronger sidechain levels produce greater correction.

This allows the rider to operate relative to another track.

For example, the system can be configured so that a vocal becomes more prominent when another track becomes louder, or conversely, so that the vocal gives way when the sidechain signal increases.

Music Sensitivity provides a range of -6 to +6 dB, allowing the relationship between the input and sidechain signals to be adjusted in either direction.

Real-Time Threading and Automation

One of the more challenging parts of the project was making automation state changes reliable while respecting real-time audio constraints.

Operations performed on the audio path need to be lock-free and avoid unnecessary synchronization, while host and UI operations could block the audio thread if not handled correctly. 

When the user changes the automation mode, the plugin follows a lock-free, two-lane update flow that separates UI notification from host/processor state application.

That's why  I used AsyncUpdater (JUCE's thread-hop mechanism): request now, execute later on the message thread.

The problem

A user can change the automation mode from the UI while the plugin processor is simultaneously processing audio.

The plugin therefore needs to communicate the new state without introducing locks into a time-sensitive path.

The solution

RaiderPro stores the latest automation state atomically:

The UI communicates the desired state, while the processor-side logic stores the pending state atomically and schedules an asynchronous update.

AsyncUpdater provides the thread hop to the message thread, where host-safe operations can be performed.

This separation allowed the system to avoid locks in time-sensitive paths while still handling automation gesture transitions such as:

• beginChangeGesture()
• parameter changes
• endChangeGesture()

The important constraint is that AsyncUpdater is asynchronous and therefore is not appropriate for sample-accurate DSP. Its role in this architecture is limited to control, host, and UI-safe operations.

This distinction between real-time DSP work and asynchronous control-plane work was an important part of the design.

DAW Automation Reliability

Automation support became an important engineering requirement because RaiderPro is intended to integrate directly into a producer's existing DAW workflow.

The plugin supports both:

Write mode

The rider generates automation that can be recorded into the DAW.

Read mode

The plugin follows previously recorded automation, allowing the producer to refine the result using native DAW automation.

This also makes it possible to "bake" the generated automation into the project and subsequently remove the plugin, freeing CPU resources.

Improving the reliability of this communication required careful handling of the boundaries between the plugin UI, processor, parameters, and host.

6. Performance and Real-Time Constraints

Real-time audio software places strict constraints on CPU usage and latency.

RaiderPro was designed to remain lightweight enough to be used across multiple tracks in a production session.

The resulting implementation achieved:

• RaiderPro achieves <1.5% CPU usage per stereo instance on an Intel Core i5-13420H (13th Gen, 8 cores, 2.1 GHz base) running Windows 11 Home (Build 26200) in Reaper DAW at 48kHz, 2048-sample buffer, with sidechain analysis enabled. Measurement taken from Reaper's native CPU meter during continuous playback of common vocal signal. This figure reflects DSP and UI rendering overhead. Performance may vary based on project complexity, buffer size, audio content, and concurrent plugin instances.
• Negligible plugin latency
• Support for real-time recording and session control
• Mono/stereo automatic routing
• VST3, AU formats
• Successful AU validation
• macOS notarization

The performance target was not simply about achieving a low benchmark number. The plugin needed to remain practical when instantiated across multiple channels in a real production environment.

From MVP to Production

The initial goal was deliberately modest:

Build a useful MVP, get it into users' hands, and let real-world feedback determine where additional engineering effort was justified.

Rather than attempting to build a highly complex riding algorithm from the beginning, I started with a simpler implementation and used iterative releases to validate the product.

Subsequent iterations addressed both technical reliability and user-facing functionality.

Some of the improvements included:

• Apple Silicon compatibility
• Windows compatibility
• A unit-test suite
• Attack modulation
• A smoother UI
• Improved host automation compatibility

This approach helped separate assumptions made during initial development from problems that were actually observed in production use.

Key Engineering Decisions

Several decisions had a particularly large impact on the final product.

Keep the initial algorithm simple

The first implementation prioritized getting a working product into users' hands rather than over-engineering the DSP.

This created a faster feedback loop and allowed subsequent development to be guided by actual usage.

Separate real-time and asynchronous responsibilities

The automation architecture explicitly separates time-sensitive processing from message-thread operations.

This reduced the need for locking while keeping host and UI operations in an appropriate execution context.

Use user feedback to guide iteration

Features such as attack modulation and improved automation compatibility were added based on observed user needs rather than being predetermined in the initial design.

Optimize for the real production environment

CPU usage, latency, DAW compatibility, and automation reliability were treated as first-class engineering requirements rather than secondary optimizations.

Results

The final system combined DSP processing, real-time constraints, host integration, and product iteration into a production-ready audio plugin.

Production impact

A process that could previously require approximately 30 minutes of manual vocal automation could be captured in a single performance pass.

The target-based approach also allowed level control while preserving more of the vocal's natural character than aggressive compression.

Technical impact

The implementation achieved:

<1.5% CPU per instance

while supporting sidechain analysis and negligible latency.

The plugin also passed validation and was packaged for multiple major plugin formats.

Workflow impact

Write mode provides automated level control that can be captured into the DAW, while Read mode allows the producer to refine the resulting automation natively.

This separates the generation of automation from the editing of automation, giving the user more control over the final result.

What I Learned

The most important lesson from RaiderPro was that building a real-time system is not just about getting the DSP algorithm right.

The algorithm is only one part of the product.

The surrounding engineering determines whether that algorithm can actually be used reliably:

DSP → threading → parameter state → host communication → automation → performance → compatibility → testing

A particularly important lesson was understanding where asynchronous mechanisms belong.

For example, AsyncUpdater is useful for safely transferring control-related work to the message thread, but it cannot replace real-time communication mechanisms for sample-accurate DSP.

That distinction influenced how I structured the automation system and helped keep the audio-processing path free from unnecessary blocking.

The project also reinforced the value of iterative development. Starting with a simple MVP made it possible to validate the core idea quickly and then invest engineering effort where real users demonstrated a need.

Conclusion

RaiderPro started as an attempt to automate a tedious audio-production workflow. It ultimately became a broader engineering project involving:

• C++
• JUCE
• Digital Signal Processing
• Real-time audio processing
• Lock-free state management
• Thread-safe communication
• DAW host integration
• Performance optimization
• Cross-platform development
• Unit/Functional testing
• Product iteration

The project gave me the opportunity to work across the entire stack of a real-time audio product—from mathematical signal processing to low-level threading and host integration, all the way through shipping and supporting a cross-platform application.

The full source and implementation details are proprietary, but the case study documents the engineering decisions and architecture behind the system.

Technologies

C++ · JUCE · DSP · Real-Time Audio · VST3 · Audio Unit · Multithreading · Lock-Free Programming · DAW Integration · Cross-Platform Development · Unit Testing

---