High CPU stress = endless GUI redraws & random 'Copy FX' events.

[DeBased]

This is a very long running problem. Before I bug report this, does anybody else get this on Windows, or is it specific to my setup (maybe certain plugins)?

So, I frequently max out my CPU (96k doesn't help). When it's near to max, Reaper likes to go crazy - very regularly, it will get stuck in a UI refresh loop, when the Reaper UI and open plugin windows keep redrawing themselves over and over. During this time Reaper is unresponsive to mouse or keyboard input (which in fact gives the typical OS warning that the app has stopped responding, and option to close it down). Sometimes if you wait long enough, the UI recovers. Often I have to kill Reaper and reload the latest save/auto-backup.

First, is anybody else seeing this at high CPU load on Windows?

I'm a programmer, so I have a good idea why this happens. There's not enough CPU to process the pending Windows redraw messages, and somehow that causes new redraw messages to get added to the queue before the first redraws have completed, resulting in a horrible redraw loop where nothing responds anymore. It could also be specific plugins causing the refresh loop (because it seems strange that new redraws are generated before the first have completed - could also be a Reaper bug?).

a) It would be great if Reaper could catch this scenario (endless redraws) and just stop the audio engine to reduce CPU which always solves it (the redraws catch up and then it's all fine again). This also happens if the audio engine stops for another reason - but if Reaper is set to never stop the engine, then you can't stop it manually as it no longer responds to input. That's why Reaper should catch this and fix it.

b) the 2nd thing that often happens is that, during the redraw loop, I frequently get random 'Copy FX' actions happening to tracks. I don't do this manually, somehow they just appear on a track. Usually the entire FX chain of one track is added to an unrelated track. I only notice when CPU usage goes through the roof and/or the changed track ends up sounding really weird.

Again I've no idea what causes this, as I definitely don't press CTRL + V during the UI freakouts, nor did I copy the source chain manually at any point. The Undo history shows 'Copy FX' events (usually one or two). So this is somehow a bug caused by the UI freakouts.

Is anybody seeing that part too?

[foxAsteria]

Random actions happening in my experience is usually due to a MIDI device output being enabled when it shouldn't be. If you have the same MIDI device enabled for in and out, sometimes it can create a strange feedback loop that causes unexpected behavior. You can also check the undo history to see which action is getting triggered and then remove the MIDI shortcut from the action in the actions list.

[poetnprophet]

In my experience with Reaper and several other DAWs, the closer you are to max CPU, the more trouble you're going to get in terms of freezes and crashes. As you approach that threshold, simple things like inserting a plugin, having multiple plug windows open AND trying to make an adjustment of the plugin via the gui WHILE playback is happening with all your track peaks onscreen....yes I would expect a crash every single time.

Yes, certain plugins will do this behavior as well. For me, it's Izotope Insight. I don't know why but in Reaper it seems to cause issues....especially when my CPU load is higher.

Also I noticed that some scripts can cause this behavior. Heda's Track Inspector sometimes causes me problems....especially when my CPU load is higher.

I'm not a programmer or even tech savvy, but my advice would be to manage your CPU load better, find what the threshold is for your issues and do what you can to stay below that by freezing/rendering tracks as needed to free up processing.

[DeBased]

Originally Posted by poetnprophet

I'm not a programmer or even tech savvy, but my advice would be to manage your CPU load better, find what the threshold is for your issues and do what you can to stay below that by freezing/rendering tracks as needed to free up processing.

Well sure I do that, but inevitably as I freeze and unfreeze stuff throughout my session (or before I know I need to freeze) I will hit high CPU at various points. So to have the DAW freakout and usually requiring an app kill (with potential recent work loss) isn't nice.

Speaking as a programmer, there is absolutely no reason why a program should crash just because CPU usage is high. What's happening is that the heavy load is revealing bugs that normally don't get triggered, but they are bugs. High CPU should just mean everything slows down, nothing else. (another possible reason is CPU being too overclocked, and overheating at high CPU).

I will have to look through my plugins and scripts to figure out if one of them is causing this. My main plugs are NI Guitar Rig, Kontakt, Slate VCC/VBC, a bunch of Waves and a few Melda, plus some JS scripts (including custom ones).

Problem is there are quite a few others too, and I don't have a reliable trigger for the UI freakout, so tracking it down could take some time. I'm fairly sure it's related to visible plugin windows, as the more I have open, the more often it seems to happen. If Reaper could spot this behaviour, it could also find out which plugin is causing it (if it is a plug) or determine itself if it's a Reaper bug. It should be easy to detect programmatically.

So has anybody seen the redraw loop?

re. the fake 'Copy FX' events, I don't think it's a MIDI device as it doesn't normally happen, I think it's freakout-related, though maybe not. I'll investigate, thanks for the pointer. In the Undo list it's shown as "Copy FX" which doesn't seem to be an action.

[Dr Bob]

Have you tried offloading the cpu use on your master channel?

Insert a new track (eg track 1)., move your FX chain from the Reaper Master channel to this track. Now route all your tracks busses etc to this as if it were the master. (it in turn will be routed to the reaper master by default). Remember to mute any master sends for the routed tracks (to avoid the "double send" issue!!!)

[Can be accomplished in some projects by making the new "master" a folder, and stick everything in that].

Basically you are allowing reaper to spread the master fx over your cpus, rather than running the whole chain on the cpu which is also handling the audio thread. I can typically see the RT Cpu use drop from 14% or so down to 0.3% by doing this (and of course, freeing up cpu at the same time).

This "trick" doesn't always work for everyone, but it might be worth trying. Can be a lot of work for complex projects, but the gain just might be your salvation!

dB

[DeBased]

hey, were both dB .

Originally Posted by Dr Bob

Have you tried offloading the cpu use on your master channel?

Ok this is interesting. I can't see off-hand why running through a replacement master track, rather than directly through the master channel should make any difference. Intuitively, the CPU can't really multi-core that any better than the Master track, as everything is still running through a single pipe just like before, and all the incoming tracks depend on the master (or the replacement track) in the same way.

Are you sure it works? Of course I'd be happy to be wrong.

[Can be accomplished in some projects by making the new "master" a folder, and stick everything in that].

Yes I often almost do that, mainly to have all the tracks I regularly freeze and unfreeze in one folder for convenience, and then just (un)freeze the whole folder. But I still route them through the master FX normally.

[poetnprophet]

Ha, in my first reply I was going ask if you had any processing on the master track, but you seemed experienced and I didn't want to insult, haha. I know how it is when you want an answer and not suggestions on the obvious things you already know.....

anyway, I would be willing to bet that is the issue.
Rule of thumb: NO processing on the master track. I'm not sure why in Reaper the issue is more dramatic, but it is always good practice to have a "pre" or "sub" master track for your (final) processing, and leave the master bare...or analyzers at most.

[DeBased]

Originally Posted by poetnprophet

Ha, in my first reply I was going ask if you had any processing on the master track, but you seemed experienced and I didn't want to insult, haha. I know how it is when you want an answer and not suggestions on the obvious things you already know.....

Very considerate, thanks .

anyway, I would be willing to bet that is the issue.
Rule of thumb: NO processing on the master track. I'm not sure why in Reaper the issue is more dramatic, but it is always good practice to have a "pre" or "sub" master track for your (final) processing, and leave the master bare

I'm not convinced, but I'll try it and report back soon. For mixes I do usually have 2 - 5 things happening on the Master (where I hit the UI freakouts), but none for live stuff.

...or analyzers at most.

I put those in MonFX, that way they don't get printed and don't consume CPU at render time.

[Philbo King]

You probably already know this... but in case you don't:
It is quite possible (easy, in fact) to get Reaper hangs from a JSFX effect that has looping or excess execution time in a high-execution-rate section.

For example code in the @gfx section is executed at a 30 Hz rate. So it's not a good place to put nested loops. Or any loops.

@block and @sample sections also have high execution rates, that depend on the buffer size and the audio sample rate.

So you might try disabling any home-made JSFX and see if your problem stops. Worth a try...

[DeBased]

Originally Posted by Philbo King

You probably already know this...
It is quite possible to get Reaper hangs from a JSFX effect that has looping in a high-execution-rate section.

For example code in the @gfx section is executed at a 30 Hz rate. So it's not a good place to put nested loops. Or any loops.

@block and @sample sections also have high execution rates, that depend on the buffer size and the audio sample rate.

Thanks for the pointer. I don't use loops in @gfx in my own code (just very simple text drawing), and @block and @sample code is usually pretty lean (no loops), but I will check to be sure.

[Philbo King]

Originally Posted by DeBased

Thanks for the pointer. I don't use loops in @gfx in my own code (just very simple text drawing), and @block and @sample code is usually pretty lean (no loops), but I will check to be sure.

It won't cause random FX copying, as far as I know... But external MIDI devices can, as pointed out earlier. (Post #2)

[Dr Bob]

FX on the master track do not have any anticipative processing done on them and so won't get spread across your cpus! Quite a few threads around about this. Also, the audio thread seems to be assigned to the same cpu as that master chain too, so any load on the cpu from the FX will necessarily affect the cpu use - and of course, the audio out will have the highest priority thread and so it can/might affect any heavy master chain fx processing - which in turn can bog lots of things down.

I hear you as an ex-programmer (starting in the mid-1960's!).Tying up the event loop can be an issue. Before PC's, I still did this type of programming in message passing systems, or graphics processors with display lists - the best way to get stuff happening was using smart interrupt routines tied to things like end of raster line, or crt flyback etc.

But, hey, it can be worth a shot moving the master fx chain - surely nothing to lose, and maybe a bit of cpu to gain.

The "original" dB!!

[Dr Bob]

@cliffy - great. It doesn't always work - maybe it's better when you have many cpus? But, clearly, for quite a few people it does work well.

Let's hope it has some effect for the OP.


dB