KVR Audio

Kinh · Post by **Kinh** » Sat Oct 18, 2014 4:10 am

Greg Houston wrote:I have 64 instances of Serum in a project at the moment. A fella posted a track in the Xfer forums with 51 instances of Serum a few days ago. I figure I'll be able to get to 80 or 90 before I have to start freezing tracks. If I had 32GB of RAM, 128 instances would be no issue without freezing anything.

That defies logic! I cant understand that. Im hitting 80, 100% with only 1 preset on a 6 core processor/32G ram. You're joking right? No one does 64 tracks in a session.

Kain · Post by **Kain** » Sat Oct 18, 2014 4:34 am

What preset is it? There are some that gave issues on my machine to but the latest beta fixed it. There were some FX presets that when you go crazy on the automation can cause a issue. But my machine is not that powerful, i5 M450 at 2,4 Ghz.

I have a broken motherboard but otherwise I would be using my i7 975 with 8 threads, pretty sure I would be able to play more instances of Serum then my ears ever could handle. Ever since 2008 I never had to worry about CPU eating (unless some process freaks out and takes 100% cpu time) but my DAW died and now I'm working on my laptop. As long as I don't do anything crazy .... I don't even have to bounce to audio. Serum is already highly optimised, I can tell from what sound quality you get using what CPU on very complex sounds.

Keep in mind that none of Steve's customers will have the exact same configuration as so it will take a while before every tiny bug is fixed.

I'm not reading much about CPU usage problems with Serum on the internet. So what preset is it ... so we can test it out. It could also be your machine, OS or DAW.

Kinh · Post by **Kinh** » Sat Oct 18, 2014 4:55 am

Kain wrote:What preset is it? There are some that gave issues on my machine to but the latest beta fixed it. There were some FX presets that when you go crazy on the automation can cause a issue. But my machine is not that powerful, i5 M450 at 2,4 Ghz.

Mostly Synth patches...SY Analog Brass (70%) SY Augustines Bell Chapel (85%) cHello (60%)...just to name a few.
Pretty much every other synth is the same. Bass, leads and arps are between 30 to 50% average though some peak above. There are some that hit 100%. This is just Serum on its own with no other vsts or drum tracks.

masterhiggins · Post by **masterhiggins** » Sat Oct 18, 2014 5:24 am

Does the license become NFR if it's resold? Does anyone know what the transfer fee is? I'm thinking about just waiting until buyer's remorse sets in for people in November/December and they want to clear up cash for the next synth.

-Sam

JC_ · Post by **JC_** » Sat Oct 18, 2014 5:49 am

Does anyone know if there's a way to lock settings/knobs? I was playing around with the distortion mix knob all the way up and almost blew my head off when I bypassed it.

EvilDragon · Post by **EvilDragon** » Sat Oct 18, 2014 6:16 am

Serum indeed IS a CPU munching hog, over here as well... I can't use more than two patches with long release at the same time in a project... sometimes not even one, it would start crackling. And this is in Reaper, which is supposed to be extremely efficient with plugins and CPU assignment...

i5 2380P, 3.2 GHz here, 4 cores.

Greg Houston · Post by **Greg Houston** » Sat Oct 18, 2014 6:24 am

I think we've established multiple times in this thread that long releases in Serum are CPU killers in current systems. For single note pads I tend to limit my release time to no more than 2.36 seconds. If the pad is for chords the release time gets shortened accordingly.

EvilDragon · Post by **EvilDragon** » Sat Oct 18, 2014 6:26 am

Hence, I think Steve needs to work some more on optimizing Serum further... For example, the patch PD Holy Place [BR] takes up an entire core over here if I play a 5-voice chord (triad in right hand and octave in left hand), and grinds the CPU if I switch to a different chord... just not really usable. And no, playing one finger pads is not a solution. LOL. Anyways, anxious to see any and all possible CPU optimizations possible. Assign every fourth voice to a different core, perhaps? I mean, each voice is pretty much a duplicate of the previous one, couldn't you vectorize their processing this way?

Codex seems even worse over here, it takes up 5% of CPU without even playing a note! Ridiculous.

paterpeter · Post by **paterpeter** » Sat Oct 18, 2014 7:12 am

EvilDragon wrote:Serum indeed IS a CPU munching hog, over here as well... I can't use more than two patches with long release at the same time in a project... sometimes not even one, it would start crackling. And this is in Reaper, which is supposed to be extremely efficient with plugins and CPU assignment...

i5 2380P, 3.2 GHz here, 4 cores.

I'm with you. i7 2600, latest Reaper. Pads with longer releases are indeed practically impossible.

Ingonator · Post by **Ingonator** » Sat Oct 18, 2014 7:12 am

EvilDragon wrote: Codex seems even worse over here, it takes up 5% of CPU without even playing a note! Ridiculous.

In Codex the CPU use when idle is indeed strange (i admiit i have not really noticed this so far...) but the CPU use when playing is lower than Serum.
I am able to layer two pads (both with Unison on) and a Synth Brass sound and play 5 notes on a quite old Core 2 Duo CPU. On a Core 2 Quad CPU (quite old too...) i could use even more. That's in Live 9.1.5 64-bit.

With the Serum demo i was never really able to layer 2 pads without the CPU maxing out and that is with 3-4 notes instead of 5. Not sure how it is with the current beta versions.

Sampleconstruct · Post by **Sampleconstruct** » Sat Oct 18, 2014 7:18 am

In all CPU discussions and comparisons, sample buffer size in the DAW must be mentioned, otherwise comparisons are totally useless. Expecting Serum to play complex unison patches with 2 oscs and a sub with 4 x oversampling at a 64 sample buffer, is of course a lost cause. In comparison to other higher CPU-synths I use like Spectral and Diversion, I find Serum to be not more demanding than these two.

EvilDragon · Post by **EvilDragon** » Sat Oct 18, 2014 7:21 am

256 samples buffer here.

Kain · Post by **Kain** » Sat Oct 18, 2014 7:56 am

Sampleconstruct wrote:In all CPU discussions and comparisons, sample buffer size in the DAW must be mentioned, otherwise comparisons are totally useless. Expecting Serum to play complex unison patches with 2 oscs and a sub with 4 x oversampling at a 64 sample buffer, is of course a lost cause. In comparison to other higher CPU-synths I use like Spectral and Diversion, I find Serum to be not more demanding than these two.

People will always blame what ever is the most lazy solution. In this case it's "Oh look Steve totally did not optimise the code enough" without them having any idea what they are talking about.

- sample buffer
- How does the DAW speak with the VST plugin? In FL Studio sometimes the fixed buffer options fixed cracks in the sound and sometimes it cause huge issues with other plugins
- Is multithreading on for the plugins.
- Any other host activity going on.

etc etc etc etc.

If the "pro's" here tell me they see a tiny bit better CPU usage then Massive with better quality and when I see the exact same thing nobody can convince me that Serum is badly optimised ... because it's not and it's easy to use that as an excuse without actually figuring out what exactly is going on on your computer. Computers are incredibly complex and no two computers in the world have the same configuration.

Are there some issues with Serum? Ofcourse, it's brand new. But nothing that is a deal breaking and is not going to be fixed in the future. That takes time, especially when you only have one programmer.

Kain · Post by **Kain** » Sat Oct 18, 2014 8:19 am

EvilDragon wrote:Hence, I think Steve needs to work some more on optimizing Serum further... For example, the patch PD Holy Place [BR] takes up an entire core over here if I play a 5-voice chord (triad in right hand and octave in left hand), and grinds the CPU if I switch to a different chord... just not really usable. And no, playing one finger pads is not a solution. LOL. Anyways, anxious to see any and all possible CPU optimizations possible. Assign every fourth voice to a different core, perhaps? I mean, each voice is pretty much a duplicate of the previous one, couldn't you vectorize their processing this way?

Codex seems even worse over here, it takes up 5% of CPU without even playing a note! Ridiculous.

Okay I tested that PD Holy Place [BR] patch.

I have I5 M450 laptop processor. dual core with hyperthreading.
Asio4all on 1152 samples on 48 Khz
32bit plugin running in bridge (sperate thread in process hacker under ilbridge.exe)

One note --> 25 cpu use in FL Studio, 8% in Process Hacker
Two notes --> 35 and 12
Fife notes --> jumps to 89 and then around 70, 20% in Process Hacker
Seven notes --> now it starts breaking up in the beginning of the sound and then plays at 99 in Fl studio and still 20% in process hackers (that's about the limit per thread with the overhead)

All pretty normal CPU use if you consider with 7 notes and 5 unison on OSC A and 3 unison on OSC B you are generating 7 x 5 x 3 = 105 different thingies the CPU is crunching on in real time.

So now what? No 7 fingered chords for Kain? No, I either limit the unison and the poly a bit or I can get a more powerful processor if I think I need that (I don't) with 7 notes I don't hear the difference between 3 unison or 5 unison voices anyway.

My point is .... when you do the calculations this synth is not totally worse than different synths.
Who told you that software synth need to be able to have routines that can do an infinite amount of calculations in a finite amount of time?

Serum is brand new and is already doing a more than good enough job CPU wise, will only get better in the future. It's no reason not to buy it unless you have a system that can't run anything anyway.

edit: I completely forgot about oversampling. Just to make another point, there are so many variables. Some of those won't change the sound significant and can reduce CPU usage like oversampling. Depending on what type of sound it is.

Official Serum thread!