How to run loads more VSTs without buying a new CPU

Discuss VST stuff here!
User avatar
joeyluck
Moderator
Posts: 11029
Joined: 15 Jan 2015

08 Feb 2018

I've had good results using this with some VST instruments. But in some cases, no change or even worse results with some VST effects. I guess it depends.

avasopht
Competition Winner
Posts: 3931
Joined: 16 Jan 2015

08 Feb 2018

I wonder what happens if you run the UAD plugins through this, ...

danc
Posts: 1017
Joined: 14 Oct 2016

08 Feb 2018

avasopht wrote:
08 Feb 2018
I wonder what happens if you run the UAD plugins through this, ...
I don't have UAD to test - however it should in theory help. Because each time you add a UAD VST it does take up a small % of your computers CPU and if Reason detects this, it might (in theory) register it on its own DSP meter, as it needs to push the audio IN and OUT of UAD. But it will have to be tested to find out.

It's a little ironic that you have to eat away at your computer's CPU to host UAD VST, as you kind of think you've bought a separate piece of hardware to take the CPU load.

Anyway - seriously considering dipping my toe into UAD with their latest Arrow, which is now at a price (around £400) where I'm prepared to have a go - plus it's Thunderbolt 3 which should in theory lesson the load on my CPU. Plus you get 14 quality UAD VSTs thrown in. Plus it's an audio interface. So pretty darn good value.
Check my Soundcloud:

User avatar
vectro
Posts: 55
Joined: 17 Jan 2015
Location: Sweden
Contact:

09 Feb 2018

danc wrote:
04 Feb 2018
I did spend 2 days trying to use Vienna Emsemble Pro, which allows you to run VSTs on multiple computers, all connected via Ethernet cable. It's a great idea. But there are many practical problems... but that's for another topic.
I'd actually like to see that topic. Practical problems?
I'm using CoreMIDI/rtpMIDI and Dante to put instruments on multiple computers and platforms over Ethernet. Been looking at VEP as the next step.

User avatar
raymondh
Posts: 1776
Joined: 15 Jan 2015

09 Feb 2018

danc wrote:
06 Feb 2018
raymondh wrote:
05 Feb 2018
I bounce all the synths and effects to audio, then mute the channels and even bypass the insert FX afterwards, and the DSP bars are still up there. Delete all the synths and FX from the song and just leave the audio tracks and it's fine, but very impactful to the workflow to restore the instruments and FX for further arranging.
You are correct that MUTING VST racks doesn't reduce CPU... but you don't need to remove the whole rack to save CPU. All you need to do is click the green ON/OFF switch on the VST rack. You will instantly save CPU.

I so wish that green button could be automated, because if I could get the sequencer to switch the VST ON/OFF then I wouldn't have a need for AGENT CM.,
Thanks!

danc
Posts: 1017
Joined: 14 Oct 2016

09 Feb 2018

vectro wrote:
09 Feb 2018
danc wrote:
04 Feb 2018
I did spend 2 days trying to use Vienna Emsemble Pro, which allows you to run VSTs on multiple computers, all connected via Ethernet cable. It's a great idea. But there are many practical problems... but that's for another topic.
I'd actually like to see that topic. Practical problems?
I'm using CoreMIDI/rtpMIDI and Dante to put instruments on multiple computers and platforms over Ethernet. Been looking at VEP as the next step.
Ok - can you start the topic and I will comment on it with my findings. I did get it all set-up and demoed for about a week.
Check my Soundcloud:

chaosroyale
Posts: 728
Joined: 05 Sep 2017

09 Feb 2018

Finally did a test of Agent comparing performance when all tracks are active.
Don't shoot the messenger.
Attachments
agent results-2.png
agent results-2.png (70.86 KiB) Viewed 9392 times

househoppin09
Posts: 536
Joined: 03 Aug 2016

09 Feb 2018

Don't you still need to test VST instruments, though? Your findings aren't surprising, since a few people have already said that the CPU savings only happen with VST instruments, not VST effects. And I'd bet it varies further from one VST instrument to another as well, so danc or someone else who's done this will need to weigh in with specific examples of which VST instruments are supposed to benefit.

chaosroyale
Posts: 728
Joined: 05 Sep 2017

10 Feb 2018

Here is the test with VSTi instead of VST fx. 28 instances of various VSTi's, with or without Agent adding one more and switching on the spectrum display caused glitches.

Again, this confirms what the developer himself said. Agent takes more resources. It is useful if you only have a few VSTs operational at one time because it effectively switches them off when they are not making sound. However you can do that with combinators anyway and thereby avoid stability issues, which I encountered a couple of times with Agent.

tldr; there's no such thing as a free lunch.
Attachments
Untitled-2.png
Untitled-2.png (42.78 KiB) Viewed 9219 times

User avatar
miscend
Posts: 1955
Joined: 09 Feb 2015

10 Feb 2018

Those results are useful for testing. But you will see a genuine CPU advantage in a real world song project, where not all devices are being used at all times. And a workflow advantage whereby you don’t need to nest all your VSTs into combinators and then automating the on/off state whilst at the same time trying to compose a song.

User avatar
miscend
Posts: 1955
Joined: 09 Feb 2015

10 Feb 2018

chaosroyale wrote:
10 Feb 2018
Here is the test with VSTi instead of VST fx. 28 instances of various VSTi's, with or without Agent adding one more and switching on the spectrum display caused glitches.

Again, this confirms what the developer himself said. Agent takes more resources. It is useful if you only have a few VSTs operational at one time because it effectively switches them off when they are not making sound. However you can do that with combinators anyway and thereby avoid stability issues, which I encountered a couple of times with Agent.

tldr; there's no such thing as a free lunch.
What is the CPU usage when the song is not playing.

User avatar
Theo.M
Posts: 1035
Joined: 16 Jan 2015

10 Feb 2018

miscend wrote:
04 Feb 2018
I’m amazed at the CPU savings you are claiming here. That would be incredible if true. But then again £6 is a lot to spend on a magazine filled with regurgitated articles that I’ll will never read.

Also are there any practicality issues with using a VST to host other VSTs? Is there chance of plugin recall settings getting lost?
what's happening is that the vsts in this case are running in an outside process rather than reason.

it's like using vienna ensemble pro on the same computer, after your daw is maxed out and popping and crackling, to get more plugin instances. See, no daw can effectively use all the actual cpu of a computer , so there are always untapped reserves that can be accessed "outside" of it.

The other way to do this is to use jbridge to literally bridge 64 bit vst to a 64 bit vst.

The OP is correct but he just didn't realise that it's not using less DSP, rather that it's running in a process outside of reason. It's a valid way to get a lot more use out of a single machine...

chaosroyale
Posts: 728
Joined: 05 Sep 2017

10 Feb 2018

I think the results I posted plus the explanation from the developer of the software make it clear what users can expect from Agent, and they can judge whether or not that is suitable for their needs.

Here's the kernel of the quote from the developer again in case you missed it: (italics mine)

"If every track in your project is running all the time then you will see a small increase in CPU usage because AGENT also consumers some small amount of CPU on it's own."

NB: it also has a significant memory overhead, about +30 percent in the case of that VSTi test, as you can see above.

Conclusion: I can easily automate VSTs that are not producing sound to switch off, so that is not a DSP bottleneck. I want to increase the maximum number of VSTs I can run concurrently. In that case Agent actually performs slightly worse in DSP and significantly worse in memory, meaning one can use more concurrent VSti or VST fx without Agent.

I'm sorry to bear bad news, but it is what it is. Until Reason gets an update, your maximum VST usage is pretty limited.

User avatar
Theo.M
Posts: 1035
Joined: 16 Jan 2015

10 Feb 2018

chaosroyale wrote:
10 Feb 2018
I think the results I posted plus the explanation from the developer of the software make it clear what users can expect from Agent, and they can judge whether or not that is suitable for their needs.

Here's the kernel of the quote from the developer again in case you missed it: (italics mine)

"If every track in your project is running all the time then you will see a small increase in CPU usage because AGENT also consumers some small amount of CPU on it's own."

NB: it also has a significant memory overhead, about +30 percent in the case of that VSTi test, as you can see above.

Conclusion: I can easily automate VSTs that are not producing sound to switch off, so that is not a DSP bottleneck. I want to increase the maximum number of VSTs I can run concurrently. In that case Agent actually performs slightly worse in DSP and significantly worse in memory, meaning one can use more concurrent VSti or VST fx without Agent.

I'm sorry to bear bad news, but it is what it is. Until Reason gets an update, your maximum VST usage is pretty limited.
sorry, i only read the first couple of posts before i added my take.

Everything the dev makes sense and correlates with the outside process theory. It's like the VE Pro plugin will still have a tiny but of resource usage also, because it has a gui and is a plugin by it's very nature, even though it's communicating with the outside app.

I know nyrv is much cheaper right now than ve pro, as it is $99 vs $229 ish on sale this month i think (25% discount), but i still recommend VE Pro. It is every plugin users dream accompaniment imo. I have only demoed it for 5 days so far for the first time, and will be buying it the minute the demo expires. Note, you need an elicenser dongle or vienna dongle though.. (vienna dongle is rebranded elicenser afaik).

But for the free version of nyrv still being able to host plugins, that is really cool.

i also recommend every single vst user in existence buy jbridge, just for the sheer fact that any plugin that might act wonky in a daw natively, often works with jbridge. You see, the daw then only hosts the bridge itself, j bridge is what will crash if there is a crash. It's still only 9.90 euro after all these years and i consider it a plugin essential. In pro tools i actually host bridge vst's inside of patchwork aax, and it all works.. i can use old 32 bit vsts that way or use the vst version of crash prone aax plugins instead.. knowing only jbridge will crash if they do.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

11 Feb 2018

I can't be arsed to use/buy jbridge or agent, because I want things simple. As simple as possible. And while I can't use nearly as many VST in Reason as I can in Studio One, I still prefer to work in Reason and manage to get by right now OK.

That said, Magnus/Props said that they'd continue to refine Reason's VST performance - I'm sure they'll come through at some point.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
raymondh
Posts: 1776
Joined: 15 Jan 2015

11 Feb 2018

EnochLight wrote:
11 Feb 2018
I can't be arsed to use/buy jbridge or agent, because I want things simple. As simple as possible. And while I can't use nearly as many VST in Reason as I can in Studio One, I still prefer to work in Reason and manage to get by right now OK.

That said, Magnus/Props said that they'd continue to refine Reason's VST performance - I'm sure they'll come through at some point.
I'm with you on this, keep it simple. Though the tip of putting the VST in a combinator and turning off the combinator after bouncing to track is a great idea, to get around the continued DSP use after bouncing.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

11 Feb 2018

raymondh wrote:
11 Feb 2018
Though the tip of putting the VST in a combinator and turning off the combinator after bouncing to track is a great idea, to get around the continued DSP use after bouncing.
Yeah, that’s awesome. Very useful yet simple.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
Theo.M
Posts: 1035
Joined: 16 Jan 2015

12 Feb 2018

sorry Enoch it doesn't make sense in this case. J bridge is as close to invisible as possible. Once you go through the bridging app process once, they are just normal vsts in your vst folder.. the only difference is they will have a little jbridge border around them and be loading in their own process space. I could understand if it was some big job that had to be done each time or if the settings didn't save with your daw like any other plugin, but this is as transparent as it gets. What is happening behind the scenes is entirely invisible to the user. No seperate apps to open like with rewire or anything like that.
I find that response a bit silly to be honest, cause on one hand you are saying reason is not performing well with vsts like studio one does, (and in my own extensive 4 part tests testing all aspects of cpu usage of various DAWs, studio one was dead last vs logic/cubase/reaper/Protools.. i mean WAY dead last), and you have all this unused process space outside reason you could be having a ton more plug instances with, but they'd still be in your reason rack like any other vst plugin! Not even like vienna ensemble which has it's own big mixer app etc.. jbridge is nothing like that.

There is literally no complication added, to anyone even mildly vst competent, which i know you are, and well beyond.. you are an experienced DAW user as are many here.

vienna ensemble/bridging apps don't make much sense with pro tools, cause on both my macs, i am able to get 700% real cpu usage out of pro tools (maximum would be 800% on 8 cores) before dropouts and overload messages. There is literally nothing left TO tap into "outside" of the DAW.. my cpus are already throttling and fans are full blast, by the time i run out of power in pro tools.. it's amazing to see.. istat and activity monitor literally show each core at 85%+ steady. I can't get there even with logic (around 550% total usage before overload), Cubase and reaper ditto, S1 way behind that. But if i was using S1 or even cubase, i'd be using jbridge (for kontakt especially) religiously. I don't get your adversity to it in this case..

Hope you are not taking this post as an insult or anything, as i really don't mean it that way. I am merely perplexed is all.

chaosroyale
Posts: 728
Joined: 05 Sep 2017

12 Feb 2018

Theo.M wrote:
12 Feb 2018
...some stuff about jbridge
The only way to explain this clearly is to do a test with a lot of VSTs running in Reason directly and the same exact sequence running in Jbridge and post the CPU and memory uage of both.

I expect that there will be no major difference between the 2, and that Jbridge will only be useful in specific cases where someone has a VST that refuses to run directly in Reason. If I am wrong, go ahead and prove me wrong, I'd be happy!

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

12 Feb 2018

Theo.M wrote:
12 Feb 2018
sorry Enoch it doesn't make sense in this case. J bridge is as close to invisible as possible. Once you go through the bridging app process once, they are just normal vsts in your vst folder.. the only difference is they will have a little jbridge border around them and be loading in their own process space. I could understand if it was some big job that had to be done each time or if the settings didn't save with your daw like any other plugin, but this is as transparent as it gets. What is happening behind the scenes is entirely invisible to the user. No seperate apps to open like with rewire or anything like that.
I find that response a bit silly to be honest, cause on one hand you are saying reason is not performing well with vsts like studio one does, (and in my own extensive 4 part tests testing all aspects of cpu usage of various DAWs, studio one was dead last vs logic/cubase/reaper/Protools.. i mean WAY dead last), and you have all this unused process space outside reason you could be having a ton more plug instances with, but they'd still be in your reason rack like any other vst plugin! Not even like vienna ensemble which has it's own big mixer app etc.. jbridge is nothing like that.

There is literally no complication added, to anyone even mildly vst competent, which i know you are, and well beyond.. you are an experienced DAW user as are many here.

vienna ensemble/bridging apps don't make much sense with pro tools, cause on both my macs, i am able to get 700% real cpu usage out of pro tools (maximum would be 800% on 8 cores) before dropouts and overload messages. There is literally nothing left TO tap into "outside" of the DAW.. my cpus are already throttling and fans are full blast, by the time i run out of power in pro tools.. it's amazing to see.. istat and activity monitor literally show each core at 85%+ steady. I can't get there even with logic (around 550% total usage before overload), Cubase and reaper ditto, S1 way behind that. But if i was using S1 or even cubase, i'd be using jbridge (for kontakt especially) religiously. I don't get your adversity to it in this case..

Hope you are not taking this post as an insult or anything, as i really don't mean it that way. I am merely perplexed is all.
No, it's cool. My point is: having to install J bridge to run an additional piece of software is counterintuitive to working in Reason altogether, IMHO. I mean sure - if this works in the meantime, then awesome! But personally - I can wait until Props actually fix Reason's VST performance (and yes, it most certainly is "broken" IMHO). :)
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

12 Feb 2018

Soooo.. Did any1 check at what buffer size this wrapper runs the plugins? Should be easy to check if you have an UAD system, it shows the buffer size the plugins run on in the preferences panel. Would be interesting to know if this is mainly about the buffer size or if theres something else going on.

User avatar
Theo.M
Posts: 1035
Joined: 16 Jan 2015

13 Feb 2018

chaosroyale wrote:
12 Feb 2018
Theo.M wrote:
12 Feb 2018
...some stuff about jbridge
The only way to explain this clearly is to do a test with a lot of VSTs running in Reason directly and the same exact sequence running in Jbridge and post the CPU and memory uage of both.

I expect that there will be no major difference between the 2, and that Jbridge will only be useful in specific cases where someone has a VST that refuses to run directly in Reason. If I am wrong, go ahead and prove me wrong, I'd be happy!
well I am not a reason user at *all* anymore, but i do pop in once every few months to say hello and to the vst section. Regardless I did a test for you, I just used kontakt vst in jbridge via patchwork in pro tools., and no cpu usage showed in pro tools, it created it's own outside process (you can also choose with jbridge to have every single plugin instance put in it's own process)... it was jbrodge that was using the cpu..

I just checked on a heavy project at 64 buffer, where if i added another VI and put it in record mode (pro tools has a hybrid buffer that a VI only goes on your chosen low buffer if it's armed), the project overloaded.. I could not play a single note. So i added the jbrdige, and i was able to play an additional instance of kontakt even though all my cpus in activity monitor are literally hammered... So that's proof enough it works.

User avatar
Theo.M
Posts: 1035
Joined: 16 Jan 2015

13 Feb 2018

EnochLight wrote:
12 Feb 2018

No, it's cool. My point is: having to install J bridge to run an additional piece of software is counterintuitive to working in Reason altogether, IMHO. I mean sure - if this works in the meantime, then awesome! But personally - I can wait until Props actually fix Reason's VST performance (and yes, it most certainly is "broken" IMHO). :)
sad to read it mate.

I won't continue to argue the points cause if you can't see that one should do whatever is necessary to get the best performance.. then there's no point trying to convince you.. i am a bit shocked you think it's counter intuitive, but it is what it is!

Anyway, i am upset for you that reason's vst performance is no good.. Well, i guess it's the same old story like with rack extensions.

I am almost tempted to download the reason 10 demo and do my benchmark.

What it consists of is a very heavy vsti synth and how many copies of it can play back the same 32 bar midi file looped..

Second test is 64 audio tracks and copying the same trio of effects over and over till overload.

Third test is live playback of vsti's rather than high internal buffer playback (irrelevant on reason as it does not dual buffer, if you set it at 128 for example it is always at 128)

and fourth is armed for record audio tracks with effects.. again to test low latency performance monitoring.. not really valid for reason either.

But for example, in pro tools, at 128 buffer, if i record arm all the VI tracks, i get 16 in the first test i mentioned. So what i can do is put reason at 128 buffer and it would be the same thing wouldn't it, cause all armed tracks in pro tools work at that 128 buffer i have chosen (and all audio tracks with the "i" checked are enabled for software monitoring and are also put on the low buffer).

So i can still compare them that way, but in reason I will only do the two tests, and compare them to the results of only the "live" tests of the other daws, rather than any of the playback tests.

if anyone is interested in me doing it just say so and i'll do it.. otherwise i won't bother. I have 4 very extensive test scenarios i have saved in all other main DAW's that i have done the tests with.

Cheers

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

13 Feb 2018

Theo.M wrote:
13 Feb 2018
irrelevant on reason as it does not dual buffer, if you set it at 128 for example it is always at 128
No, Reason always runs all plugins at 64 samples no matter what, thats (probably) why it "doesn't perform well". The reason for that is modulation, it can happen only at the buffer frequency, hence my question.

User avatar
Theo.M
Posts: 1035
Joined: 16 Jan 2015

13 Feb 2018

normen wrote:
13 Feb 2018
Theo.M wrote:
13 Feb 2018
irrelevant on reason as it does not dual buffer, if you set it at 128 for example it is always at 128
No, Reason always runs all plugins at 64 samples no matter what, thats (probably) why it "doesn't perform well". The reason for that is modulation, it can happen only at the buffer frequency, hence my question.

ok, if i do the test i will set the other DAWs to 64 samples. If i disable studio one dropout protection then it's always at 64 samples. If i disable cubase asio guard same thing. If i arm the tracks in pro tools and have 64 buffer in preferences, same thing.
So, 64, right? Ok.

and yes that probably IS the answer.. absolutely none of the DAWs perform great when using multiple tracks at a 64 buffer.

*everything* changes just from 128 to 64 buffer in my "live, armed track" tests, on all DAWs. Performance gets worse than *half* in some cases.

so it might actually be, that reason is performing just as any other DAW would at 64 and there's nothing wrong with it at all. What Normen says makes perfect sense if all plugins are at 64 samples.

poor design choice.

Just curious Normen, if i set say a 1024 sample buffer in reason, but put a VSTI on a track and play it, are you saying i will also have 64 sample buffer playing response from my keyboard, not 1024?

Sounds like props have overcomplicated things.

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 8 guests