Cakewalk Adaptive Limiter–Behind the Scenes

Cakewalk’s Adaptive Limiter

The Adaptive Limiter, introduced in the SONAR 2017.05 Update, has been very well received by customers. Jon Downing, Cakewalk Software Engineer, reveals some of the DSP design decisions and efforts to create this fantastic new plug-in.

Building Character

When I started working on the Adaptive Limiter project, the team had already decided that the plugin would have a number of modes of operation, called “characters”. Each character would be suited to a different range of mixing or mastering scenarios. In order to gather ideas for these processing modes, we researched and analyzed the design of other well-known software dynamics processors. We also reviewed papers from the academic journals and conference proceedings that cover this sort of thing (AES and DAFx).

Early in the project, I spent most of my time with ideas based on existing algorithms for attack/release automation and dynamic transfer curve adjustment, as well as different signal processing topologies which affect the overall shape and sound of the limiter’s gain envelope. Basically, I tried to generate a “bag of tricks” of awesome dynamics processing DSP features, from transient enhancement stages to dual interpolated release curves. This is one of the most fun audio engineering/science projects I can imagine, so that was definitely a highlight of the development cycle for me!

We planned on sorting these DSP add-ons, enhancements, and permutations into groups, to try to build combinations that fit the sonic signatures from our original specification. When we sat down to do this, it turned out we had more than enough to work with. In fact, to cram in all the DSP we developed, we had to add in two extra toggle switches which were never in the original design. This was a late design decision made by the team which I was really excited about.

Exposing these features as toggles, instead of hiding them away in the character selection, allows for some really interesting sonic possibilities. For instance, I love the sound of the Aggressive character, which has a very quick linear attack curve, combined with the gentle adaptive transfer curve provided by the Soft Knee switch. I’d use this combination for styles of music which contain fast, detailed transient material, but also need to be mastered as loud as humanly possible (looking at you, metalheads). The adaptive knee allows you to bring the threshold way down, since the signal can now be driven deep into its range without distortion. At the same time, the sharp envelope tracks every double kick and pick stroke, keeping your signal’s dynamics intact.

Adaptive Limiter Character
Comparison of the envelope curves produced by the Adaptive, Aggressive, and Pumping character settings, with the same parameter settings and program material (EDM drum loop).

Decoding Compression

A feature I was just as excited to work on as the basic dynamics processing was the real-time codec preview. I wish that its development process went as smoothly as the main DSP part, but in reality, it had me pulling my hair out at times. The LAME encoding library, while very well documented, is typically used for encoding and decoding full audio files “offline”. For our plugin, we needed to encode buffers of audio samples into binary MP3 data, and then decode the binary data back into audio samples in real-time, without dropping or shifting any buffers. We also had to precisely determine the delay introduced by the full encode/decode cycle, for each encoding bit rate, in order for the artifact solo feature to work properly.

While all this can certainly be accomplished with LAME, I got pretty stuck at times. I can remember too-long debugging sessions with Logan Thomas (fellow Software Engineer) wondering why our dry and encoded buffers were out of alignment by 47 (or 13, or 117) samples. Difficulties aside, it was a great learning experience in working audio codecs, which I had not done much prior to working on the Adaptive Limiter.

MPEG frame size description
Description of the MPEG1/2 frame size, from the LAME technical FAQ. In DSP programming, we’re used to working with powers of two…none to be found here!

The Secret’s in the Smoothing

While I was given the job of developing the DSP for the Adaptive Limiter by myself, I was fortunate to have existing Cakewalk code to refer back to and draw inspiration from. Better than that, just a video call away, I had the expertise and counsel of none other than the esteemed developer behind the classic Cakewalk Concrete Limiter, the infamous Bob Currie.

After my first pass at DSP development, we really liked what we had, but still saw room for improvement. Specifically, we felt the Limiter sounded a little harsh and brittle on very dynamic material, when the envelope follower is rapidly switching between its attack and release stages. Since the time constant of the envelope following filter changes instantly during the switch from attack to release, a faint broadband “click” can be introduced in the signal’s spectrum, extending from DC all the way up to 20 kHZ. While this click is typically some 80 dB below the program material, and is often masked by it, it can become annoyingly audible during rapid dynamic changes. When we ran all this by Bob, he suggested a post-processing stage for the gain envelope, which he had developed for the Concrete Limiter. It ensures a smooth transition between the attack and release stages, without sacrificing any of the speed and punchiness of the “raw” gain envelope.

Adaptive Limiter Spectrogram Comparison
Spectrogram comparison of the Cakewalk Adaptive Limiter output (left) versus a competitor’s popular limiter plugin (right). The input signal has been low-passed at 3 kHz to reveal the broadband clicks introduced by rapid envelope switching. We don’t think you’ll miss the sound of those ugly clicks muddying up the frequency response of your project!

Having some “secret sauce” audio code just lying around–that happens to be perfectly suited for a sonic issue you’re facing–is a pretty awesome experience for an engineer to say the least. But it’s also pretty typical of working on music products at Cakewalk. One of the best things about working here is that in 30 years of developing music software, we’ve already solved a lot of audio problems. And with every release, we solve a few more!

17 Replies to “Cakewalk Adaptive Limiter–Behind the Scenes”

  1. Thank you for this article: I appreciate the insight into some of the issues you run in to, as well as some of the audio tics (in this case literally) of what to listen for. Good information!

  2. Great article – really appreciate the insights. I just used the adaptive limiter for the first time – and now I have to go back and remaster 25 yrs worth of work – the improvements are so pronounced! The hard work you and the team put into this tool was well worth it. Thanks to you all

  3. This is just the kind of juicy stuff your fellow propellerheads appreciate. More, please.

    As a follow-up, I’d be interested to know more about how you went about evaluating the AL’s performance during development and testing, and what methods were used to make objective comparisons against comparable limiters.

    – Bitflipper

  4. As a software engineer I have to ask why your sample offsets ended up being prime numbers. I wonder if the bug became some kind of sieve of eratosthenes or if the lame codec had primes as magic numbers.

Leave a Reply to Oscar Laun Cancel reply

Your email address will not be published. Required fields are marked *