Recommendation in order to address the high CPU usage issue for low-end devices

Bugs
#1

Hi @Tytel. Your vital synth rocks! Will subscribe soon.

Regarding the synth’s cpu usage, it uses a huge chunk of my laptop’s intel i3 cpu, which causes audio droupouts with some of the presets. Because of this, I tend to set the oversampling rate to Draft (1x) in order to ease my cpu usage.

However, I found out that the oversampling rate setting is dependent on the presets, i.e. every presets have their own oversampling rates. So when you set the oversampling rate to draft (1x), and you change to another preset with a default oversampling rate set to High, the synth will again cause audio droupouts.

Is it possible to make the oversampling rate setting independent of the presets, so that whichever preset I choose, the oversampling rate would remain at Draft? A check box to “override” preset sampling rate would be very useful when I am browsing the presets in the library, without the need to set the oversampling rate each time I preview one, just to prevent audio dropouts. Thanks!

3 Likes
#2

Something like ‘lock oversampling rate’ checkbox, so the oversampling rate will stay at what you have chosen while switching on different presets.

And I think its a good idea to put it in the options where you click the vital logo.

2 Likes
#3

Agreed. In that way, there would be no need to mess with the settings of the presets already existing in the library.

1 Like
#4

Yes please from me too, it’s inevitable that some presets will cause problems because they are made on high-end machines and may not be suitable for the run-of-the-mill pc. Removing oversampling seems to help enormously with mostly no noticeable loss of quality.

2 Likes
#5

I agree completely. Please reply and like this post to increase the likelihood that this feature will be implemented:

  1. oversampling locked to current setting when browsing presets
  2. allow to set different oversampling rates for realtime and offline (export / rendering), so that you can run in realtime at lower OS rate, while making sure that it will sound superb when bouncing
#6

You’ve already made your request. There’s no sense in bumping every old thread.