CPU Optimization for vital

Feature Requests
#37

Here’s the CPU Benchmark for your system and my internet computer which is where I ran the test:

CPU%20%20040721-1

The higher the score the better so you can see why the numbers we each got were so different. There would be an even larger disparity if I tested on my studio system. Like I said Vital is going to have the same CPU demand on every system with the same patch it’s the system specs that will determine whether it can be run with patches that take full advantage of Vital’s power.

I sympathize with those who can’t afford to keep up with technology. I wish I could buy everyone a new computer.

#38

Ya…Renoise has a lovely little feature called render vst to samples. I can then take that and manipulate even further. I was trying to use a Vital patch that was hitting me around 70 percent CPU with everything else turned off. Rendered to sample instrument and was running a 6 percent . Love that feature.

1 Like
#39

Really was excited about Vital, but after a few weeks playing with it i find it a bit unusable CPU wise. For what it does, Hive is still my go to wavetable synth. Blue 2, and my old trusty Sylenth still gets the job done as far as analog sounding soft synths and don’t bog down my old ass computer. Maybe things will change with Vital but i have to agree with you at the moment.

1 Like
#40

I’ve noticed that there’s a tendency for some patch programmers to go crazy on EVERYTHING. I think that’s part of the problem. Yes, with a VI this powerful you can make a nice 2 sawtooth pad and then max out on filter modulation AND effects, then cross-wire modulation macros just because you can, but if you test the patch, disabling some connections, you might find that a lot of the extra routing is a waste. It doesn’t sound thinner if you detect redundant routing that doesn’t add anything audible, and put some effort into keeping the CPU load reasonable.

#41

I think there’s a misconception going on here. Vital, using OpenGL, runs (at least) two threads parallel, OpenGL and audio. But, this advantage only pays off, if you actually use a dedicated graphics card. If you use a CPU with “in-built graphics”, the CPU is still marking processing time for the graphics in the task manager. The same is of course true for all apps that make use of OpenGL. In other words, even the cheapest dedicated graphics card will improve your experience with Vital, even if that dedicated card is only as potent as the CPU’s in-built graphic chip (it comes with its own memory, which avoids sharing RAM, and is its own process, to name just two advantages).

#42

Benchmarking Vital
OS: Win10Pro (latest)
Hardware: i9900k @ 4.7Ghz, 32GB Ram, RTX 3080, Scarlet 6i6
DAW: BitWig

–

- Base line test: BitWig no track open, no other programs running bar notepad++
Global CPU Usage: 2% to 4%
Global RAM: 16%
GPU Load: 4%
BitWig CPU Usage: 0 to 0.4%
BitWig RAM Usage: 540MB

–

Measurements 1
= Open BwitWig
= Open song (Contains 1 layer, vital and 1 piano roll block and looping timleine)
= Vital is NOT in view
= Play has not been click and song is not playing

Global CPU Usage: 1% to 3%
Global RAM: 17%
GPU Load: 4% to 6%
BitWig CPU Usage: 0.5% to 1.5%
BitWig RAM Usage: 815mb
BitWig DSP Load: 1% approx

–

Measurements 2
= Open BwitWig
= Open song (Contains 1 layer, vital and 1 piano roll block and looping timleine)
= Vital is in view
= Play has not been click and song is not playing

Global CPU Usage: 11% to 14%
Global RAM: 18%
GPU Load: 30% to 34%
BitWig CPU Usage: 10% to 11%
BitWig RAM Usage: 905mb
BitWig DSP Load: 1% approx

–

Measurements 3
= Open BwitWig
= Open song (Contains 1 layer, vital and 1 piano roll block and looping timleine)
= Vital is in view
= Song is playing

Global CPU Usage: 8% to 11%
Global RAM: 18%
GPU Load: 36% to 48%
BitWig CPU Usage: 7% to 9%
BitWig RAM Usage: 913mb
BitWig DSP Load: 30% approx

–

Measurements 4
= Open BwitWig
= Open song (Contains 1 layer, vital and 1 piano roll block and looping timeline)
= Vital is in view
= Song stopped clicked
NOTE: Can still hear some Vital sounds extremely quietly

Global CPU Usage: 8% to 11%
Global RAM: 18%
GPU Load: 36% to 48%
BitWig CPU Usage: 2% to 4%
BitWig RAM Usage: 913mb
BitWig DSP Load: 30% approx

–

Measurements 5
= Open BwitWig
= Open song (Contains 1 layer, vital and 1 piano roll block and looping timeline)
= Vital is in view
= Song stopped for x amount of time, bitwig DSP graph confirms no load from Vital anymore
= Can’t hear any extremely quiet sound from Vital anymore

Global CPU Usage: 3% to 4%
Global RAM: 18%
GPU Load: 32% to 38%
BitWig CPU Usage: 2% to 4%
BitWig RAM Usage: 914mb
BitWig DSP Load: 1% approx

–

Measurements 6
= Open BwitWig
= Open song (Contains 1 layer, vital and 1 piano roll block and looping timeline)
= Vital is in view
= Changed preset to Analog Stab
= Dropped piano roll 1 octave
= Duplicated layer, upped notes 1 oct
= Duplicated layer, upped notes 2 oct
= Duplicated layer, upped notes 3 oct
= Duplicated layer, upped notes 4 oct
= Total 6 vital instruments

NOTE: Load actually didn’t increase much on duplication.

Global CPU Usage: 15% to 16%
Global RAM: 21%
GPU Load: 38% to 46%
BitWig CPU Usage: 14% to 16%
BitWig RAM Usage: 2GB
BitWig DSP Load: 20% to 30% saw tooth rise and fall based on notes being played

–

Measurements 7
= Same as above just vital is no longer in view

Global CPU Usage: 9% to 11%
Global RAM: 21%
GPU Load: 15% to 20%
BitWig CPU Usage: 8% to 110%
BitWig RAM Usage: unchanged
BitWig DSP Load: unchanged

** Values have been confirmed via multiple tests doing the same tasks in sequence… **

–

NOTE: Mac Hardware
Apple hasn’t been known for using latest generation hardware in their machines for many years +12. While your laptops and imac’s may be good enough to render video 3D etc, audio is time critical in milliseconds. Even that mac that costs over £20,000 doesn’t even use the latest hardware, only thing good about it is that it uses error correcting memory (ECC Ram).

–

CONCLUSION: Vital load

  • Could it be optimised better? Yes (But I expect this to come in time, v1.0.7 is early days)
  • Does it consume a lot of CPU compared to others? It’s not the lightest, but it’s also not the worst, I’ve seen Arturia Pigments swallow 3 times the ram and eat 60% of my CPU and 75% of BitWigs DSP load with just 1 instrument.
2 Likes
#43

Try running Vital and your DAW through the Built-in graphics (not AMD, for instance). This gave me instant -10% Less CPU load. Tbh, Pigments 3 is much CPU hungrier than Vital.

#44

Vital will always be OK with no optimization on these top-end machines, the need for optimization, for me, is more to improve matters for the average laptop.

#45

So true!

#46

Not really on my System with AMD radeon. Upon loading Studio One with Vital, the CPU in the task bar gave instantly 23% Load. When I made S1 and Vital to use Intel graphics instead, the CPU went down to 12-15%.

#47

There isn’t a synth that is fully optimized. A majority of the big names like Serum, Sylenth1, and Vital come close. In my experience as a plugin developer, there are two major factors that impact a synth’s optimization - Architecture and Algorithm

Architecture is the main idea of where a synth put the audio through what thing and how it does it. You could process each oscillator voice in scalar form (I.E normal integers and floating point numbers) or vector form (Special CPU instructions to make things faster in parallels). It has been common to process voices in vectors because you can synthesize stuff and do filters in not a lot of CPU instructions. Vital has an entire section of its source code to vector intrinsics. I can guarantee that Vital would kill your CPU if vector intrinsics weren’t used.

Algorithm is the main idea of how to do something in an architecture. Vital’s unison algorithm is very CPU friendly compared to Serum’s. The effects are very sturdy and don’t add as much CPU as the ones in Serum.

One thing that I’ve screwed up on in the past is filters- they are the main element of subtractive synthesis. They are also processed voice by voice, meaning every note will have its own filter. This is ok with a few notes, but you need to make sure that your filters are optimized for high polyphony. Vital’s filters are pretty good, and I see no needed CPU optimizations. There are other synths with faster filters, so they may be part of the high CPU thing.

2 Likes
#48

I wonder if the gpu could be used for this instead of the cpu… Pushing vectors through shaders, do the math and back out again… But would probably have to dial back the visual effects a bit… Also not sure on latency of putting data on the gpu and getting it back again.

#49

The only thing that surprised me really was that it consumed 30 to 40% of an RTX 3080, when in view, so maybe some optimisation on the graphical routines down the road. Serum doesn’t touch my GPU as far as I can tell.

#50

I’ve seen many VST and standalone synths/fxs that uses the GPU to process DSP, now a days latency isn’t that much you can nearly achieve around 3ms with GPU audio processing, the problem is, parallelizing a audio stuff is basically the DarkSouls level of coding to programmers, simply put a single core in GPU is 50 times weaker than your CPU single core performance, and you want to utilize those 10,496 cores (RTX 3090 i.e.)

1 Like
#51

Seems like the GUI CPU loading issue I was having is a purely system related thing (4 years old machine) . My machine behaves exactly the same way with the Pigments 3. So, I guess, nothing can be done and it’s NOT a Vital bug or something.

#52

Just tested on an M1 Mac Mini using REAPER v6.29 for ARM64 (M1).

While REAPER is written for M1 Macs now, Vital isn’t, so it’s running in a Rosetta 2 x86 wrapper. I tried finding a somewhat complex preset to use, and settled on “Cinema Bells”. I set up a 3-note major chord to loop and here is the usage, via REAPER’s performance meter while it was playing and while Vital’s window was open. No effects and no other tracks in the project:

29%20AM

Then, for laughs, I duplicated the same track 6 times, and this is what I got while it was playing:
https://i.imgur.com/sokbJPB.png

1 Like
#53

One way to decrease CPU consumption would be to have separate oversampling settings for realtime and offline (rendering / export), so that you could run CPU with no oversampling while playing and recording and still make sure that it will be bounced at a higher oversampling rare during export. If you would like to see this feature implemented, please like or reply to this post

1 Like
#54

Hello, I want to Iike vital, great features, great interface… unusable lag.

I have a fairly new MacBook -
I launch ableton with 6 vital tracks - 7% cpu usage.
I open the vital window to edit or scroll the library and the cpu usage skyrockets at 30 40%
Closing the window does nothing to restore the cpu if not dropping a 5 %
Interface of the whole os becomes sluggish - using sidecar becomes a nightmare

(p.s. you can make ableton fully pausa le on iPad if you create a custom onscreen keyboard for the shortcuts in OS X keyboard viewer, it takes minutes and it’s amazing).

Vital interface is the cpu and gpu killer.
I want to use vital… and subscribe… but I can barely use it…

Any rapid fix?

#55

Matt has been working on a major rewrite of Vital that in part will address GUI issues but there is no word on a release date yet.

So other than trying to adjust settings on your system there is no “rapid fix” at this time.

Perhaps other Mac users can chime in with some advice to optimize your system to run Vital more efficiently.

2 Likes
#56

thanks teksonik.
I see that autocorrect changed some text in my previous message making part of its meaning lost, what I wanted to say in the brackets is that ableton can be used in touch mode (pen mode) on ipad without sacrificing any shortcut using a custom on screen keyboard layout. It is an off topic, but it might be useful to someone in the forum.

I hope the gui rendering cost in resources will be fixed soon, if anyone has any advice, please feel free to share… I tried boosting resources from terminal with the nice command, but I get permission issues.