Is there a way of telling how CPU intensive VSTs are?

[Finbar]

If I use too many VSTs in a project on Reaper, my playback starts stuttering, which makes it hard to do much more. If I turn stuff off, then it works fine again. I'm cool with that, as I don't need everything on all the time. But is there a way of seeing which VSTs use how much CPU, so I know which ones it is most efficient to leave off etc? I use Reaper.

Thanks

[paul_5]

[quote name='Finbar' post='1275435' date='Jun 20 2011, 12:02 AM']If I use too many VSTs in a project on Reaper, my playback starts stuttering, which makes it hard to do much more. If I turn stuff off, then it works fine again. I'm cool with that, as I don't need everything on all the time. But is there a way of seeing which VSTs use how much CPU, so I know which ones it is most efficient to leave off etc? I use Reaper.

Thanks [/quote]
Have you tried using grouping stuff and/or using FX busses to reduce instances of VSTs? just a thought. You could also export tracks that you are happy with and then turn off all of the VSTs on that track, that way you could still develop a piece without having to cull plugins.

[51m0n]

[quote name='Finbar' post='1275435' date='Jun 20 2011, 12:02 AM']If I use too many VSTs in a project on Reaper, my playback starts stuttering, which makes it hard to do much more. If I turn stuff off, then it works fine again. I'm cool with that, as I don't need everything on all the time. But is there a way of seeing which VSTs use how much CPU, so I know which ones it is most efficient to leave off etc? I use Reaper.

Thanks [/quote]

ctrl-alt-p

Or View-> Performance Meter

Will give a complete breakdown of where the load is.

Learning to group tracks and st up aux sends to tracks to conserve CPU power is really vital, Reaper is particularly superb at this kind of routing shenanigans. A good read of the excellent manual is a very good idea!

[Finbar]

Yeah, I have a decent comprehension of Reaper's routing I think (not the best, but I'm still learning!). Right now in this project I basically have my drum tracks all grouped together in one 'folder' (Steven Slate Drums, so they're a VST in themselves), with a compressor on the master bus, but I've not processed them any further yet, so that will add more instances of VSTs when I start EQ'ing etc. Then I have a few tracks of bass, which all have impulse response plugins and EQ/amp sims. They're all in one grouping, but I can't condense the number of VSTs any further there as each track uses different VST settings. I also have a bunch of guitar tracks that are grouped together, which are equally all using different instances of VSTs on each track. I don't think I can get away with using less, and I was hoping to avoid having to bounce things down when I'm still working on stuff, but I'll have more of a play. I'll definitely look at the ctrl/alt/p thingy too! Cheers

[51m0n]

SOunds like you've got a lot of the routing stuff pretty much sorted.

However have you noticed that you can add audio channels to a track?

So you can have track 1 as an aux send for a reverb say.

Then if you have a drum kit in a group that is track 2 and your bvs in a group that is track 10 you can add channels of ausio to each group (one for each contained track that needs to send to the reverb), then route the send through the channels on the group and from the channels on the group to the reverb aux.

This is useful since it means that the level of signal sent to the aux track is dependant on the level of the group fader as well as the level of the send fader on each track within the group.

That way when you change the level of the group, you change the level of the reverb generated by the group.

This means you can get some fx outside of the groups they work in, which can save a lot of CPU as you dont have to repeat the effect.

Its great for reverbs, delays, parallel compression (not so much, but I have bothered with it before).

The routing does become more complex to set up, but the behaviour of group fades becomes far more as you would expect.

[lowdown]

After you have finished tracking/recording etc you can knock the latency up as well.....
I should imagine Reaper is ok/good at Plug in delay compensation.

Of course with quality Quad/Dual cores [CPU's] it shouldn't be an issue these days.



Garry

[~tl]

Another tip is that when you're happy with the sound of a particular track, render it down to a "static" audio file. For amp simulations, this will save a lot of CPU power as it just needs to play the audio without the additional processing load of the plugin. It's worth keeping the original track and a note of the plugin settings in case you decide to go back and recreate something. You can usually save the plugin settings and reload them later.

[lowdown]

[quote name='~tl' post='1285617' date='Jun 28 2011, 07:52 PM']Another tip is that when you're happy with the sound of a particular track, render it down to a "static" audio file. For amp simulations, this will save a lot of CPU power as it just needs to play the audio without the additional processing load of the plugin. It's worth keeping the original track and a note of the plugin settings in case you decide to go back and recreate something. You can usually save the plugin settings and reload them later.[/quote]


Yep that as well - or just archive the original track, that way the plug and info is still all there and then there will be zero hit on the cpu[s]
Un archive if you want to change things.



Garry