CPU Optimization for vital

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

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.

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.

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

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.

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

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

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?

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

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.

Interesting. Since Matt is working on updating the GUI engine, then this may get addressed with the next release.

Can I add my 2 cents?
I have a 11th generation core i5, and even when my cpu usage (taskbar or Reaper performance meter) is under 10%, I have severe sound freezes or dropouts (I’m not english, I don’t know the exact word, but it’s like I’d want to have zero latency on my sound card, and it obiously can’t) on some presets (usually big pads).
Even with oversampling set to 1, it happens sometimes.
My laptop is under LinuxMint with Reaper.
Are you sure Vital uses the 8 cpu cores?

I think Vital is quite mild on the CPU and I’m running an old 2012 Mac Pro. Waves Element 2… now there’s a CPU hog! But of course YMMV

I suggest buying the pro version and download the 1.5 beta pre-release: everything is solved. Thanks!

1 Like

i agree. The 1.5x beta runs great

Forget CPU optimisation, it’s looking like GPU AUDIO will be the next innovation.

1 ms latency.

Quick update. I was finally able to get my self a new laptop. A powerful one indeed and vital runs like a Lambo. Super fast and i can now even open some crazy cpu wrenching presets.

Thanks everyone for your feedbacks and suggestions on this thread. I really appreciate it

1 Like

First - thank you Matt for this really nice synth that helps newcomers a lot to start into the business of sound creation!

I cannot really say that Vital takes a whole lot CPU Power but nonetheless it is the only VST that gives me crackeling Sound if I try to play it live with some presets:

Ryzen 4500U, Fast SSD, 32GB RAM, Vital Analog Preset (feat. 7 unison, Reverb, Deley, Chorus…)
DPC Latency around 200-400 ms
Presonus Studio 1810, 256 Samples Buffer Size (in/out Latency about 13 ms)
Windows 11 Pro, Reaper DAW

As soon as I go over 16 Voices I get dropouts on my audio interface - no other VST gave me that (mostly I Use UFI Workstation, Tyrell, sforzando). By reducing the Unison to 3 I can go up to 24 Voices but I would like to have 32… Seems not possible even running Vital on Oversampling-Draft-Mode (1x).

CPU does look good though never reaching anywhere near 50 Percent.

So I am not quite sure what to optimize but as the problems scale with the voices the Synth is playing it must be some (CPU) optimization that would help - so I vouch for that

I don’t think there’s that much to actually optimize if there’s no apparent issue, like when comparing similar patches in Vital, Serum, Pigment, Phase Plant etc. would indicate that Vital has significantly worse performance.

But surely if something would get optimized I’d be happy. I’m just not betting on the effectiveness of discussing Vital’s future here, or anywhere, given the nature of its development.

I have a fairly recent laptop with some ram and Vital still is a bit too hungry for it, I love it too much to leave it though.
What would help a little would be able to set the oversampling quality globally, not just on a per patch basis