{"id":4277,"date":"2018-01-12T13:24:13","date_gmt":"2018-01-12T18:24:13","guid":{"rendered":"https:\/\/splice.com\/blog\/?p=4277"},"modified":"2025-03-19T13:54:12","modified_gmt":"2025-03-19T17:54:12","slug":"optimizing-serum-cpu-efficiency","status":"publish","type":"post","link":"https:\/\/splice.com\/blog\/optimizing-serum-cpu-efficiency\/","title":{"rendered":"Optimizing Serum for better CPU efficiency"},"content":{"rendered":"
Illustration:\u00a0<\/em>Maria Chimishkyan<\/em><\/a><\/h6>\n

Xfer Records\u2019 Serum is a powerful, versatile wavetable synthesizer VST that has received near-universal acclaim from reviewers and everyday users alike.<\/h1>\n

Since its Rent-to-Own launch, Serum also happens to be the top seller on Splice\u2019s Rent-to-Own marketplace.<\/a> Producers love its powerful wavetable tools, myriad modulation options, and functionality-packed UI. Some critics, however, have opined that Serum uses a disproportionate amount of processing power.<\/p>\n

From KVR:<\/a><\/p>\n

\n

First, the synth uses a LOT of processing power. I hit a note on a super saw and saw my i7 dual core processor spike at 20%-30%. That’s a lot of number crunching for one instrument! This can be mitigated somewhat by using effects to simulate “unison” voices and (MAYBE) using a lower draft quality global setting. It’s just a function of math, if you want rich, fat, CLEAN sound, it’s just something we have to live with. If your computer isn’t beefy, you may have to drop your MIDI tracks to audio so you don’t kill your CPU.<\/p>\n<\/blockquote>\n

From MusicRadar:<\/a><\/p>\n

\n

Serum needs to be immediately put at the very top of any synthesist\u2019s shopping list. It’s insanely powerful and sounds phenomenal.
PROS<\/strong>: Morphing oscillators. Flexible unison modes\/ Built-in wavetable editor. Magnificent sound. Outstanding effects. Incredible modulation options.
CONS<\/strong>: Can hit your CPU hard.<\/p>\n<\/blockquote>\n

From Emusician:<\/a><\/p>\n

\n

STRENGTHS:<\/strong> Powerful wavetable synthesis. Extensive modulation and tone-shaping features.
LIMITATIONS:<\/strong>\u00a0Can be CPU-intensive. No standalone version.<\/p>\n<\/blockquote>\n

Despite near-universal praise for Serum\u2019s sound, many reviews mention CPU efficiency issues.<\/a> In this post, I\u2019ll examine Serum\u2019s CPU usage to determine whether these are valid complaints. I\u2019ll find out why CPU issues might occur, take recommendations from Xfer devs, and test out those recommendations in comparison to fellow wavetable workhorse Massive.<\/p>\n

Why is this happening to me?<\/strong><\/h2>\n

Steve Duda of Xfer Records remains active in many online Serum communities including the Serum subreddit<\/a> (where he’s the sole moderator) and Xfer support forums, where he has repeatedly encountered users who ask how to reduce Serum\u2019s share of CPU usage. According to Mr. Duda<\/a>, efficiency issues are typically attributable (at least in part) to user error:<\/p>\n

\n

Most CPU complaints I have found first and foremost come from heavy voice count compounded by not watching poly limits sensibly (lower-right fraction in Serum). Some synths won’t let that number exceed 64, so it’s good to keep an eye on it yourself and be sensible with unison (16 can sound great, but isn’t always better sounding!)<\/p>\n<\/blockquote>\n

Sam Leggett, former Xfer dev, and current Splice audio scientist concurred:<\/p>\n

\n

Anything that is going to automate each voice separately increases the problem space by the number of voices, and if you have a lot of notes playing, e.g. in a chord stack, that will multiply said problem space by that many notes.<\/p>\n<\/blockquote>\n

In other words, users may complain about high CPU usage if they crank up the voice count. Any digital synth must perform a certain number of calculations per voice in order to output audio. By the same token, when users increase the voice count, they’re also increasing the amount of numbers that their synth has to crunch in order to produce the desired sound. Since these calculations are performed by the computer\u2019s CPU, increasing the voice count will increase CPU usage no matter what digital synth you use.<\/p>\n

This post from Duda throws a little bit of shade at NI\u2019s Massive, which caps the voice count at 64 and automatically redistributes voices to allow polyphony once the limit is reached. This prevents Massive from spiking the user\u2019s CPU, even if the user raises the voice count and unison setting to their maximums. While voice count is not a bottleneck in most musical contexts, there may be legitimate cases where this limit is restrictive.<\/p>\n

Imagine you wanted to play a dominant 13th C chord (C13) using a Serum patch with 2 oscillators on Unison settings of 8 each. That\u2019s 7 notes (C E G B\u266dD F A), times 2 oscillators, times 8 = 112 voices. In Massive, these settings would trigger the voice cap, altering the timbral characteristics of the final output. Serum, on the other hand, does not limit voice count, meaning our 112-voice chord would use more CPU – although not on a per-voice basis, and without limits as to the patch\u2019s desired timbre.<\/p>\n

Another common potential cause of CPU inefficiency that Duda identified is excessive oversampling:<\/a><\/p>\n

\n

2x is all that is needed for normal oscillators, you shouldn’t hear any audible difference running 4x so it is indeed overkill. The 4x (oversampling) will be most noticeable when using FM warp modes, as it runs the oscillators at a higher sample rate which reduces digital artifacts. It will make some difference when using other warp modes as well.<\/p>\n<\/blockquote>\n

Oversampling sounds like a cool parameter that will increase sound quality if you crank it up, but as usual Duda is correct. According to the Nyquist-Shannon sampling theorem, it should be possible to perfectly replicate a signal if sampled at or above the Nyquist rate (twice the highest frequency component in the signal). Therefore, an oversampling rate of 2x should be more than adequate for accurate representation of most signals.<\/p>\n

What can I do about it?<\/strong><\/h2>\n

For starters, it\u2019s worth making sure that your copy of Serum is updated to the latest version. Updates to the codebase over the years have improved CPU usage, which may actually explain some of the efficiency criticism in the reviews. It should go without saying that a cracked Serum will result in degraded performance since it\u2019s likely to be outdated and no updates can be applied. If you’re looking to own a legitimate copy of Serum, you can Rent-to-Own Serum for an easy $9.99 a month<\/a><\/strong>.<\/p>\n

But let\u2019s assume you\u2019re all up-to-date and put Sam and Steve to the test. Below, we\u2019ll try out some of the parameters they identified as potential CPU bottlenecks, determine their actual CPU impact, and assess their effect on Serum\u2019s final output.<\/p>\n

Will it work?<\/strong><\/h2>\n

To test this out, I\u2019ll be using my rMBP and the Splice studio Mac Pro.<\/p>\n

\"serum-cpu-test\"<\/p>\n

For this test, I\u2019m going to be be using Ableton Live 9 because there’s no standalone version of Serum. To measure CPU, I\u2019ll use Live\u2019s built-in CPU usage monitor, which monitors the peak usage across one processor core output from Live. I know what you\u2019re thinking: \u201cBut I have 18-core hyp3rthr3ading d00d??!!!1<\/em>\u201d As a matter of fact, Serum uses only two core threads. Let\u2019s hear again from Duda:<\/a><\/p>\n

\n

There’s a DSP thread and a GUI thread. This is the most optimal way to be for a typical project use, as the DAW will delegate instances (tracks) across cores. Running multiple DSP threads comes at a price and only allows for more out of a single instance, which tends to not be needed once people learn to limit polyphony reasonably.<\/p>\n<\/blockquote>\n

It’s possible to capture more in-depth data using techniques like CPU usage profiling in Xcode\u2019s Instruments, but since there’s no standalone version of Serum, there\u2019s not much of a point in profiling its CPU usage independent of a DAW anyway.<\/p>\n

Based on the recommendations I gleaned from Steve\u2019s forum posts and talking to Sam, I\u2019m going to test the following parameters\u2019 impact on CPU usage peak within Live:<\/p>\n

Voice count<\/strong><\/p>\n