|
|
|
02-19-2017, 08:44 AM
|
#1
|
Human being with feelings
Join Date: Aug 2011
Location: Stockholm, Sweden
Posts: 75
|
FX on folder tracks more CPU demanding?
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
|
|
|
03-24-2017, 08:50 PM
|
#2
|
Human being with feelings
Join Date: Mar 2017
Posts: 11
|
5.35 and 5.40 version better with cpu and plugins like SLATE DIGITAL 32bit handles better on my el capitan
|
|
|
03-25-2017, 01:22 AM
|
#3
|
Human being with feelings
Join Date: Jul 2012
Location: Netherlands
Posts: 5,247
|
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 ..
Quote:
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
|
|
|
|
03-25-2017, 06:43 PM
|
#4
|
Human being with feelings
Join Date: Aug 2011
Location: Stockholm, Sweden
Posts: 75
|
Quote:
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
|
|
|
03-25-2017, 06:53 PM
|
#5
|
Human being with feelings
Join Date: Aug 2011
Location: Stockholm, Sweden
Posts: 75
|
Quote:
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
|
|
|
03-26-2017, 07:34 AM
|
#6
|
Human being with feelings
Join Date: Jul 2012
Location: Netherlands
Posts: 5,247
|
I gotcha, well explained.
Would be nice if we could get official Cockos statement / clearification about this.
|
|
|
03-26-2017, 12:35 PM
|
#7
|
Human being with feelings
Join Date: Sep 2008
Location: Calgary, AB, Canada
Posts: 6,551
|
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.
|
|
|
03-26-2017, 01:49 PM
|
#8
|
Human being with feelings
Join Date: Jul 2015
Location: Stockholm, Sweden
Posts: 1,344
|
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).
|
|
|
03-27-2017, 05:47 AM
|
#9
|
Human being with feelings
Join Date: Aug 2011
Location: Stockholm, Sweden
Posts: 75
|
Quote:
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
|
|
|
03-27-2017, 05:49 AM
|
#10
|
Human being with feelings
Join Date: Aug 2011
Location: Stockholm, Sweden
Posts: 75
|
Quote:
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
|
|
|
03-27-2017, 08:24 AM
|
#11
|
Human being with feelings
Join Date: Sep 2010
Posts: 12,632
|
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.
|
|
|
03-27-2017, 09:13 AM
|
#12
|
Human being with feelings
Join Date: Apr 2010
Location: Cloud 37
Posts: 1,071
|
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}
|
|
|
03-27-2017, 10:03 AM
|
#13
|
Human being with feelings
Join Date: Sep 2010
Posts: 12,632
|
Quote:
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.
|
|
|
03-27-2017, 01:05 PM
|
#14
|
Human being with feelings
Join Date: Jul 2012
Location: Netherlands
Posts: 5,247
|
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.
|
|
|
03-27-2017, 01:37 PM
|
#15
|
Human being with feelings
Join Date: Jul 2015
Location: Stockholm, Sweden
Posts: 1,344
|
Quote:
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.
|
|
|
03-27-2017, 01:37 PM
|
#16
|
Human being with feelings
Join Date: Jul 2015
Location: Stockholm, Sweden
Posts: 1,344
|
Quote:
Originally Posted by borg64
Also: awesome weather we’re finally having in Stockholm!
//Sven
|
Indeed!=))
|
|
|
03-27-2017, 01:44 PM
|
#17
|
Human being with feelings
Join Date: Jul 2012
Location: Netherlands
Posts: 5,247
|
In Holland too, Long Live Spring !!
|
|
|
03-27-2017, 01:44 PM
|
#18
|
Human being with feelings
Join Date: Sep 2008
Location: Calgary, AB, Canada
Posts: 6,551
|
Quote:
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.
|
|
|
03-27-2017, 02:19 PM
|
#19
|
Human being with feelings
Join Date: Sep 2010
Posts: 12,632
|
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.
|
|
|
03-27-2017, 02:34 PM
|
#20
|
Human being with feelings
Join Date: Jul 2012
Location: Netherlands
Posts: 5,247
|
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 !
|
|
|
03-27-2017, 02:50 PM
|
#21
|
Human being with feelings
Join Date: Aug 2011
Location: Stockholm, Sweden
Posts: 75
|
Quote:
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
|
|
|
03-27-2017, 02:50 PM
|
#22
|
Human being with feelings
Join Date: Aug 2011
Location: Stockholm, Sweden
Posts: 75
|
Quote:
Originally Posted by vanhaze
In Holland too, Long Live Spring !!
|
Indeed - and woohoo!
//Sven
|
|
|
03-27-2017, 02:59 PM
|
#23
|
Human being with feelings
Join Date: Jul 2012
Location: Netherlands
Posts: 5,247
|
Quote:
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.
|
|
|
03-27-2017, 05:47 PM
|
#24
|
Human being with feelings
Join Date: Sep 2008
Location: Calgary, AB, Canada
Posts: 6,551
|
Quote:
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.
|
|
|
10-18-2017, 10:32 AM
|
#25
|
Human being with feelings
Join Date: Jan 2016
Location: Los Angeles, CA
Posts: 3,127
|
Any word on this? It's absolutely a problem with PDC, because disabling PDC on the folder fixes the crazy RT CPU use!
|
|
|
05-12-2018, 04:47 AM
|
#26
|
Human being with feelings
Join Date: Mar 2017
Posts: 36
|
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
|
|
|
10-12-2018, 02:48 PM
|
#27
|
Human being with feelings
Join Date: Jan 2016
Location: Los Angeles, CA
Posts: 3,127
|
Any updates?
|
|
|
04-11-2019, 01:22 PM
|
#28
|
Human being with feelings
Join Date: Jan 2016
Location: Los Angeles, CA
Posts: 3,127
|
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
|
|
|
04-11-2019, 01:37 PM
|
#29
|
Human being with feelings
Join Date: Jan 2016
Location: Los Angeles, CA
Posts: 3,127
|
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.
Last edited by ferropop; 04-11-2019 at 01:44 PM.
|
|
|
04-24-2019, 03:42 PM
|
#30
|
Human being with feelings
Join Date: Mar 2013
Posts: 9
|
Quote:
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.
|
|
|
04-25-2019, 11:05 AM
|
#31
|
Human being with feelings
Join Date: Jul 2012
Location: Netherlands
Posts: 5,247
|
This is really awful ..
Hope Cockos can have a look at it.
|
|
|
11-26-2019, 03:53 AM
|
#33
|
Human being with feelings
Join Date: Aug 2019
Location: beijing
Posts: 612
|
Quote:
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?
|
|
|
09-23-2021, 06:52 AM
|
#34
|
Human being with feelings
Join Date: Aug 2019
Location: Forest City
Posts: 336
|
This is not the most recent of threads, but I ran into the same issue only recently, using mSpectralDynamics (MSD).
I had the idea to reduce CPU load and simplify routing by structuring projects under two main folder Tracks, one for Vocals and one for Instruments then side chain the vocals to the instruments folder with mSpectralDynamics on thus ducking everything vocal on the instrumentsfolder.
Both folders contain many subfolders and child tracks, like all background vocal tracks or even more in the Instrumentfolder like Drumbus, Kickbus, snare Bus, Bassbus, Guitar busses etc.
The result is major glitching/stuttering on playback wich stops immediately if the plugin is bypassed. (The glitching is not dependend on the mode the plugin is in, as soon as it is switched on, even in modes without side chain or if the side chain is disabled, glitching occurs. Only bypassing the plugin helps)
I tried using a (mix)bus between the main folders and the master but it did not resolve the issue.
I haven´t tried the PDC splitting or the "grandparents" folder mentioned in this here thread yet, but I will (as soon as I understand what they actually mean).
If anyone has any update on this, I would be grateful to hear about it.
|
|
|
09-23-2021, 08:48 AM
|
#35
|
Human being with feelings
Join Date: Jul 2009
Posts: 1,231
|
There's an open bug thread on this issue here: https://forum.cockos.com/showthread.php?t=241308
Reproducing the bug and posting about it in that thread might help get the attention of the developers.
|
|
|
09-23-2021, 08:57 AM
|
#36
|
Human being with feelings
Join Date: Jan 2016
Location: Los Angeles, CA
Posts: 3,127
|
Quote:
Originally Posted by WaveTrans
This is not the most recent of threads, but I ran into the same issue only recently, using mSpectralDynamics (MSD).
I had the idea to reduce CPU load and simplify routing by structuring projects under two main folder Tracks, one for Vocals and one for Instruments then side chain the vocals to the instruments folder with mSpectralDynamics on thus ducking everything vocal on the instrumentsfolder.
Both folders contain many subfolders and child tracks, like all background vocal tracks or even more in the Instrumentfolder like Drumbus, Kickbus, snare Bus, Bassbus, Guitar busses etc.
The result is major glitching/stuttering on playback wich stops immediately if the plugin is bypassed. (The glitching is not dependend on the mode the plugin is in, as soon as it is switched on, even in modes without side chain or if the side chain is disabled, glitching occurs. Only bypassing the plugin helps)
I tried using a (mix)bus between the main folders and the master but it did not resolve the issue.
I haven´t tried the PDC splitting or the "grandparents" folder mentioned in this here thread yet, but I will (as soon as I understand what they actually mean).
If anyone has any update on this, I would be grateful to hear about it.
|
I do this exact same thing and get the exact same behaviour.
It really does make sense unfortunately. Your instrumental bus is probably littered with hundreds of plugins which internally might even have their own parent-child dependencies, and same goes for the Vocal bus. To then send Vocals to the Instrumental sidechain and it remain in sync, the highest sum of PDC is what the whole situation now depends on. If there's even a single plugin that doesn't play nice in this super complex setup, the whole thing goes kaput.
That said, the list of plugins that really misbehave is pretty specific. Soothe2 (unfortunately) doesn't do well, even though it is an unreal "broad strokes" high-cpu plugin that makes sense to save for busses.
Have yet to find a solution - ended up building a brand new PC with the most maxed-out possible specs to deal with this, and still come across the issue - albeit much less frequently.
|
|
|
09-23-2021, 10:12 AM
|
#37
|
Human being with feelings
Join Date: Sep 2010
Posts: 12,632
|
I think PDC related buggy plugins combined with complex subgroup routing can throw a wrench into things. I have one ringer that I continue to stubbornly use: Soundtoys Decapitator. It reports it's PDC incorrectly and that's the first sign of trouble. It's just crashy. If I have a session with 300 tracks or more (including busing, etc), I know I'll have a better time if I render any distortion processed tracks and offline that thing right away. (Of course I put a negative time adjuster on it to correct the errant PDC to put it in sync for parallel use. That probably helps put the system on blast.)
Performance meter and Activity Monitor are your friends here. If you have audio dropouts but your system is far from being pushed, you have a buggy plugin. Don't go desperately spending money on some over powered video processing system only to find it won't make the slightest difference.
Just for perspective...
You'd never have complex routing like this in Protools or other DAWs. It would bring those systems to their knees! You'd have to split up larger projects into sub-projects. Problems only really come out in Reaper when you're already doing ten times the tracks and routing that any other DAW would let you get away with. That's my experience anyway.
|
|
|
09-23-2021, 02:18 PM
|
#38
|
Human being with feelings
Join Date: Jul 2009
Posts: 1,231
|
Quote:
Originally Posted by serr
If you have audio dropouts but your system is far from being pushed, you have a buggy plugin. Don't go desperately spending money on some over powered video processing system only to find it won't make the slightest difference.
Just for perspective...
You'd never have complex routing like this in Protools or other DAWs. It would bring those systems to their knees! You'd have to split up larger projects into sub-projects. Problems only really come out in Reaper when you're already doing ten times the tracks and routing that any other DAW would let you get away with. That's my experience anyway.
|
This is not true. It doesn't matter what plugin you use. It just has to be plugins with larger latencies, as I've demonstrated here: https://forum.cockos.com/showthread.php?t=241308
Regarding complex routing, this is not the case either. I can route things exactly the same, but NOT use the master/parent sends, and not run into these issues. There's something weird/buggy about master/parent sends and latency inducing plugins.
|
|
|
09-24-2021, 03:09 AM
|
#39
|
Human being with feelings
Join Date: Aug 2019
Location: Forest City
Posts: 336
|
Thanks for your replies! Most welcome!
Thanks to the information you provided I was able to test a bit more.
To find plugins potentially involved, I disabled one after the other (FX bay makes this very easy) until playback was normal again.
However, the only plugin that made a difference was mSpectralDynamics; bypassing it helped, only removing the side chain did not.
All other plugins only seem to contribute to the overall load, so if a certain amount was bypassed, playback was reconstituted.
I further tested the master/parent send and re-did all routing with M/P send ticked off. This helped to a certain extent. When I re-activated half of the bypassed plugin load, playback was normal even with mSpectralDynamics switched on, when I increased the load by activating all plugins in the project, the RT Cpu was again over 100%, peaking at about 120%. This is actually an improvement to the 150-180% before.
And, again, bypassing mSpectralDynamics resolved the issue, bringin RT CPU under 100% again (contstant 96%).
I also tried Pro-Q3 with sidechained dynamics in the exact position/folder where mSpectralDynamics stalls playback but with Pro-Q3 everything works just fine.
I interpret this, that the playback stalling is not only caused by folders/routing/MP sends but due to something to do with mSpectralDynamics.
Since mSpectralDynamics is central to the issues, I also contacted Melda support.
They require a minimal project to demonstrate this effect but I found it impossible to achieve the required RT CPU overload using only Melda and Reaper stock plugins.
For this reason any suggestions how to increase the RT CPU/PDC load in a simple manner would be very welcome.
I tried with long reverbs and Reacomp with pre-comp maxed but it is still not enough to stall playback as in a real project, even though, switching mSpectralDynamics on radically increases and bypassing it decreases RT CPU.
Last edited by WaveTrans; 09-24-2021 at 03:16 AM.
|
|
|
09-24-2021, 12:23 PM
|
#40
|
Human being with feelings
Join Date: Jul 2009
Posts: 1,231
|
Quote:
Originally Posted by WaveTrans
For this reason any suggestions how to increase the RT CPU/PDC load in a simple manner would be very welcome.
I tried with long reverbs and Reacomp with pre-comp maxed but it is still not enough to stall playback as in a real project, even though, switching mSpectralDynamics on radically increases and bypassing it decreases RT CPU.
|
Try just using more instances of latency inducing plugins. Duplicate tracks if you have to.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 04:12 AM.
|