Do not process muted tracks STOPPED WORKING

[akademie]

"Do not process muted tracks" option stopped working in later pre- and dev- releases.
Muted tracks still consume CPU!

Bug Report here:
Do not process muted tracks STOPPED WORKING

... also mentioned in the "v7.0pre9 - August 17 2023" thread here:
REAPER Pre-Release Discussion > v7.0pre9 - August 17 2023

[sockmonkey72]

Originally Posted by akademie

"Do not process muted tracks" option stopped working in later pre- and dev- releases.
Muted tracks still consume CPU!

Bug Report here:
Do not process muted tracks STOPPED WORKING

... also mentioned in the "v7.0pre9 - August 17 2023" thread here:
REAPER Pre-Release Discussion > v7.0pre9 - August 17 2023

This is working for me on macOS in a basic case (heavy synth plugin on 10 tracks), do you have a simple example of it not working?

[mschnell]

If verified this definitively needs a fix !

[akademie]

Well, by further quick inspection (but now in Linux with v6.81+dev0730) it seems that it depends on opened tracks FXChain window !!!

- fresh portable install (set audio device)
- blank new project, view Performance meter
- add track and insert e.g. Tone Generator JSFX, FXChain is visible, Perf.meter shows Track 1 = 1.3 percent
- MUTE track, no change
- close the FXChain window, then within 1-2 seconds the CPU usage drops to 0.0 percent in Perf.meter
- open the FX window and CPU is again at 1.3 percent

[sockmonkey72]

  * Includes feature branch: always running non-bypassed FX when the UI is visible

Probably because of this? Some plugins might not update their interfaces if they are not running, which is probably (maybe?) why it's set up this way, but maybe there's a bug?

[akademie]

It can be that.

Anyway e.g. I have opened lots of chains or individual plugins when working on project for a good reason and cannot be "workarounded" by something like 'if you want this temporarily muted track save CPU, then find all its plugins windows and close them

Hopefully the threads will catch devs eyes and will be able to fix the bug or change the new design behavior.

[mschnell]

Seems appropriate and if it's not buggy, the track would be stalled if all plugins are not visible.
Seems like not easily do be tested ?!?!?

[Justin]

Actually 99% sure this is just a CPU metering issue, where the lack of processing is what times out. We can shorten the length of that, I suppose.

[akademie]

Originally Posted by Justin

Actually 99% sure this is just a CPU metering issue, where the lack of processing is what times out. We can shorten the length of that, I suppose.

HMM, but
1) for +dev and pre- , there the CPU does not drop to zero after mute at all, even after 5 minutes, if the GUI/plugin/FXChain is open/visible. If you close it, then the CPU drops almost immediatelly (= within 2 seconds, the same as with older releases) - what does preventthe track to stop processing when GUI visible? (that's definitely something new)

2) for the older releases vs 6.82rc1 , what change makes the dramatic difference in timing(*) of CPU stop processing in this RC1 versus older releases (like 6.58)? (all my tested installs have the default preferences and configurations, also Dummy Audio is selected)


EDIT: (*)
And btw, for the case nr.2, now I tried to look at the Performance meter after reading your post and I definitely see that the CPU at the top of the window is lowered after those 2-3 seconds, while the number in performance meter's track list area is still holding the last value for some another 10 seconds (within that time period there is discrpancy between the tracks' individual valkues versus the total CPU load at the top. I do not know where the change comes from , why it is useful or needed/required, just it is not good I think if is not synced...

[mschnell]

Originally Posted by akademie

1) for +dev and pre- , there the CPU does not drop to zero after mute at all, even after 5 minutes, if the GUI/plugin/FXChain is open/visible. If you close it, then the CPU drops almost immediatelly (= within 2 seconds, the same as with older releases) -

To me this seems perfectly correct. If the GUI of a plugin is visible it (the audio part) needs to be processed, as the user seems to want to see it's results (say, e.g. a spectrum). To do this supposedly the complete track needs to be "powered"

[akademie]

Sorry mschnell, but it is perfectly incorrect!

Originally Posted by mschnell

To me this seems perfectly correct. If the GUI of a plugin is visible it (the audio part) needs to be processed <snip>...

We are talking about "muted tracks" and "Do not porcess muted tracks..." option enabled in preferences (REAPER Preferences > Audio > Mute/Solo) here.
So:
1) if track is muted, it does not sound, should not process according to that option and therefor CPU usage should be 0 (zero) even if the GUI is visible.

2) This behavior has changed few +dev pre-releases ago, so it was not correct all those long year, but is not correct now. And possibly can be because of new strategy under the hood which may be incompatible, but that's why the Bug (or regression) report.

[mschnell]

Originally Posted by akademie

1) if track is muted, it does not sound, should not process according to that option and
2) This behavior has changed few +dev pre-releases ago, so it was not correct all those long year, but is not correct now. And possibly can be because of new strategy under the hood which may be incompatible, but that's why the Bug (or regression) report.

1)I don't think so. Muted means: no sound output. Hence no processing necessary when considering the sound. But if some GUI is visible, same might be expected to be "active" from the sound in the track.
2) obviously because something changed regarding the plugin GUI handling.

[akademie]

Uh, I am out of arguments on such basic thing as is the 1) at least.

I am not saying that the GUI (globally) shouldn't consume some CPU, but it is included in global CPU metering in Performance meter (at the top).

On the other hand, list of individual tracks' CPU shows processing CPU by all the track's plugin chain - let's call it audio, because when the track is muted , again - it does not process any audio (or at least should not when that option is enabled) and also any plugin's GUI should not visually update anything (it is disabled for the muted time).

[nofish]

Recently released v6.82rc2 contains a change referring to this thread.

[Justin]

Originally Posted by akademie

HMM, but
1) for +dev and pre- , there the CPU does not drop to zero after mute at all, even after 5 minutes, if the GUI/plugin/FXChain is open/visible. If you close it, then the CPU drops almost immediatelly (= within 2 seconds, the same as with older releases) - what does preventthe track to stop processing when GUI visible? (that's definitely something new)

We made a change for 7.0 (and thus +dev builds) where muted tracks always have their FX processing if the FX UI are visible.

2) [u]for the older releases vs 6.82rc1[u] , what change makes the dramatic difference in timing(*) of CPU stop processing in this RC1 versus older releases (like 6.58)? (all my tested installs have the default preferences and configurations, also Dummy Audio is selected)


EDIT: (*)
And btw, for the case nr.2, now I tried to look at the Performance meter after reading your post and I definitely see that the CPU at the top of the window is lowered after those 2-3 seconds, while the number in performance meter's track list area is still holding the last value for some another 10 seconds (within that time period there is discrpancy between the tracks' individual valkues versus the total CPU load at the top. I do not know where the change comes from , why it is useful or needed/required, just it is not good I think if is not synced...

the performance meter shows the same value as the UI does, it should go to 0 within a few seconds in 6.82rc2, assuming "do not run muted tracks" is enabled... (it does here, too). (also assuming it doesn't have pre-fader sends, isn't record armed, etc etc)

[mschnell]

Originally Posted by Justin

We made a change for 7.0 (and thus +dev builds) where muted tracks always have their FX processing if the FX UI are visible.

I suppose this holds if any of the track's plugins' GUIs is visible. IMHO this makes perfect sense. Maybe Akademy might want to have this configurable.

[akademie]

Originally Posted by Justin

We made a change for 7.0 (and thus +dev builds) where muted tracks always have their FX processing if the FX UI are visible.

This part is bad in my honest opinion, because I can have opened so many FXChain windows or even worse - many individual plugins GUI floating and when I need to mute track while also to save CPU I would have to close all individuals belonging to that track to save CPU, and few moments later the same with different track and reopen the closed ones again for previously unmuted track

Can we have "old behavior" preserved as an option (legacy or whatever), please?

Because for workflow different than kind of "open one FX window at a time" it is extreme functional regression

[akademie]

Originally Posted by mschnell

I suppose this holds if any of the track's plugins' GUIs is visible. IMHO this makes perfect sense. Maybe Akademy might want to have this configurable.

Yes, because, again, I can't think any good reason (not that there isn't any of course) when I would want/need to process plugin when its GUI visible, if I mute the track and explicitly instruct it to "not processing muted track", really.

(Anyway, I can think of unwanted CPU hungry behavior when e.g. I have few tracks (or many) , each with lots of CPU hungry plugins, their GUI opened and to save CPU even more I decide to "Render stems and mute originals". Then I will have double number of tracks, originals will be muted but their processing still running for no good reason except their "dead GUI" is still open and all the windows have to be closed to have any required effect

I think with the new functionality for v7.0, the option is really missing to keep all other functionality almost intact, not affected.

[akademie]

Only reporting that the case 2) (= timing discrapancy of performance metering) is solved in REAPER v6.82 RC2.

Main topics stays still.
(more in next post...)

[akademie]

To the main thread case #1).

Why is dropping one of the Reapers strong features (aka "Do not process muted tracks..." option) planned for v7.0 ??

Again, can we have compatibility option/settings ?
All older projects which have various plugins windows open on muted tracks will be hard to manage and even hard or impossible to open due to CPU overflow

Also why is essential to be able to have visible GUI (again I mean "dead GUI" = no movement, measurement indication, processing) on tracks which are muted?
For example as blueprints, where the initial setting of parameters is still visible from dead/muted tracks, while we are working on active copy of the track and tailoring the parameters (visualy can compare diferences over "template/blueprint"). In sound design there are really lot of windows opened (and also lot of PM windows opened) for constant tweaking.

I really do not know deeper plans on audio engine for v7.0 which needs to break current behavior and workflows, but considering compatibility like:
- adding option to Mute/Solo window (there is already exceptions in "Do not process muted tracks.." for sends etc.("survive"), so perfect place for another option something like - "tracks with visible GUI prevent stopping processing"..
- or introducing new feature like "offline/archive track" with button on TCP/MCP which would have essentially the same behavior as "Do not process muted tracks" in pre7.0 versions
- other ideas..?

[mschnell]

Originally Posted by akademie

Yes, because, again, I can't think any good reason ....

You seem to like to have Plugin GUIs floating. I only rarely do that.
But OTOH, a plugin GIO also can be "open" embedded in the TCP or MPC. This might add to the issue !

[akademie]

^^^^ right, just wanted to write another interesting case:

I just tried to insert ReaTune on a track in v 6.81+dev0730 which already introduced the new behavior.

A) If the FXChain window or ReaTune's individual floating window with its GUI is open, visible, then when the track is muted it is still processing

B) If the FXChain window or ReaTune's individual floating window with its GUI is not open, is not visible, then when the track is muted it stops processing (OK)

That's something we already figured and is discussed,
but

C) If e.g. the ReaTune's GUI is embedded to TCP/MCP, then when the track is muted it stops processing (OK)

Then, am I missing something? Why in "C)" track stops processing when the GUI is also visible??? (this is behavior I am used to and use a lot, but with normal windows, not embedded)

[mschnell]

Originally Posted by akademie

Why in "C)" track stops processing when the GUI is also visible???

Yep that is inconsistent.

I feel a decent solution could be two (global ? ) configuration options:
(- do not process muted tracks (as before) )
- process muted track when a plugin's main GUI is visible (checked by default)
- process muted track when a plugin's embedded GUI is visible (unchecked by default)

[Justin]

We can add an option, sure

[Icchan]

Originally Posted by Justin

We can add an option, sure

I think it would be very cool if any muted track that's not being processed, would take a "snapshot" of the GUI, then when you open the chain or the GUI you get grayed out UI that just says "This plugin is muted and is not processed. If you want access, disable "do not process muted tracks." from the options." or something something...

Or just check "if dirty" or something and if the window isn't displayed, do not process, if it is, process as normal.

[akademie]

Originally Posted by Justin

We can add an option, sure

EXCELLENT !

I appreciate it, thank you

[mschnell]

+1