easyeffects
easyeffects copied to clipboard
wwmm
Enable toggle for an app is not kept after closing
I find this strange since the excluded apps are remembered as excluded, but the enable toggle right next to it behaves differently.
That is because the enabled state isn't a configuration key like the others that depend only on what EE is doing. Enabling an application just means "try to move it to our virtual device". But the audio app and third party tools like pavucontrol are totally free to choose another destination at any point in the future. And like Pulseaudio, PipeWire also has its own stream -> device restoration logic that may get in the way. In this case we would have a state that does not represent what is actually being done anymore. So in order for this to make sense we would have to try to force this state. But this isn't even possible in some corner cases. In the past when we still used Pulseaudio someone asked for this but it will be an endless source of headaches.
Yeah that makes sense. I wonder if something could be done to clarify this in the UI though? Some way of conveying it is not permanent and is different from exclude.
How difficult is it to detect if the application is in the right state, i.e. moved to the virtual device? Perhaps what can be done is to remember a "tentative list" of apps that were enabled previously. If at startup the list of apps that are actually enabled are different, the user can be warned and the enabled toggles will revert to a default like they do now.
How difficult is it to detect if the application is in the right state, i.e. moved to the virtual device?
We know where the application is. The problem is that there is no guarantee it will stay there. In its default configuration EE will try to Process All Outputs/Inputs. But this is an one time operation. It will try only once. Whether it worked or not. But if we look at this as a setting we will have to monitor its state and force what is in our configuration. What will have consequences. Let's imagine that the user wants EE to apply effects almost all the time but that in some situations using the app built-in device selector is desirable. As things are right now EE won't get in the way. But if we try to force a state whenever it sees the current stream device is not the one "it should be" we may undo what the user tried to do.
It is also hard to know if when we force a disabled state the stream is going to where the user wants. What we do now when we disable is setting target.node to null. What makes sense when the stream starts in EE. But if it didn't we probably should not be doing this to it. So we have to make sure we do not touch the stream if it were not linked to our virtual device while EE was running.
Another corner case is what we should do if the app is disabled in our settings but the app device selector or pavucontrol move it to us. Do we update our setting to enabled or do we force the disabled state? Now the button just reflects the current state. But if it becomes a setting the situation is different. I think too many corner cases that will have to be handled will be introduced by this feature...
As most users probably have Process All Outputs/Inputs enabled there isn't much to gain by saving this state. EE will try to force it, once, in this situation. And the people that do not want EE to process all streams probably do not want EE messing with the stream device anyway. And for the people in the middle ground there is the blocklist. If the app is there EE won't touch them. But if the disabled state becomes something that is saved EE may have to touch these streams.
I wonder if something could be done to clarify this in the UI though?
I don't know. I look at it as "Apply Effects". But this may become too big in some languages.
I don't know. I look at it as "Apply Effects". But this may become too big in some languages.
But I think this name would have the same problem. I am not sure there is a way to pass all this information using just one or two words. What we do now does not give the full idea. But making this a setting in the usual meaning of the word will bring more problems.
Perhaps we try disconnect the enable button from the actual state. And also I think using a checkbox in the first place is problematic since those are usually saved.
e.g. we can change the enable toggle to a button that says "toggle effects" (or similar). Then the actual "is app moved to virtual device" state of the app would be shown by a green or red icon for each app.
Then at least it does not look like the toggle is directly controlling the state. It is still somewhat unclear to the user why the state might change though. But there is maybe another way with the many widgets.
e.g. we can change the enable toggle to a button that says "toggle effects" (or similar). Then the actual "is app moved to virtual device" state of the app would be shown by a green or red icon for each app.
Green or red icons may not be nice to color blind people. So the shape has to be clearly indicating the state too. But arranging the widgets in the available space may also not be that easy. The last round of changes to the apps list has shown this.
Then at least it does not look like the toggle is directly controlling the state. It is still somewhat unclear to the user why the state might change though.
It depends on how you look at it. It can change where the application is. It just isn't guaranteed the action will succeed and even if it does it isn't permanent. Even if we implement a "toggle effects" and an indicator some people may still expect it to be a configuration setting and wonder why sometimes the indicator is in the off state. The current problem would only move to a different button or widget.
We could summarize all that has been said here in 3-4 rows in the manual explaining what the enable and exclude checkbuttons are doing (even if there's already the App Excluded section covering it partially) and why the enable one may not be persistent.
