Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain and implement different modes better #52

Open
bergfried opened this issue Sep 20, 2022 · 2 comments
Open

Explain and implement different modes better #52

bergfried opened this issue Sep 20, 2022 · 2 comments

Comments

@bergfried
Copy link

(Sorry for the somewhat strange-looking title.)

I just learned by accident that I can choose different values for "Learn noise profile". Neither the README.md nor the Wiki explain them, nor do they acknowledge their existence. How do they work? Some of them appear to be labeled in Spanish. For English, I would prefer simpler labels like

  • 0: "Disabled"
  • 1: "Average"
  • 2: "Median"
  • 3: "Maximum"

But I do not know whether that would be expressive enough since I do not understand the semantics. Please explain the meaning of the different values (0 to 3) in the Wiki.

While we are at it: From what I guess the different values are supposed to mean, does that mean that the way noise reduction works depends on the mode chosen during learning? If so, why not just learn for all of the three different modes simultaneously, and then let the user choose the mode to be used afterwards? That way, the user can try and compare different modes without having to try and make Noise Repellent relearn from the exact same noise profile repeatedly.

In the end, I think of something like this:

  • "Learn noise profile" should have only two values, "0" meaning "Disabled" and "1" meaning "Enabled".
  • There should be a new control "Mode" with the same four different values and labels as enumerated in the list above.
  • Since "Mode" can then be set to "0" meaning "Disabled", there is no need for a separate control "Enable" anymore. Thus, the currently present control "Enable" can be removed.

The main advantages I see are the following:

  • It is easier for the user to compare different modes by trail and error.
  • Every effect host I have ever seen already features a separate (binary or continuous) dry/wet control for each effect. Thus, removing the current "Enable" control simplifies the interface since it is probably redundant anyway.
  • Given the current implementation, what happens if the user switches "Learn noise profile" from a non-zero value to another non-zero value, e.g. from "2" to "1"? This kind of question (and confusion!) will not arise with the changes proposed here.

Of course, there are probably reasons as to why the controls are the way they currently are. Maybe what I imagine is too complex to implement or too difficult to use. What do you think?

P. S.: The control "Reduction strenght" (sic!) should probably read "Reduction strength".

@lucianodato
Copy link
Owner

That makes absolute sense! Much better usability for sure. Thing is I'll need to change how libspecbleach works quite a bit. Still doable I think.

@bergfried
Copy link
Author

Well, technically, there are at least two downsides to the approach I proposed.

  • If, for example, it should later be possible to use different percentiles instead of fixed ones like "Median", the new approach would need to compute and store data for each percentile, making it quite inefficient.

  • Even if the number of non-trivial choices is fairly limited (currently three), it still needs more data (in this case roughly three times as much).

However, I think the currently available three choices are good enough. Again, as I said, these are only theoretical downsides written down here for the sake of completeness.

(By the way, I am not sure whether "Mode" is a good label but I could not yet come up with a better word for it.)

@lucianodato lucianodato transferred this issue from lucianodato/noise-repellent Oct 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants