FX on folder tracks more CPU demanding?

[borg64]

Hey Reaper folks!

I use folder tracks as busses a lot when mixing in Reaper. For example, I usually put all my drum tracks under a folder track called DRUM BUSS, which often also contains nested folder tracks (e.g. Kick Buss, Snare BUSS, OH Buss, Perc Buss etc.). I work like this mainly for two reasons; easy to mute/solo entire sections as this approach fits my preferred mix project layout (most of my client mixes creep up to around, or well above, 100 tracks these days), but also to apply general (often more CPU intensive) FX processing to the whole buss folder rather than on individual tracks.

When inserting more CPU-taxing AUs/VSTs on these folder tracks, I often get a lot more glitching/pops/clicks than if I use the very same FX on the ”child” tracks - I can get away with loads of instances of these FX on the child tracks, but may experience dropouts with just singular use on folders.

The most obvious occurrence is when I create a top master folder for all my other folder and tracks (i.e. a 2BUSS folder, nesting the rest of the project contents underneath), which then goes to my MASTER track. If I insert a buss compressor and EQ on the 2BUSS folder, the system occasionally gets bogged down quite fast. If I instead move these FX to the MASTER track, system runs smooth again.

Is this behaviour to be expected? I’m going to try routing stuff ’the old fashioned way’ and create AUX tracks with sends/receives for my next mix project, but just wanted to check if there’s something I’m missing here.

Reaper version is 5.33/64 bit on a Mac Pro 2012 with 3.33 GHz 6-core Xeon and 24 GB of RAM running OS X 10.9.5. My system, mix and audio library disks are on three separate SSD:s from Angelbird.

Many thanks for your time!

Sven

[Sweet4]

5.35 and 5.40 version better with cpu and plugins like SLATE DIGITAL 32bit handles better on my el capitan

[vanhaze]

Because plugins on MASTER Track don't benefit from anticipative processing, it's always advised to make a folder track in which al tracks are nested, so this folder
track serves as the master track.
Just like you do.
So, The fact that you get better performance when placing the "master plugins" on Reaper Master Track instead of the "master folder track" is weird imho.

The other issue you describe: better performance when placing plugins on individual child tracks instead of their folder track is something hopefully someone can explain, enlighten about.
Would like to know if this true ..

Originally Posted by borg64

Hey Reaper folks!

I use folder tracks as busses a lot when mixing in Reaper. For example, I usually put all my drum tracks under a folder track called DRUM BUSS, which often also contains nested folder tracks (e.g. Kick Buss, Snare BUSS, OH Buss, Perc Buss etc.). I work like this mainly for two reasons; easy to mute/solo entire sections as this approach fits my preferred mix project layout (most of my client mixes creep up to around, or well above, 100 tracks these days), but also to apply general (often more CPU intensive) FX processing to the whole buss folder rather than on individual tracks.

When inserting more CPU-taxing AUs/VSTs on these folder tracks, I often get a lot more glitching/pops/clicks than if I use the very same FX on the ”child” tracks - I can get away with loads of instances of these FX on the child tracks, but may experience dropouts with just singular use on folders.

The most obvious occurrence is when I create a top master folder for all my other folder and tracks (i.e. a 2BUSS folder, nesting the rest of the project contents underneath), which then goes to my MASTER track. If I insert a buss compressor and EQ on the 2BUSS folder, the system occasionally gets bogged down quite fast. If I instead move these FX to the MASTER track, system runs smooth again.

Is this behaviour to be expected? I’m going to try routing stuff ’the old fashioned way’ and create AUX tracks with sends/receives for my next mix project, but just wanted to check if there’s something I’m missing here.

Reaper version is 5.33/64 bit on a Mac Pro 2012 with 3.33 GHz 6-core Xeon and 24 GB of RAM running OS X 10.9.5. My system, mix and audio library disks are on three separate SSD:s from Angelbird.

Many thanks for your time!

Sven

[borg64]

Originally Posted by Sweet4

5.35 and 5.40 version better with cpu and plugins like SLATE DIGITAL 32bit handles better on my el capitan

Hey Sweet4 and thanks for the reply,

This doesn’t seem to be a CPU vs. specific plugins issue; it seems related to the handling of folder tracks in Reaper. I work strictly in the 64 bit version.

Happy weekend!

//Sven

[borg64]

Originally Posted by vanhaze

Because plugins on MASTER Track don't benefit from anticipative processing, it's always advised to make a folder track in which al tracks are nested, so this folder
track serves as the master track.
Just like you do.
So, The fact that you get better performance when placing the "master plugins" on Reaper Master Track instead of the "master folder track" is weird imho.

The other issue you describe: better performance when placing plugins on individual child tracks instead of their folder track is something hopefully someone can explain, enlighten about.
Would like to know if this true ..

Hey vanhaze,

Thanks for your input!

To clarify, if I create another folder track above my 2BUSS folder track (i.e. an EXTRA 2BUSS folder, which nests everything beneath including the 2BUSS) and move my 2BUSS plugins there instead, performance is back to normal. As is plugins inserted directly on the actual Master Out track, as long as I have an empty 2BUSS folder ”between” the Master Out and the rest of the session tracks. E.g. the empty track is nesting everything else, before it hits the Master Out.

This is definitely a functioning workaround, but I’d rather not have to layout my sessions this way as it occasionally becomes overly complicated when there's subsequent folder tracks, which in turn may (or must, depending on how the CPU is reacting) contain even more folder tracks ”between” child tracks and the BUSS folders. Maybe I’m just abusing folder tracks too much.

The more child tracks summed to a folder (e.g. a buss), the more punishment on the CPU perfomance on these buss/folder plugins. So a 2BUSS folder, nesting the entire session directly underneath it, becomes unusable for less CPU-economic plugins. In this case I leave the 2BUSS folder empty and just use it for session automation, then put my master FX on the actual Master Out track.

If this is to be expected due to how Reaper sums child tracks, I will happily continue creating these in-between CPU-saving folder tracks. But it just feels like a bug right now, and I wanted to check if I’m doing something wrong here. Which is quite possibly the case.

Apologies if this made no sense whatsoever, maybe I should screenshot this…

Have a nice weekend!

//Sven

[vanhaze]

I gotcha, well explained.

Would be nice if we could get official Cockos statement / clearification about this.

[Lokasenna]

I just did a quick test, making ten nested folders and putting the same FX chain on each folder track. There was no difference in CPU usage for any of them.

Not a particularly thorough test, I'll admit.

[mlprod]

I have the same experience here Sven. Moving plugins from the Master folder track to the master track easesn up the burden on the CPU a little bit.

Its definitely the case that reaper gets hit with more CPU load when having a really folder based work flow with lots of plugins/processing on busses (folders).

[borg64]

Originally Posted by Lokasenna

I just did a quick test, making ten nested folders and putting the same FX chain on each folder track. There was no difference in CPU usage for any of them.

Not a particularly thorough test, I'll admit.

Hey Lokasenna!

It seems more likely to happen with larger projects and more CPU-demanding plugins, especially when there are lots of child tracks and folders underneath. I guess there’s some complex math happening under the hood when the parent folder track does its summing of nested child tracks and folders, but I only notice the bad hit performance-wise when there are plugins on the immediate parent track.

I’ve noticed this happen with only light processing on the child tracks, it’s the heavier stuff on the immediate parent folders that causes the issue here.

//Sven

[borg64]

Originally Posted by mlprod

I have the same experience here Sven. Moving plugins from the Master folder track to the master track easesn up the burden on the CPU a little bit.

Its definitely the case that reaper gets hit with more CPU load when having a really folder based work flow with lots of plugins/processing on busses (folders).

Hey mlprod!

Although I feel bad hearing you’re experiencing the same issue, it’s kinda nice to know I’m not going insane here. Thanks!

Also: awesome weather we’re finally having in Stockholm!

//Sven

[serr]

A while back someone was claiming the opposite. That using folder tracks instead of normal "universal" tracks (standard Reaper tracks that can be routed however you want with no restrictions) used less CPU.

I took a large-ish project (around 200 tracks and just as many plugins) and converted everything over to use folder tracks instead of the standard bus routing. 100% identical CPU use. An exercise in wasting time I will not be repeating!

What I do know is that if you stack up enough plugins that add to PDC on a track that PDC seems to get taxed and gets crashy after a point. I say crashy because you get clicks and pops even though you aren't hitting any wall with CPU use - the typical red flag that points to a plugin crashing.

You'll find that if you split the plugins across two (or more) tracks in that scenario that it fixes it. Just daisy chain route across two tracks.

Hope that helps.

[Mr. PC]

Could this be because the parent track is processing the effect on each child separately? For example, a compressor on the parent is actually compressing each child independently (like putting a compressor on each child)?

Does the sound change in any way if you put an effect onto a 'grandparent' track rather than simply a parent track?

Try this... render 2 versions of the same project,
One with the tracks all under a parent track with some effects on it.
The other with a 'grandparent track' and the effects from the parent track moved to the grandparent.

Import both renders into a project and phase reverse... see if they sum to 0.

{disclaimer. I have no idea what I'm talking about. Just speculating based on my limited knowledge}

[serr]

Originally Posted by Mr. PC

Could this be because the parent track is processing the effect on each child separately? For example, a compressor on the parent is actually compressing each child independently (like putting a compressor on each child)?

I'm confident that there is no such feature in Reaper.
ie. A plugin on a parent track having an instance of itself inserted on any/every child track behind the scenes (and remaining invisible). If there was, there would certainly be a switch to turn that on/off.

I'm pretty sure the only unique feature folder tracks have (besides restricted use) is the ability to be used as an organization tool to hide child tracks. (You can choose to NOT route child tracks to the parent folder and use then solely for organization. Then using standard send/receive routing normally.)

Seriously, try splitting plugins with high-ish PDC needs across multiple tracks. Just daisy chain route as needed. PDC does crash and this is the workaround.

[vanhaze]

Dear serr, thank you for your response.

One sentence i don't understand:
"PDC does crash and this is the workaround. "

I am a total PDC noob..could you please explain what this sentence exactly means ?
I am quite interested.

[mlprod]

Originally Posted by serr

Seriously, try splitting plugins with high-ish PDC needs across multiple tracks. Just daisy chain route as needed. PDC does crash and this is the workaround.

A first a (admittedly sloppy test) didnt improve things here, need to test more though.
I don't doubt that subgroups would generate the same results, but I think the original question was regarding if Reaper put more stress on the CPU when plugins are on parent tracks rather than child tracks and that if definitely the case here. Which isnt that strange either, but all tricks to make a super dense mix arr in 96k run smoother is helpful for sure.

I think this thread should move to the general forum.

[mlprod]

Originally Posted by borg64

Also: awesome weather we’re finally having in Stockholm!

//Sven

Indeed!=))

[vanhaze]

In Holland too, Long Live Spring !!

[Lokasenna]

Originally Posted by vanhaze

Dear serr, thank you for your response.

One sentence i don't understand:
"PDC does crash and this is the workaround. "

I am a total PDC noob..could you please explain what this sentence exactly means ?
I am quite interested.

Plugins that need to look ahead of the current signal (limiters, noise gates, lots of other stuff too) add a certain amount of delay to the signal to do so; they let Reaper know how much, and Reaper compensates for that delay when it plays everything back so you hear the correct things at the correct time.

Because Reaper has to put in more effort to do this, having a lot of plugins requesting PDC can be really taxing on your system even though the plugins aren't actually using that much CPU on their own. This can lead to clicking/popping/stuttering/glitching in situations where you wouldn't expt it.

[serr]

Using the C word is perhaps a bit flippant.

I said that because I haven't been able to establish a threshold for this. For example, something like "Any track that needs more than X samples of PDC to offset for all the inserted plugins will crash PDC."

X seems to be a moving target. So there must be another variable beneath the surface. ie. Tracks needing anything over X samples of PDC and if one or more of the plugins are (mystery variable).

That you can daisy chain route two tracks with the same plugins inserted across them and with the same things going on upstream of those tracks to cure this strongly points to issues with PDC or something related to it though.

[vanhaze]

Serr and Lokasenna, your are both heroes, i understand much better now, thx !!
EDIT: I never knew PDC taxes the cpu in a DAW (Reaper) more ; thats vital info for me !

[borg64]

Originally Posted by serr

A while back someone was claiming the opposite. That using folder tracks instead of normal "universal" tracks (standard Reaper tracks that can be routed however you want with no restrictions) used less CPU.

I took a large-ish project (around 200 tracks and just as many plugins) and converted everything over to use folder tracks instead of the standard bus routing. 100% identical CPU use. An exercise in wasting time I will not be repeating!

What I do know is that if you stack up enough plugins that add to PDC on a track that PDC seems to get taxed and gets crashy after a point. I say crashy because you get clicks and pops even though you aren't hitting any wall with CPU use - the typical red flag that points to a plugin crashing.

You'll find that if you split the plugins across two (or more) tracks in that scenario that it fixes it. Just daisy chain route across two tracks.

Hope that helps.

Thanks serr, it could definitely be related to PDC calculations, some great suggestions here. A few of the mix jobs I get sent here are (at least partially) rescue projects that were recorded by clients under sub-par circumstances, so I usually end up reaching for the fancier forensics plugin stuff when doing my thing, which means PDC is often all over the place.

But, and excuse my grave ignorance on the matter, shouldn’t moving all the plugins on the problematic parent folder to a new ”grandparent” folder simply move the problem with it as well, as the plugins are still on one single track? Because in my case, it doesn’t; the grandparent folder track solves the issue!

Leaving just one ”heavier” plugin on the immediate parent track can make the project behave erratically (not always, but often enough), but as soon as it’s moved to the grandparent folder, things are smooth again. And again, the worst and most obvious case is the use of a 2BUSS folder track nesting everything directly underneath, i.e. maybe ”summing” a lot of PDC calculations…? I always leave this one completely free of FX and only use it for volume automation of the entire mix. If I mix into a software compressor or want to do small EQ tweaks on the entire mix, I put that/those plugin(s) directly on the Master Out and there are rarely any problems. Basically, in-between empty folder tracks alleviate the pain and make for smooth mix sessions.

I suppose I’m just wondering if I should get used to the idea of having a bunch of grandparents on my mixes.

Will definitely try daisy-chaining more when the next project comes in, thanks again for the tip!

//Sven

[borg64]

Originally Posted by vanhaze

In Holland too, Long Live Spring !!

Indeed - and woohoo!

//Sven

[vanhaze]

Originally Posted by borg64

Thanks serr, it could definitely be related to PDC calculations, some great suggestions here. A few of the mix jobs I get sent here are (at least partially) rescue projects that were recorded by clients under sub-par circumstances, so I usually end up reaching for the fancier forensics plugin stuff when doing my thing, which means PDC is often all over the place.

But, and excuse my grave ignorance on the matter, shouldn’t moving all the plugins on the problematic parent folder to a new ”grandparent” folder simply move the problem with it as well, as the plugins are still on one single track? Because in my case, it doesn’t; the grandparent folder track solves the issue!

Leaving just one ”heavier” plugin on the immediate parent track can make the project behave erratically (not always, but often enough), but as soon as it’s moved to the grandparent folder, things are smooth again. And again, the worst and most obvious case is the use of a 2BUSS folder track nesting everything directly underneath, i.e. maybe ”summing” a lot of PDC calculations…? I always leave this one completely free of FX and only use it for volume automation of the entire mix. If I mix into a software compressor or want to do small EQ tweaks on the entire mix, I put that/those plugin(s) directly on the Master Out and there are rarely any problems. Basically, in-between empty folder tracks alleviate the pain and make for smooth mix sessions.

I suppose I’m just wondering if I should get used to the idea of having a bunch of grandparents on my mixes.

Will definitely try daisy-chaining more when the next project comes in, thanks again for the tip!

//Sven

Good post !
Me 2 will investigate in more "daisy chaining" plugin chains over multiple Tracks, see how / where it get's me performance wise.

The only thing i noticed that, when moving a big bunch of quite heavy processing plugins from Reaper Master Track onto a Folder Track, which holds all Tracks as Child Tracks, performance is somewhat better (say: less "tearing of sound", due to cpu core overload).
Which i always found logical, knowing that Reaper's Master Track FX Chain doesn't support Reaper's famous anticipative processing.
But i am aware of the fact that, reading all previous posts, this fact could maybe abit offtopic.

[Lokasenna]

Originally Posted by vanhaze

EDIT: I never knew PDC taxes the cpu in a DAW (Reaper) more ; thats vital info for me !

It's definitely not worth ditching a plugin over, but it's useful to know about if you find yourself with some audio glitching. The Performance Window will tell you exactly which tracks are asking for it.

[ferropop]

Any word on this? It's absolutely a problem with PDC, because disabling PDC on the folder fixes the crazy RT CPU use!

[Sekkleman]

I’ve been having similar issues with heavy plugins on parent folder tracks. I’m glad I found this thread as I’ll definitely try the blank parent to grandparent folder track workaround. I’m gonna end up with a heap of extra folders though (one extra for every main group and subgroups) which’ll become pretty insane and messy so hopefully the bug will get sorted... has anyone found a better solution yet?

Im also runnng on win7 PC rather than OSX

[ferropop]

Any updates?

[ferropop]

Still a huge issue

Here are plugins/behaviours I can pin this down to as examples:

1. Nested folders where high-PDC plugins (Oeksound Soothe, Waves GW MixCentric) are on the parent. This *royally sucks* because the whole point of processing large chunks of tracks like this is to save CPU and do "broad strokes" processing, yet it's creating this whole new issue of crackling/RT-CPU spikes. Example: Soothe on a VOX bus.

2. Sends going from one set of nested folders to another. I assume calculating PDC in this situation is probably super complicated, but it's almost unusable in the current state. Example: DRUMS folder with nesting, SYNTHS folder with MixCentric, sending DRUMS(Kick) to SYNTHS 3/4 for sidechain compression.

3. Plugins with Variable PDC, ie ReaPitch. Example: throwing ReaPitch on the SYNTHS bus and automating a pitch-shift creates insane behaviour depending on what's in SYNTHS.

Willing to put in tons of time testing if some of this can be addressed. It unfortunately kills broad-strokes workflow working the way it currently does

[ferropop]

This ultimately came from trying to do the following structure (which I had to stop):

INSTRUMENTAL (FOLDER){ // RECEIVE:VOX(3/4), FabFilter ProMB (3/4), MixCentric

== DRUMS (FOLDER){
==== Kick // SEND:SYNTHS(3/4)
==== Snare...
== }

== SYNTHS (FOLDER){ // RECEIVE;DRUMS(3/4), FabFilter ProC (3/4)
==== Synth 1
==== Synth 2...
== }

== FX (FOLDER){
==== ...
== }

}


VOX (FOLDER){ // SEND:INSTRUMENTAL(3/4), Soothe

== Lead
== Harm
== ...
}


The above was completely unstable. Shedding the big INSTRUMENTAL bus solves this a bit, but the beauty of being able to unmask the Vocals to the entire Instrumental track goes away. Just an example.


tldr: I group INSTRUMENTAL and VOX separate, MultiBand Compress the Instrumental to unmask Vocals. Inside INSTRUMENTAL I sidechain Kick to Synths for sc ducking. Get extreme crackles and RT-CPU usage.

[yophio]

Originally Posted by ferropop

This ultimately came from trying to do the following structure (which I had to stop):

INSTRUMENTAL (FOLDER){ // RECEIVE:VOX(3/4), FabFilter ProMB (3/4), MixCentric

== DRUMS (FOLDER){
==== Kick // SEND:SYNTHS(3/4)
==== Snare...
== }

== SYNTHS (FOLDER){ // RECEIVE;DRUMS(3/4), FabFilter ProC (3/4)
==== Synth 1
==== Synth 2...
== }

== FX (FOLDER){
==== ...
== }

}


VOX (FOLDER){ // SEND:INSTRUMENTAL(3/4), Soothe

== Lead
== Harm
== ...
}


The above was completely unstable. Shedding the big INSTRUMENTAL bus solves this a bit, but the beauty of being able to unmask the Vocals to the entire Instrumental track goes away. Just an example.


tldr: I group INSTRUMENTAL and VOX separate, MultiBand Compress the Instrumental to unmask Vocals. Inside INSTRUMENTAL I sidechain Kick to Synths for sc ducking. Get extreme crackles and RT-CPU usage.

I'm having the exact same problem here.

Bypassing the sidechain send from instrumental folder to vox immediately solves the glitching and heavy rtcpu use. In that situation I also get a really long playback delay; I have to wait almost 10 seconds since I pressed play to hear anything.

I guess the problem exists because Reaper is summing the PDC from every instrumental child track with the vox folder.

I don't know how this can be fixed.

[vanhaze]

This is really awful ..
Hope Cockos can have a look at it.

[Joe90]

Also experiencing this - I believe this is directly related to my issues here -

https://forum.cockos.com/showthread.php?t=225314.

[todoublez]

Originally Posted by borg64

Hey Lokasenna!
It seems more likely to happen with larger projects and more CPU-demanding plugins, especially when there are lots of child tracks and folders underneath.
//Sven

I experienced the same thing here, yeah especially I slam a Acustica plugin,
it gets unstable.

I wonder is this a Mac issue?