PLEASE HELP - Apfx causing massive lag on muting/unmuting tracks (FIXED)

[Joe90]

I posted about this previously asking if it's normal behaviour, and a couple of people chimed in basically saying 'yes, annoying isn't it'... but that post was tied in with questions about PDC, and I think this is a separate issue, so I'm posting again with a more clear description, looking for more info -

Here is a blank project with a folder nested four times. Each track (including folders) has 4 x MJUC on it, I chose MJUC because it's widely used and known for not being super CPU intensive, it is on HQ mode, which creates 39 samples of latency. CPU use for the project is at 6%. RT CPU is at 1% (there's no audio, these tracks are empty).



See how slow and inconsistent the muting is? It gets much worse in a heavy project (100-150 tracks, 50% CPU, 2% RT). When I press 'm' to mute, it staggers them very slowly, when I click on the track mute button it is more efficient, they all trigger at the same time, but they're still delayed. In a heavy project, this behaviour is also often accompanied with massive audio stuttering and RT CPU spikes (system and drivers are clean, latencymon results are good), and sometimes a crash if I try and mute/unmute too many tracks at once or too quickly. All of this also applies to soloing. This gif is just an attempt to reproduce this behaviour (which I'm seeing widely across my heavier projects) without so many variables (different vsti's etc) that could be causing the issue. I could recreate this behaviour with any plugin that introduces some latency, it doesn't need to be MJUC. It also doesn't need to be such a deep layer of folders - once a project gets busy with some vocal channels and some live Vsti's you only need to go one or two folders deep, maybe throw a send or two in there, and these issues start appearing. It also makes no difference if 'do not process muted tracks' is ticked or not... that was the first thing I checked.

Unsurprisingly, bypassing all the FX fixes this behaviour (which is what made me think it was related to PDC). However, turning off Apfx globally also completely solves the issue, however it makes Reaper very CPU inefficient compared to other DAW's. It seems like once the Apfx crosses a certain 'threshold' (or maybe it's whenever it kicks in at all - difficult to tell) it just starts causing these lags on anything playback related.

In regards to the more staggered muting when using a keyboard shortcut - When I click on the mute track button then check the last action in the undo list it says 'toggle track mute' but when I mute the tracks by pressing 'm', the last action reads 'adjust track mute (via surface)'. Same for soloing. My 'm' command is assigned to the action 'Track: Toggle mute for selected tracks'. I believe this has something to do with the very slow staggering of the muting/soloing compared to clicking on the button, and is hopefully something someone can help with.

So - there are two problem at play here -

1. The slower staggered mute/solo response when using a keyboard shortcut instead of clicking. (I'm hoping this an issue that just I'm having, and can be easily rectified)

2. The general slowdown created by the way Reaper handles Apfx and PDC in complex routing situations. The most frustrating thing is that this seems largely unrelated to CPU - in this test project I'm still getting all these issues with tiny amounts of CPU use - I'd understand if the RT CPU was very high, bottlenecking one core or something, but it's not... the CPU juice is there but Reaper is not using it. You could argue that it IS related to CPU because if I had a powerful enough PC to run large projects WITHOUT Apfx then it would be fine - I don't if anyone has tried working up a full production with Apfx off - but it really does make Reaper very CPU inefficient compared to anything else out there.

Please see this thread to see what I've tried and tested already in relation to this issue - https://forum.cockos.com/showthread.php?t=225314

I believe the issues described in this thread are also related - https://forum.cockos.com/showthread.php?t=188157

If it transpires that this really is a core reaper issue then I guess that's my Reaper journey coming to end for now, which will be such a shame. I'll be watching closely and campaigning to get it sorted though as I love this DAW (and I've already sunk in a fair bit of time and money into it before this issue reared it's ugly head). As I mentioned in my other thread, I really hope I can sort this as using my other DAW's now feels like dragging my feet through sand compared to how I've get Reaper running that it's set up and tweaked to my liking, but once it starts lagging like this then it's just unusable for me.

The mute button is one of the most important tools a writer/produced has in their arsenal, and I mean that 100% seriously... Pop music especially is all about trimming the fat, and I'm constantly muting and unmuting certain parts - seeing how it makes space for other parts and re-assessing if they are needed or not. This laggy glitching behaviour makes this so painful. When any other DAW gets bogged down with a heavy project (and they have their own set of issues in these situations, trust me I know) muting and soloing is ALWAYS still responsive, and doesn't cause audio glitches. Bear in mind I'm getting these audio glitches on muting/unmuting a track in a heavy project even if that track is EMPTY with no FX and not routed to anything! It's inconsistent too - sometimes (rarely) it will react straight away, but I can always get it to glitch in a heavy project by just muting/unmuting the track quickly and repeatedly - again this is a totally empty track... it's almost like the Apfx buffer gets 'overflowed' causing a RT spike when muting/unmuting too many tracks, or too rapidly - again this is exactly the same whether 'do not process muted tracks' is ticked or not. The only thing that makes a solid reliable difference to the responsiveness is turning off Apfx, but as I said, this is not an option for a heavy project. It's definitely not purely related to PDC as I originally suspected - as I can open a fresh project, run like 10-15 linear phase EQ's on one track, stacking up a ridiculous 50,000 total PDC for that track, and the playback and response is still snappy (astonishingly so compared to other DAW's).

The ability to Mute/Solo tracks as responsively as possible should be CORE to every DAW as far as I'm concerned, so I'm amazed that there aren't more people talking about this - hopefully I've missed something and someone can help me out. I understand there is a core latency between pressing any button and hearing the result that is unavoidable, and dictated by a number of variables. However, this is much more than just basic playback latency caused by PDC (even taking into account the oddly inefficient way that Reaper stacks plugin PDC with a whole buffers worth of PDC per plugin - a third party chainer used WITHIN reaper handles PDC better than reaper does natively).

[Joe90]

BUMP

Realise it's a long post so here's a TL DR - Apfx is causing muting/unmuting tracks to be very laggy and glitchy on heavy projects, and it's even worse when using a keyboard shortcut than when clicking the mute button.

[lclyman]

What happens if you un-nest all the tracks...in other words, don't use folders? That would eliminate folders as the issue.

LC

[Justin]

If you could provide the following we would be happy to take a look:

1) Provide the OS version and REAPER version
2) A simplified project that duplicates this. If you could get it to do it using ReaVerb or ReaFIR or another built-in plug-in this would make it easier. If not, a freely available plug-in.
3) Does it do it with a fresh REAPER portable install? If not, can you provide a reaper.ini that duplicates?
4) Can you provide the exact action ID that is being used to trigger the mute/unmute?

As far as the comments about performance issues when unmuting tracks -- there is an option in the preferences called "do not run muted tracks". If you disable this, it will prevent those performance issues when unmuting (though it raises the CPU use of muted tracks...)

[Joe90]

Originally Posted by Justin

If you could provide the following we would be happy to take a look:

1) Provide the OS version and REAPER version
2) A simplified project that duplicates this. If you could get it to do it using ReaVerb or ReaFIR or another built-in plug-in this would make it easier. If not, a freely available plug-in.
3) Does it do it with a fresh REAPER portable install? If not, can you provide a reaper.ini that duplicates?
4) Can you provide the exact action ID that is being used to trigger the mute/unmute?

As far as the comments about performance issues when unmuting tracks -- there is an option in the preferences called "do not run muted tracks". If you disable this, it will prevent those performance issues when unmuting (though it raises the CPU use of muted tracks...)

Hi Justin,

Thanks so much for your reply! Despite my slight moaning and questions all over this forum, I have to say you have created an incredible DAW here!

Windows 10, 1903, all up to date. It's a fast PC, tuned for Asio Performance.

I'm using the latest dev build (5.982+dev1002/x64), however I've observed the exact same behaviour with the standard version too.

Interface is an RME Fireface UCX, but I'd be surprised if that's relevant to this issue.

Yes I can replicate it with a fresh portable install and reaFIR only, however I did have to load a bunch more of them in order to recreate the behaviour (I suspect because they are a much lighter hit on the CPU than MJUC in HQ mode and therefore lighter on the Apfx too) -

Gif 1 shows a project with 20 tracks, containing two large nested folders 5 layers deep, each track has 13 instances of ReaFIR. I'm hitting 'm' which is assigned to the problem mute action (action number and name are detailed below). You can see the CPU instantly spike, and the staggered behaviour. Any other method of muting the track (by clicking on the mute button, or by a different action) does not stagger, it's only delayed by the PDC of the project (again, as expected). You can see when I turn off Apfx the staggered muting stops happening. However when I turn off Apfx you can see the real time CPU is still very high (not sure why as there is no actual audio being processed). I realise the PDC is very high in this project (understandably with all the ReaFIRs) but I can recreate this behaviour with third party plugins at much lower PDC totals, so I'm pretty sure that the PDC is not the cause of this.

https://media.giphy.com/media/UUhERR...PUez/giphy.gif

I removed some of the tracks from the top folder to lower the overall RT CPU load, and made a second gif, here you can see the overall project is sitting at a steady and low CPU use, then the track muting causes a stagger and a spike, then it comes back down, you can also see in this gif how it will work intermittently, before lagging again.

https://media.giphy.com/media/H566Xt...MHhi/giphy.gif

The action ID that is causing the staggering mute behaviour is '6'... that feels like I've made an error, but it really is action number '6'. The action is named 'Track: Toggle mute for selected tracks' in the action menu, but after using it, it shows up in the undo list as 'Adjust track mute (via surface)'.

Regarding the audio glitches when muting/unmuting tracks (even when said tracks are empty/unrouted) - The 'Do not process muted tracks' checkbox unfortunately makes no difference, it was one of the first things I checked. The function itself is working as expected (I can see the CPU lowering when muting a bunch of heavy tracks only when this option is checked, as expected) but it doesn't help with this spiking/glitching issue when muting/unmuting tracks. Just to be clear - this is not only happening with the specific mute action that is causing staggering for me, it happens even when clicking on the mute button in the TCP. The only way I've found to reliably stop it is to disable Apfx globally.

https://stash.reaper.fm/37288/Reaper...r%20Justin.rpp

This project and the gifs were created with a totally default install, except I assigned the 'm' button to action number 6.

Edit: I thought I should include - I was running at a buffer size of 96 samples for this test project. If I bring the buffer up to 1024 I still see the staggered muting, but not the spikes, if I then duplicate the top folder of tracks a few times just to work the CPU/Apfx a bit harder and go back to muting those bottom tracks again, I can see it start to happen again - I believe this may be related to an Apfx 'threshold' that, once crossed, starts causing these issues for me.

[lclyman]

Originally Posted by Justin

As far as the comments about performance issues when unmuting tracks -- there is an option in the preferences called "do not run muted tracks". If you disable this, it will prevent those performance issues when unmuting (though it raises the CPU use of muted tracks...)

Justin...I had no idea this option existed as I've used many other DAWs and mute specific options were not available as far as I knew.

CPU usage is rarely a problem since upgrading my computer, so disabling that mute preference essentially eliminated my previously mentioned mute/unmute problems. Workflow now is more of what I'm used to.

Thanks and keep those gems coming,
LC

[Joe90]

Originally Posted by lclyman

Justin...I had no idea this option existed as I've used many other DAWs and mute specific options were not available as far as I knew.

CPU usage is rarely a problem since upgrading my computer, so disabling that mute preference essentially eliminated my previously mentioned mute/unmute problems. Workflow now is more of what I'm used to.

Thanks and keep those gems coming,
LC

That's interesting - are you positive? Have you checked with a really heavy project? I only ask because it definitely doesn't help for me, if I load up a heavy project I still get the skipping/glitching on muting and unmuting a track even with this option unchecked. It definitely works as described, it just doesn't help with the glitching. If it is definitely working for you then hopefully this means it's something I can fix in my setup too.

Regarding your other question about nesting/unnesting, yes it definitely helps if I un-nest everything, but if I just duplicate the unnested tracks a few times I can see the behaviour pop back up, so it's not purely related to folder status, complex routing just seems to exacerbate it.

[lclyman]

Originally Posted by Joe90

That's interesting - are you positive? Have you checked with a really heavy project? I only ask because it definitely doesn't help for me, if I load up a heavy project I still get the skipping/glitching on muting and unmuting a track even with this option unchecked. It definitely works as described, it just doesn't help with the glitching. If it is definitely working for you then hopefully this means it's something I can fix in my setup too.

There's no question the mute/unmute is much smoother w/o those annoying stutters and crackles. This particular project has 60+ tracks but more importantly 15 busses that are all loaded with multiple high cpu and latency inducing plugins (nebula, acqua, 3rd party algo heavys, etc.). Over all this project has 114 fx, total CPU of 51%.

My typical muting/unmuting is when I'm checking parallel processing and ambience/effects levels on various busses and efx sends, but track and folder mutes are not uncommon. Your track counts would appear to be higher than mine typically are (60-80 tracks), so perhaps in a project twice this size I might have a different outcome. But as I've said, for my typical work flow, this latest change has made a big difference.

[Justin]

Thanks -- we can improve the performance of that action (6)... as far as the overall performance issues described, that will have to wait for another day

[Joe90]

Originally Posted by Justin

Thanks -- we can improve the performance of that action (6)... as far as the overall performance issues described, that will have to wait for another day

That's awesome news about improving that specific action - much appreciated Justin!

Regarding the other performance issues discussed - I totally understand, hopefully it's now 'on the list' so to speak, and to be honest I just appreciate the correspondence. Reaper feels so much more fluid to me now than my other DAW's (one of which I've used full time for 15 years) that I will just work around this issue for now until it's hopefully sorted. FWIW - to me it feels like the Apfx track muting spike issue is tied in with overall issues you've previously referenced regarding CPU strain on complex routing when PDC starts stacking up... I guess all these functions affect each other in many subtle ways, and I'm sure it's a delicate balancing act on the programming side.

Perhaps there's something about my system that exacerbates this issue, as I find it surprising that there is so little talk about it here - so if there's ever anything I can do to help with testing then please feel free to reach out.

I suspect it won't be the last you hear of this issue, as I think you are going to see a lot more users coming in from other DAW's over the next few years, and in my humble opinion this is one of the last hurdles remaining that could hold someone back from making the jump.

The thing is... thanks to the hard work of you and your team and the amazing script writers on this forum, Reaper has crept up as the dark horse of DAW's in the last few years, growing from the reputation of 'cheap, reliable, no-frills alternative for straightforward audio recording/mixing' into a fully fledged producers/composers DAW, with most of the best functions from other DAW's, plus a bunch more that other DAW's don't even seem to even consider (even simple no brainers like 'move active floating FX window to mouse cursor' - so simple, but SO useful on a multi-monitor setup!).

Many people aren't aware how much it's grown though, partly because you update so often and partly because some of these new features are not native scripts. Plus when you do introduce a new feature natively you don't make a song and dance about it, so if you're not on this forum it's unlikely you'll know about it. However... word of mouth is travelling, and it's saying 'Oh, your DAW can't do that? Try Reaper'

[foxAsteria]

This is a huge problem for me when using SWS toolbar solo/mute buttons or scripts such as Hackey Machines.

Even with the new dev versions addressing these issues, in an otherwise responsive project with CPU and RT CPU below 50%, it can cause several minutes (really) of stuttering and total unresponsiveness if I use them during playback.

It's often faster to forcibly crash the project and reload the backup than to wait it out.

[poetnprophet]

hello, i have also experienced this many times as my projects become more complex. I have the mute thing disabled in prefs already. It is particularly noticeable when high pdc tracks have sends/returns, muting anything with a send or a receive will cause some slight glitching and/or slight lag in actions. So, plugin mgmt has been my workaround, and I try to avoid plugins with high pdc whenever possible. For instance, the free Proximity EQ by Sonible will glitch any project at any stage with a crazy high pdc (20,000+ samples). then if I try to mute/solo that track or any track it's sending to, glitch city. Even though my cpu is at maybe 30-40%.

[serr]

FYI, there's a preference setting for "Muted tracks take no CPU time" in the Preferences/Audio page. With this enabled, muting a track removes it from being processed which leads to the entire mixing board recalculating PDC. That PDC "reshuffle" results in mad dropouts for that moment and you hear clicks and pops for a moment.

That mode makes the mute buttons more like channel on/off that aren't to be used or automated during the mix. Untick that box and PDC stays calculated for all channels and you can work the mute buttons.

Not sure if this is related but FYI if it is.

[foxAsteria]

Originally Posted by serr

FYI, there's a preference setting for "Muted tracks take no CPU time" in the Preferences/Audio page.

Thanks, but it has no effect on the problem for me. Just wish that Reaper would recognize it can't handle playback while processing the request and actually stop first, instead of glitching out for several minutes.

[Joe90]

Originally Posted by foxAsteria

Thanks, but it has no effect on the problem for me. Just wish that Reaper would recognize it can't handle playback while processing the request and actually stop first, instead of glitching out for several minutes.

Same here - makes no difference, it was the first thing I checked.

Poet n Prophet - It's not purely related to PDC, but it definitely seems like a factor. The reason I say that is I can get a minimal project going and stack up a bunch of instances of Pro Q in linear phase mode, building up a ridiculous level of PDC - like 50,000, and there are no signs of this issue (Reaper actually remains amazingly responsive in this scenario, compared to other DAWs). If I was to then push the CPU on that project I would start seeing issues though, I'm guessing whenever Apfx starts to 'kick in' (that is pure speculation though, I have no idea how Apfx is working in the backgroud). Further to this, turning off Apfx ALWAYS fixes it for me, including the RT spikes you can get from muting/unmuting tracks - so that seems to be the main culprit as far as I can tell.

If you are having other issues with PDC then a workaround is to use a chainer like bluecats 'patchwork', which will add up all the contained plugins PDC correctly, instead of creating a whole buffers worth for each plugin, which is what Reaper does. It's no help for a single plug-in with a really high PDC though.

If anyone reading this is having issues with staggered muting/soling like I have then this has been my fix - I've switched out action #6 for action #40280, which literally seems to do the exact same thing but without the staggering (quite odd but at least that is fixed) I still get the RT spike issues when muting/unmuting on heavy projects though, that seems to be a separate issue. Unfortunately there is no replacement I've found for the 'solo' action like there was for the mute action, but I've switched out the stuttering solo action (#7) for the action 'me2beats_Toggle exclusive solo for selected tracks.lua' which as you can probably guess is technically an exclusive solo not a standard one, but it works fine for my needs and at least I don't have the staggering anymore.

Edit - There is actually a fix for the stuttering solo action #7 - replace it with action #40281 -'Track: Solo/unsolo tracks. Thanks to Stevie for pointing it out.

[Joe90]

It's odd that the 'do not process muted tracks' option seems to be helping with this for some people, but not others... Iclyman reported earlier in this thread that it was helping for him too.

I've tested the function and it's definitely working for me as described, when it's checked I can see the CPU meter drop when muting a bunch of heavy tracks, and when I do the same with it unchecked I can see the CPU doesn't change, so the function itself is working, it's just not helping with the RT spikes on muting/unmuting in heavy projects.

Serr - just to clarify, does checking this option definitely makes a difference for you with the RT spikes on muting/unmuting, or are you just not experiencing those full stop?

[serr]

Yeah, it works exactly as expected. But I'm audio only. Sometimes 100's of tracks but audio only. I don't work with the MIDI instrument plugins and all that.

Sounds like that variable has been ruled out and something else is going on here.

[Joe90]

Thanks for clarifying Serr. I don't think VSTi's are the cause, although I expect they could exacerbate the issue. I only say this as I've recreated this behaviour with a portable install, using a blank project with no audio or midi, just some nested tracks with lots of ReaFIRs on them.

Feel free to give the project a try if you get a chance, I'd be curious to see whether you still get the RT spikes at your end or not, and whether the ' do not process muted tracks' checkbox still makes a difference. You might need to delete some of the tracks or add more depending on your CPU speed, I was testing it on a fast CPU at 1024 buffer size.

https://stash.reaper.fm/37288/Reaper...r%20Justin.rpp

Perhaps there's another performance setting that FoxAsteria and I are both using that is somehow affecting the 'do not process...' checkbox behaviour... however this would surprise me, as this test project was made with a fresh portable install.

Having said all this - I can recreate this behaviour in a heavy project by muting/unmuting an empty track with no FX, that is routed nowhere... this suggests that this checkbox might no be the answer to this issue anyway, but who knows.

[Joe90]

Originally Posted by foxAsteria

Thanks, but it has no effect on the problem for me. Just wish that Reaper would recognize it can't handle playback while processing the request and actually stop first, instead of glitching out for several minutes.

This seems to be fixed for me in the latest pre-release dev version (5.984 dev1027).
I'm also not seeing the realtime spikes on muting/unmuting. It's still a bit laggy on heavy projects (maybe a touch more so than before, not sure), but no more skipping/glitching audio for me. They didn't mention anything about fixing it, but they seem to have done something... haven't done extensive testing yet though, just thought I'd let you know, curious to see if it works for you too.

[foxAsteria]

@Joe90 - Yea I was testing a dev version. It wasn't helping me tho. My problem could be related to something else.

Just tested the latest and in my most problematic project, it still takes several minutes to unmute even a single track via sws toolbar mute action or hackey trackey script. This occurs when stopped with CPU and RTCPU under 30%. Highest PDC track is 1280.

[Gianlorenzo Mungiovino]

Hi you guys, it seems I've found a solution to these mute/solo weird issues:
Just create two cycle actions with the same "SWS: Toolbar mute toggle" action and now it works properly without any lag. Do the same with solo sws action.
I really don't know why using these two actions as cycle's avoids the lags.
I've tried in a 64 tracks project with fabfilter pro q3 in maximum linear phase mode (an instance for each track).
RT cpu spikes unfortunately are still there, but I must say the load in this scenario is pretty heavy... but now seems we can say goodbay to several minutes lag as we faced before.
I hope this fix can help.

Bye

[Joe90]

Gianlorenzo could you explain how you made this cycle action? I'd like to try it to see if it helps.

[Gianlorenzo Mungiovino]

Originally Posted by Joe90

Gianlorenzo could you explain how you made this cycle action? I'd like to try it to see if it helps.

Hi Joe, Here what I've done:

I simply created a sws cycle action with the only "SWS: Toolbar mute toggle" action (see the picture attached).

After that I customized my side toolbar adding a new button with the mute icon that trigger the cycle action created before (see the other picture again).

By doing so, and adding the solo button too, I've recreated the Logic Pro sidebar; now whenever you'll check (or uncheck) these buttons, you'll turn on (or off) every already muted or soloed existing tracks.