How to run loads more VSTs without buying a new CPU

[normen]

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.

No, you still get 1024, the processing cycle is simply executed multiple times per hardware buffer. And again, the design choice was made because the modulation rate (i.e. CV and parameter automation) is dependent on that. To put it differently: Only on the start of each buffer a plugin sets the values from its parameters and CV inputs. ANd while yes, internally Reason could have done it differently - VSTs work like that and theres no way around that. So if you want to be able to modulate VST parameters in Reason at frequencies that are common in Reason (above 40Hz) then you NEED to run it at a low buffer size.

This is exactly what we fought about before, Reason is „live“ internally, everything happens at 64 samples without any additional buffers or anything. Its not overcomplicating, its the most simple solution for that issue.

[EnochLight]

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. ...
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

Nah, don't bother wasting your time testing Reason in its current form - there's nothing really more to know that Props and us users don't already know. Wait until it's updated at some point in the future, and then give it another try if you're so inclined. But working inside of Reason hasn't changed at all since you last owned it, so I doubt better VST performance would change your mind to come back.

Anyway, don't be upset for me. I can get things done just fine, currently, and this is on my 6+ year old antiquated machine. It's all good!

[Theo.M]

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. ...
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

Nah, don't bother wasting your time testing Reason in its current form - there's nothing really more to know that Props and us users don't already know. Wait until it's updated at some point in the future, and then give it another try if you're so inclined. But working inside of Reason hasn't changed at all since you last owned it, so I doubt better VST performance would change your mind to come back.

Anyway, don't be upset for me. I can get things done just fine, currently, and this is on my 6+ year old antiquated machine. It's all good!

i would never come back. I have never been happier with a DAW as i am with pro tools. Ecstatic. In 2.5 years i haven't even considered another DAW. It's the best darn thing i have ever used. I don't even rewire ableton into it like i did with logic as it does everything i need as an all in one. I was just offering for you to see if i could reproduce your issue, but in fact i would really rather not do it, as it would mean i'd have to have codemeter on my system.. so.. no objections from me! Good luck!

[Theo.M]

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.

No, you still get 1024, the processing cycle is simply executed multiple times per hardware buffer. And again, the design choice was made because the modulation rate (i.e. CV and parameter automation) is dependent on that. To put it differently: Only on the start of each buffer a plugin sets the values from its parameters and CV inputs. ANd while yes, internally Reason could have done it differently - VSTs work like that and theres no way around that. So if you want to be able to modulate VST parameters in Reason at frequencies that are common in Reason (above 40Hz) then you NEED to run it at a low buffer size.

This is exactly what we fought about before, Reason is „live“ internally, everything happens at 64 samples without any additional buffers or anything. Its not overcomplicating, its the most simple solution for that issue.

Arguments were years ago who cares. You are a good guy with lots of knowledge and I think my tone these past few years has shown nothing but improvement and friendliness.

Ok so it's a simple solution, but sadly it means reason has poor plugin performance. I did a quick search after speaking to enoch and it seems he is not alone..

For whatever reason (NPI), i can have my REAL cpu usage at 700% in pro tools. So, it's using 1024 integral buffer for playback tracks, as well as dynamic processing so plugins don't use CPU over silence. Logic is next best. The highest i could ever get real cpu usage of reason (last ever tested was V9) was 250% before crackles and pops no matter the buffer chosen. And even if it IS because of the way it's using plugins at 64 samples because it *has* to, why does it matter when the result is that it performs poorly?

You know so much about this, my advice to you is to speak to props about it and maybe help them improve it.. I think it's in every reason user's best interest to maximise it's performance, but since right now it is not good, VE pro and j bridge are workarounds. You realise this is why i left the program so long ago.. in real world tests, reason popped with a couple of heavy Vi tracks and a few audio tracks and effects.. and now in PT on the very same computer, i can run 200 track projects.. - fact. I hope reason gets there, i will always have a soft spot for it cause it's so much FUN to compose with, but i didn't come here to argue, not at all. I just want the best for everyone.

peace.

PS.. if i set another DAW to 64 samples and disable high buffer playback processing, they too mean that "everything happens at 64 samples without any additional buffers or anything. ".
But you have never confirmed that one way or another in the years and years of this discussion.

If you can tell me why Cubase at 64 samples with asio guard disabled is any different to reason and why it performs better, please do.

[normen]

I don‘t think theres much to improve. Horses for courses. If you want to mix lots of Kontakt instruments with UAD plugins then you simply shouldn‘t use Reason. Some VST plugins (probably those that run well on low buffer sizes because of fitting algos) work just fine in Reason and can nicely improve the Reason experience so thats what I take from VST integration. Generally I am not a big fan of VST integration exactly because its shoehorning something onto Reason that just doesn‘t fit there imo.

Edit: As for the general discussion, I still don‘t see why the same code with the same binary would suddenly perform worse depending on what external application calls it. Even less so with the EXACTLY same VST, where before with REs you‘d have at least two different compiler outputs. HOW its called (i.e what the app asks from it, what buffer size etc.) - thats a different thing.

Edit2: But as I said elsewhere before, the Props could add an optional larger buffer size for (user selectable?) VSTs, at the cost of those then causing additional latency and not being able to be automated at high frequencies.

[miscend]

Jbridge is over priced at 14 bucks. It needs to come down to 9 bucks.

[Theo.M]

Jbridge is over priced at 14 bucks. It needs to come down to 9 bucks.

i really hope you are joking

[Theo.M]

I don‘t think theres much to improve. Horses for courses. If you want to mix lots of Kontakt instruments with UAD plugins then you simply shouldn‘t use Reason. Some VST plugins (probably those that run well on low buffer sizes because of fitting algos) work just fine in Reason and can nicely improve the Reason experience so thats what I take from VST integration. Generally I am not a big fan of VST integration exactly because its shoehorning something onto Reason that just doesn‘t fit there imo.

Edit: As for the general discussion, I still don‘t see why the same code with the same binary would suddenly perform worse depending on what external application calls it. Even less so with the EXACTLY same VST, where before with REs you‘d have at least two different compiler outputs. HOW its called (i.e what the app asks from it, what buffer size etc.) - thats a different thing.

Edit2: But as I said elsewhere before, the Props could add an optional larger buffer size for (user selectable?) VSTs, at the cost of those then causing additional latency and not being able to be automated at high frequencies.

but reason did not perform great with rack extensions either. Reason's performance shone up to the rack extension addition.. Before that, you could run hundreds of the built in devices (and still can i presume, of those particular devices).

One thing I have been trying to explain for an eternity though, is that reason falls apart quicker than other DAWs.. It simply can not access the same percentage of your total cpu across it's multithreading before crackling as other daws can. This is irrespective of whether you use vst/RE/ or just built in devices. The built in devices like thor et al, simply take longer to get you there because they are SO light on dsp, especially on modern i7's. BUT, reason still falls apart at about the same percentage of cpu usage, it's just that RE's and vsts will get it there way quicker.

It's not the answer to say if you want to use a lot of vsti's don't use reason.. reason is a fully fledged DAW with advanced features and midi, and is targeted at composers IMHO.. the answer should be that props improve it...

I did test 9 demo to load and export some old songs' midi, and the pdc was awful. I don't know if ten is any different. All i know is that the pdc has no visual compensation from the time i tested it, so the playhead cursor was not in time with the music. I hope this gets improved too.

I think it's time for props to stop adding features and buckle down on the plugin performance and pdc engine and just refine it like crazy.. that's what I would do if i was them anyway.. and there is no reason why they can't add a playback buffer for non armed vsti tracks that aren't in complex modular configurations.. to improve performance.. just for straight vsti's that have the vsti and normal insert effects.. they could mimic the way other daw's do it for those tracks.

[normen]

I don‘t think theres much to improve. Horses for courses. If you want to mix lots of Kontakt instruments with UAD plugins then you simply shouldn‘t use Reason. Some VST plugins (probably those that run well on low buffer sizes because of fitting algos) work just fine in Reason and can nicely improve the Reason experience so thats what I take from VST integration. Generally I am not a big fan of VST integration exactly because its shoehorning something onto Reason that just doesn‘t fit there imo.

Edit: As for the general discussion, I still don‘t see why the same code with the same binary would suddenly perform worse depending on what external application calls it. Even less so with the EXACTLY same VST, where before with REs you‘d have at least two different compiler outputs. HOW its called (i.e what the app asks from it, what buffer size etc.) - thats a different thing.

Edit2: But as I said elsewhere before, the Props could add an optional larger buffer size for (user selectable?) VSTs, at the cost of those then causing additional latency and not being able to be automated at high frequencies.

but reason did not perform great with rack extensions either. Reason's performance shone up to the rack extension addition.. Before that, you could run hundreds of the built in devices (and still can i presume, of those particular devices).

One thing I have been trying to explain for an eternity though, is that reason falls apart quicker than other DAWs.. It simply can not access the same percentage of your total cpu across it's multithreading before crackling as other daws can. This is irrespective of whether you use vst/RE/ or just built in devices. The built in devices like thor et al, simply take longer to get you there because they are SO light on dsp, especially on modern i7's. BUT, reason still falls apart at about the same percentage of cpu usage, it's just that RE's and vsts will get it there way quicker.

It's not the answer to say if you want to use a lot of vsti's don't use reason.. reason is a fully fledged DAW with advanced features and midi, and is targeted at composers IMHO.. the answer should be that props improve it...

I did test 9 demo to load and export some old songs' midi, and the pdc was awful. I don't know if ten is any different. All i know is that the pdc has no visual compensation from the time i tested it, so the playhead cursor was not in time with the music. I hope this gets improved too.

I think it's time for props to stop adding features and buckle down on the plugin performance and pdc engine and just refine it like crazy.. that's what I would do if i was them anyway.. and there is no reason why they can't add a playback buffer for non armed vsti tracks that aren't in complex modular configurations.. to improve performance.. just for straight vsti's that have the vsti and normal insert effects.. they could mimic the way other daw's do it for those tracks.

Yeah well. You can fish the answers to those questions and statements from my post history. You keep dragging in the kitchen sink and I‘m really not interested discussing all of those boring topics again. A hint for the technical questions might be „DSP load is not CPU load“.

Did anyone check what buffer size this wrapper runs the plugs at please?

[miscend]

Jbridge is over priced at 14 bucks. It needs to come down to 9 bucks.

i really hope you are joking

It’s actually 15 bucks!

It should be cheaper. It’s quite buggy; you have to rescan plugins a few times for it to work properly and often times there are glitches in the way it renders some Vst GUIs. I would be willing to accept all its quirks at a lower price like 9 bucks.

[Zac]

i really hope you are joking

It’s actually 15 bucks!

It should be cheaper. It’s quite buggy; you have to rescan plugins a few times for it to work properly and often times there are glitches in the way it renders some Vst GUIs. I would be willing to accept all its quirks at a lower price like 9 bucks.

I thought you must be joking too. 14 tokens to get almost any 32 bit plugin working at 64 bit for reason.... ummm i would have paid double easy. It's a great utility.

[miscend]

It’s actually 15 bucks!

It should be cheaper. It’s quite buggy; you have to rescan plugins a few times for it to work properly and often times there are glitches in the way it renders some Vst GUIs. I would be willing to accept all its quirks at a lower price like 9 bucks.

I thought you must be joking too. 14 tokens to get almost any 32 bit plugin working at 64 bit for reason.... ummm i would have paid double easy. It's a great utility.

There’s only one 32 bit plug-in that I still need. That’s SQ8L. The GUI works but is glitchy with jbridge.

[Theo.M]

but reason did not perform great with rack extensions either. Reason's performance shone up to the rack extension addition.. Before that, you could run hundreds of the built in devices (and still can i presume, of those particular devices).

One thing I have been trying to explain for an eternity though, is that reason falls apart quicker than other DAWs.. It simply can not access the same percentage of your total cpu across it's multithreading before crackling as other daws can. This is irrespective of whether you use vst/RE/ or just built in devices. The built in devices like thor et al, simply take longer to get you there because they are SO light on dsp, especially on modern i7's. BUT, reason still falls apart at about the same percentage of cpu usage, it's just that RE's and vsts will get it there way quicker.

It's not the answer to say if you want to use a lot of vsti's don't use reason.. reason is a fully fledged DAW with advanced features and midi, and is targeted at composers IMHO.. the answer should be that props improve it...

I did test 9 demo to load and export some old songs' midi, and the pdc was awful. I don't know if ten is any different. All i know is that the pdc has no visual compensation from the time i tested it, so the playhead cursor was not in time with the music. I hope this gets improved too.

I think it's time for props to stop adding features and buckle down on the plugin performance and pdc engine and just refine it like crazy.. that's what I would do if i was them anyway.. and there is no reason why they can't add a playback buffer for non armed vsti tracks that aren't in complex modular configurations.. to improve performance.. just for straight vsti's that have the vsti and normal insert effects.. they could mimic the way other daw's do it for those tracks.

Yeah well. You can fish the answers to those questions and statements from my post history. You keep dragging in the kitchen sink and I‘m really not interested discussing all of those boring topics again. A hint for the technical questions might be „DSP load is not CPU load“.

Did anyone check what buffer size this wrapper runs the plugs at please?

No it seems you don't understand the difference between cpu and dsp load and keep trying to pile that back on me.

You are always nasty and condescending and a huge part of why I had muted you, but i unmuted you as it had been ages, tried to be nice to you, responded politely, and you have been your usual high almighty self. Such a nasty person.

Don't worry, this is literally, the absolute last time in my entire life, whatever of it is left, that I will ever see another thing you write, nor speak to you ever again.

To others who are interested:

When i am talking about CPU load, i am talking about the real cpu load using istat or activity monitor.

When REASON'S dsp bar is full and crackling is occurring, in my machine it is only about 250% of total 8 core load, which has a maximum of 800%.

DSP meters in DAW's *ARE* a very useful indication.. for example, Cubase's meter is an asio meter, NOT a cpu meter.
But you will find, that if that meter is full, Cubase has issues. Just like when Reason's dsp meter is full, reason can not play back without clicks and pops.

The difference is, which Normen can't comprehend (or he does and his incessant hatred of me is just that strong that he always has to be difficult about it)., is that when reason's dsp meter is full, the REAL CPU usage of the computer, is about half of other DAWs.. it simply can't as efficiently access all the power.. When cubase's asio meter is full, the real cpu being used is almost 600% of the 800%. Vs 250 ish percent with reason.
This is exactly where j bridge and vienna come in.

Logic gets to 600, PT to 700 percent. Nothing load balances like PT.. Anyway it's very simple, i installed the 10 demo and nothing has changed even on my modern macbook pro.. a totally different computer to when i previously used reason. You can see in the logical core usage monitor (of which there are 8, 4 real cores), that they are all hovering about 35 to 40% when reason will no longer play back, at any buffer size, and it's own dsp meter is full.

With Pro tools, They are all above 85%, some even hit 92% *real* usage..Pro tools takes the cpu to 90+ degrees, reason keeps it cool. Reason is not effectively using the processing power of the computer. To do a comparison i tested instances of ozone 7 as well as my VI polyphony test. Reason can do 4 tracks of the Vi that pro tools does 16 of, and ozone instances spread across 32 audio tracks are 2.9x higher in PT.

So? Who cares how the other DAWs do it, they do it. I was merely suggesting that props take a look at options, like they did with PDC, for their customers.

Anyway, see you all in a year, it's been interesting.. Good luck to all. I really only came in here mentioning solutions as i was simply trying to help those with performance issues.

[Theo.M]

I thought you must be joking too. 14 tokens to get almost any 32 bit plugin working at 64 bit for reason.... ummm i would have paid double easy. It's a great utility.

There’s only one 32 bit plug-in that I still need. That’s SQ8L. The GUI works but is glitchy with jbridge.

this was not about 32 bit bridging.. I don't know why you are coming here and bagging a quality product like j bridge, when it might have some issues with a very outdated, unsupported and no longer updated VSTI.

I was talking about 64 bit to 64 bit bridging to save CPU power by loading vst's in reason in the jbridge process rather than reason's.

Anyway, why not send the developer a note and ask him if he can make it work with that vsti?

he is probably the nicest person I have ever dealt with. Literally.

[miscend]

There’s only one 32 bit plug-in that I still need. That’s SQ8L. The GUI works but is glitchy with jbridge.

this was not about 32 bit bridging.. I don't know why you are coming here and bagging a quality product like j bridge, when it might have some issues with a very outdated, unsupported and no longer updated VSTI.

I was talking about 64 bit to 64 bit bridging to save CPU power by loading vst's in reason in the jbridge process rather than reason's.

Anyway, why not send the developer a note and ask him if he can make it work with that vsti?

he is probably the nicest person I have ever dealt with. Literally.

Well you brought it up as an alternative to Agent. And I brought the reason why I won’t use it; because it’s expensive and buggy for me. SQ8L is not buggy in other hosts, it was coded 100% up to spec and good as is.

Not that it really matters anymore because it has since transpired that NYRV might be out of business. As they haven’t been any updates to Agent (or Agent CM) and as of recently they haven’t been replying to customer emails.

Did you quit KVR?

[vectro]

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.

I don’t get why I should start a topic on practical problems with VEP? Just tell us

[superpop]

I was talking about to save CPU power by loading vst's in reason in the jbridge process rather than reason's.

Really? I would like to know more about this statement if you don't mind.

[chaosroyale]

Am I going to have to disprove this "magic" solution as well, like I did with the "agent CM" VST host that started this thread?

Adding additional wrappers/processes when running VSTs inside Reason cannot improve performance.

Some people have reported good results running VSTs outside of Reason and using midi loopback, but I find that too much of a pain in the ass plus you cannot use CV wiring.

tl,dr: until Props improve the VST handling in Reason (auto-switch off for VSTs with empty buffers, option for larger buffers for VSTs which are not taking CV inputs, etc) , you are stuck with it as is.

I was talking about to save CPU power by loading vst's in reason in the jbridge process rather than reason's.

Really? I would like to know more about this statement if you don't mind.

[kitekrazy]

32 bit bridging uses more CPU. All VSTs are not equal either. Even the best systems get taxed. Bounce or mix at a higher latency. At one time people use to set their buffer at 100ms for mixing.

[aeox]

32 bit bridging uses more CPU. All VSTs are not equal either. Even the best systems get taxed. Bounce or mix at a higher latency. At one time people use to set their buffer at 100ms for mixing.

Mine is near 100ms currently

[superpop]

Well I run a quick test with demo versions of Diva and Jbridge and I had bad results that when I run Diva inside Reason.

7 instances of Diva/Jbridge and "Computer too slow..."

7 instances of Diva inside Reason and 3-4 DSP bars.

Am I going to have to disprove this "magic" solution as well, like I did with the "agent CM" VST host that started this thread?

Adding additional wrappers/processes when running VSTs inside Reason cannot improve performance.

Some people have reported good results running VSTs outside of Reason and using midi loopback, but I find that too much of a pain in the ass plus you cannot use CV wiring.

tl,dr: until Props improve the VST handling in Reason (auto-switch off for VSTs with empty buffers, option for larger buffers for VSTs which are not taking CV inputs, etc) , you are stuck with it as is.

Really? I would like to know more about this statement if you don't mind.

[Theo.M]

well there you go.. My Logic was that it would be using process space outside of Reason itself..

VE Pro though, *should* be a solution for better performance of VST instruments, and just use your FX in reason over the return channel of the VE Pro audio. People swear by that thing and say using it on the same machine (particularly in windows) gives way better instrument performance. Disclaimer, on my mac and Pro Tools/Cubase, i could not get any performance benefit using VE Pro, and in fact it made it worse.. but those DAWs are able to use 95% of my cpu, as in my REAL cpu not the DAW meter, and play back the song.. Reason can't do that, so, there may be a real benefit with VE Pro.

In Pro Tools, on my 8 core/16 thread iMac Pro, using VI tracks in a heavy test, I was able to get activity monitor showing over 90% on every single core and the project was playing back (computer was so bogged down the meters were jumping, it was literally being hammered).. Out of a possible 16 threads, 1600% cpu usage, I was getting it to 1500%. That's incredible. I tried reason 10 demo out of sheer curiosity, and I could not even get it to use half of the computer's real cpu before pops and clicks, like 600% ish. (using ua apollo as interface and to double check, the iMac pro on board audio)..Big difference. So there's all that process space free, surely VE Pro could use that, surely. I can't believe that 8 years later after I complained how much Reason performance sucked with RE's, that it's even worse now with VST's and never got fixed or optimised. That boggles me. I never read as many performance issue reports on any DAW as I read here at this forum. i DO know one thing, Reason at low latency runs much, MUCH better on windows than Mac.. you can get much higher real cpu utilisation without pops and clicks. If someone is using reason as their main DAW, i recommend windows wholeheartedly. Because the other programs use dual buffers, the problem of low latency on OSX has been "worked around" and the performance gap closed.. for example cubase on windows and mac, for ultimate effect and VST count in a project, has evened out when compared on similar hardware.. Only because of asio guard.

You could also host VE Pro as a standalone rather than using the audio piping plugin that comes with it, so you can set it to really low latency and it's not using cpu in the DAW.. use it like a hardware synth with it's own audio output.. Whatever reason can't use, it should be able to use.. Using it that way, even on my old macbook, I was able to run it at 64 buffer across 8 threads using a lot of VI's and I used standard midi tracks in the DAW to control it, I think in reason they are called external instrument tracks, which I've never used with it..I deleted the reason 10 demo but there's still demo time left if i reinstall it, if you guys want results with it and VE Pro to see if you can host more instruments that way.. I could try...