CPU saving automation technique for VST

Discuss VST stuff here!
Post Reply
chaosroyale
Posts: 728
Joined: 05 Sep 2017

06 Feb 2018

EDIT: resurrecting this thread because someone asked about it on the General Board. The tl:dr below is really all you need.

TL;DR

1.You can automate the devices OFF to save DSP

2. VST instruments will need to be in a combinator, and you switch the combinator off. VST FX have a switch on each device.

3. This CAN change latency compensation reporting. In this case, some people have reported problems like clicks. So you may want to check a test render. In cases where there is no latency difference, there will be no problem.

4. I came up with this workaround in Reason 9.5. The performance boost in 10.3~ has made this workaround less important. Your mileage may vary.


...ok, below is the original post, but everything useful is in the info above.

This really works, I use this technique all the time, but please read the caveats because I expect some people will misinterpret what I am saying.

I saw a thread on using VST hosts to help with VST performance and it seemed to be a slightly more cumbersome version of a workaround that I use. My technique doesn't need any 3rd party downloads (paid or otherwise) and anyone can do it within Reason itself, as long as you can use automation lanes.

Caveat1: VSTs will still be more efficient on other DAWS, I hope this will be addressed by Props. My technique is simply making the best of a bad situation.

Caveat2: This technique will not magically increase the maximum number of concurrent active VSTs you can run, and neither will any other technique as far as I know. However; most music does not have every device active all the time, and if that is the case, this trick WILL save your DSP.

Caveat3: I expect some of you already do this but a lot of people just leave their VSTs sitting in the rack eating up DSP, so this is for you guys!

HOW TO: this is so simple it actually annoys me a little that it is not the default setting for VSTs in Reason.

INSTRUMENTS:
1. Put any VST instruments that you have "alone" in the rack into a combinator.
2. Set up an automation lane for "Enabled"
3. Whenever the VST combinator is not making sound, automate the combinator OFF. *Pay attention to reverb tails, etc.

FX:
1. Set up an automation lane for "enabled" directly on the FX unit
2. Whenever the FX unit is not making sound, automate it OFF. *Pay attention to reverb tails, etc.

There do not seem to be any pops or clicks with the effects I've used but if it does, you can always switch on slightly before the sound plays and automate a volume fader on the desk to de-click.

By doing this a particularly troublesome track I had made which used a lot of dynamic EQs and several vintage type compressors and reverbs went from 98% CPU and occasionally clicking and stuttering, to 88% CPU and I could use the spectrum display and a loudness visualizer VST without it dropping out. This may not seem like a big deal but it was the difference between being able to carry on working or not.

The downsides are small but obvious: the automation is a pain in the ass but you can simply set default to OFF and copy and paste ON messages that last as long as you need the VST to make sound. Furthermore if you need an LFO that runs constantly for the whole track, this technique will interrupt it. Then again , that's a rare case and you can always use a Reason LFO that won't go to sleep.

I haven't experienced any other disadvantages with this technique, so I hope Props can make "no sound = no use" the default setting in Reason, *as well as* working to improve the VST implementation overall.
Last edited by chaosroyale on 19 Oct 2020, edited 2 times in total.

danc
Posts: 1017
Joined: 14 Oct 2016

06 Feb 2018

Excellent run through. I can vouch that your method does work. I was wondering if there was a way to "switch off" the VST racks. Thank you for such a great explanation!

Regarding your comment:
chaosroyale wrote:
06 Feb 2018
Caveat2: This technique will not magically increase the maximum number of concurrent active VSTs you can run, and neither will any other technique as far as I know. However; most music does not have every device active all the time, and if that is the case, this trick WILL save your DSP.
I was the one that started the other forum topic about using AGENT CM VST host to minimise CPU. I've been using my technique for a few weeks now and it really does allow me to increase the maximum number of concurrent VSTs. So, I do see it as being magical. Also - many people have raised points that they've found AGENT CM as being unstable - again, for me it has been consistently stable - but I do realise that different computer setups might cause instability.

Just to appease this one chap on my thread... I do not have any affiliation with Future Publishing or Nyrv Systems. So - I am not profiting from talking about a FREE VST on Reasontalk... I simply am trying to solve the headache of Reason gobbling my CPU.
Check my Soundcloud:

User avatar
SoulState
Posts: 308
Joined: 15 Jan 2015

06 Feb 2018

[edit]
Last edited by SoulState on 06 Feb 2018, edited 2 times in total.
:reason:

chaosroyale
Posts: 728
Joined: 05 Sep 2017

06 Feb 2018

Hi Danc, and sorry for calling your method "cumbersome"!

If that host really does increase maximum concurrent VSTs (I will confess to being a little skeptical - not of you but of how it would actually be achieving this) then it could be useful for really huge projects, at least until Props refine their code a little. I have a feeling that even slightly better code in Reason plus simply turning off the unused VSTs would probably be the optimal solution going forward.

If someone has time to do a thorough test of both our methods with all the variables accounted for, that would be great, but for now at least I can say that this simple automation method really helps ease CPU use for most music and obviously it doesn't have any stability issues. If people are wary of downloading 3rd party software, this way they don't have to.

danc
Posts: 1017
Joined: 14 Oct 2016

06 Feb 2018

chaosroyale wrote:
06 Feb 2018
Hi Danc, and sorry for calling your method "cumbersome"!
No offence taken. Loading up a VST and then click a button to load another VST isn't that cumbersome. Takes me about 10 seconds extra!
chaosroyale wrote:
06 Feb 2018
If that host really does increase maximum concurrent VSTs (I will confess to being a little skeptical - not of you but of how it would actually be achieving this) then it could be useful for really huge projects,
What I have noticed is that Reason's DSP meter max's out way before my PCs CPU gets anywhere near max'd out. So - running VSTs inside a host simply bypasses Reason's arbitrarily low threshold and uses all of your CPU, not just the CPU that Reason is prepared to offer you.

chaosroyale wrote:
06 Feb 2018
at least until Props refine their code a little. I have a feeling that even slightly better code in Reason plus simply turning off the unused VSTs would probably be the optimal solution going forward.
Totally agree that Props need to fix this problem. As other DAWs are definitely getting a better deal than us regarding concurrent usage. My guess is that Props have erred on caution, for stability sake whilst they rolled out VST compatibility, and will address in a later version.

chaosroyale wrote:
06 Feb 2018
If someone has time to do a thorough test of both our methods with all the variables accounted for, that would be great, but for now at least I can say that this simple automation method really helps ease CPU use for most music and obviously it doesn't have any stability issues. If people are wary of downloading 3rd party software, this way they don't have to.
Agree - test away. Maybe both methods are valid and can be used together.
Check my Soundcloud:

User avatar
miscend
Posts: 1955
Joined: 09 Feb 2015

07 Feb 2018

This method is more laborious than printing tracks to audio.

Is the VST on and off button not automatable?

chaosroyale
Posts: 728
Joined: 05 Sep 2017

08 Feb 2018

EDIT: I must have been drunk when I wrote this: miscend was probaby asking about VST effects, which CAN be automated on/off without putting them in a combinator. My reply was about VSTis, which cannot.
miscend wrote:
07 Feb 2018
This method is more laborious than printing tracks to audio.
That really depends on how long each audio clip takes to render. You would still have to turn off all the VSTs by hand after rendering to audio, in which case you could just as well create an automation lane for the switch and then it is just a matter of copypasting sequencer tracks with switch messages. So I guess it would actually take the same or longer to print to audio.

However, the big difference is that the on/off automaton method keeps everything live, whereas bouncing to audio is useless if you need to keep tweaking effects, or re-writing parts.

A proper freeze option would solve this.


miscend wrote:
07 Feb 2018
Is the VST on and off button not automatable?
If it were, I would not have said you need to put standalone VSTis into a combinator. However if they make it automatable in future, the process would be exactly the same, automate the on/off, simply without using the combinator.
Last edited by chaosroyale on 19 Oct 2020, edited 1 time in total.

groggy1
Posts: 466
Joined: 10 Jun 2015

11 Feb 2018

What happens if the VST introduces latency? Doesn't switching it on/off change the delay-compensation milliseconds amount? (and I thought that introduced pops/clicks)

chaosroyale
Posts: 728
Joined: 05 Sep 2017

11 Feb 2018

groggy1 wrote:
11 Feb 2018
What happens if the VST introduces latency? Doesn't switching it on/off change the delay-compensation milliseconds amount? (and I thought that introduced pops/clicks)
EDIT> I totally misread this comment and my reply was kind of nonsense. Basic answer - test it and see how it affects your render.

I expect an RE developer could explain if there is any problem with this, but remember I only recommend turning off combinators when they are not producing any sound, so I don't think there is an issue.

I did some tests in the other "VST/CPU" thread mentioned above, and it seems as though the "Agent" host does not improve VST performance at the limit, it simply turns them off when they are not being used, the same as the automation trick in this thread, but with an additional memory overhead for loading the VST host.

So it's up to you: loading VSTs into combinators and using automation versus loading VSTs into a VST host and using more memory.
Last edited by chaosroyale on 27 Oct 2020, edited 1 time in total.

chaosroyale
Posts: 728
Joined: 05 Sep 2017

19 Oct 2020

EDIT: another lazy reply by me here. groggy is right: in some device chains there will be a difference in latency if you switch off one of the VSTs (usually effects but some oversampled instruments have latency too). In this case, check if your latency compensation as reported to the DAW goes down when turning the device "off". If nothing changes, you are good to go. (This could be taken care of automatically by the DAW in theory, but currently it is not, so you have to pay attention.)
chaosroyale wrote:
11 Feb 2018
groggy1 wrote:
11 Feb 2018
What happens if the VST introduces latency? Doesn't switching it on/off change the delay-compensation milliseconds amount? (and I thought that introduced pops/clicks)
Edit: I accidentally hit "report" instead of "quote" MODS: please ignore my report!

clicks issue or lack thereof - see my explanation above.

Latency: all the combinators in my projects using VSTs report 0 delay compensation with or without automation, and that's even using fancy dynamic EQs etc. I have not noticed any audible issues when switching things on or off. The overall master delay compensation display does not go up or down even if I outright delete the VSTs so I think the automation is not a problem.

I expect an RE developer could explain if there is any problem with this, but remember I only recommend turning off combinators when they are not producing any sound, so I don't think there is an issue.

Final edit: I did some tests in the other "VST/CPU" thread mentioned above, and it seems as though the "Agent" host does not improve VST performance at the limit, it simply turns them off when they are not being used, the same as the automation trick in this thread, but with an additional memory overhead for loading the VST host.

So it's up to you: loading VSTs into combinators and using automation versus loading VSTs into a VST host and using more memory.

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 12 guests