Bug??? Excessive RTCPU from feedback routing not reduced when loop eliminated
This really seems like a bug to me. The large RT CPU makes some sense to me, since it must require all kinds of recursion or whatever, but it seems like removing the loop should free up those resources, but it doesn't.
This is a bit of complex project, but not really that bad compared to some things I've done. I'm really not sure how much the specifics matter, but I'll lay it out in case the title doesn't quite explain well enough.
It's for my live band. We've got several tracks for live inputs - record armed and monitoring on. Each of these sends to another track where various FX are applied so that I can actually see the post-FX levels on the meters and those tracks then send to an FOH mix bus track.
We also have a set of tracks with MIDI loops to trigger individual drums. These all send to a track with an instance of SuperiorDrummer which itself sends to the FOH track. Every track in the project has Master/Parent send disabled, I use explicit sends for everything.
Now, I want those drum loops to follow the dynamics of the rest of the band. Each of the midi tracks (usually individual drums) has a receive from one of the instrument "monitor" tracks, and I use a JS plugin and PM to modulate the velocity based on the audio level from that instrument. This is not a feedback loop in any sense of the word and is not the root of the problem. It has worked reasonably well for a couple years now, but I wanted to make it better, and that's where things went a little weird.
What I wanted was for each of the individual drum tracks to also be modulated by the overall mix level so that it would get louder and softer when its assigned instrument did, but that range is limited or scaled down based on the overall mix. As a "first shot" attempt at that, I just sent back from the FOH mix track to the MIDI tracks. This does not create an actual audio feedback loop, but it does create a sort of cyclical dependency and causes the RT CPU usage to skyrocket. Honestly, that's almost expected, and certainly not surprising to me.
What is unexpected is that I can't cure that by removing the receive from the SD (drum audio) track on the mix track. I duplicated that FOH track, deleted that receive on the duplicate (as well as the hardware send, since I didn't want it going out to the world), and that RT CPU stayed high. Muting the sends (back to the MIDI tracks) helped reduce that load, but it still wasn't working right. So I deleted that duplicate, inserted a new track and set it up exactly the same way that it had been except without ever having a feedback loop, and it works the way I expect. RT CPU use is a heck of a lot less. Like, what had been "idling" at 89% dropped to 20%!
By all rights the routing is exactly the same as it had been, the only difference being that this mix track never had the feedback loop involved. So somehow Reaper got upset about that loop and just couldn't get over it, even after I removed it. Even after restarting Reaper/reloading the project, it was still all upset. This feels like a bug to me. If the problem is the feedback, then removing the feedback should fix the problem, but it doesn't.
|