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

Input signals exceeding the graph are not clipped off. #169

Open
Sandelinos opened this issue Sep 2, 2023 · 4 comments · May be fixed by #170
Open

Input signals exceeding the graph are not clipped off. #169

Sandelinos opened this issue Sep 2, 2023 · 4 comments · May be fixed by #170

Comments

@Sandelinos
Copy link

Not sure how to verbally explain this in more detail than in the title.
I noticed this when I was trying to use Wolf Shaper as a soft-clipper but no amount of input gain would make the signal actually clip.

Here's a screen recording demonstrating the issue:
https://cloud.sandelinos.me/s/8o5RD6d64m82YrP

@Sandelinos
Copy link
Author

Sandelinos commented Sep 2, 2023

Made a PR (#170) to fix it.

@Sandelinos Sandelinos linked a pull request Sep 2, 2023 that will close this issue
@pdesaulniers
Copy link
Member

pdesaulniers commented Sep 3, 2023

Hello, thanks for the issue and PR!

The plugin was implemented this way in order to avoid distortion in the 'default graph' state. If we clip the signal at +/- 1.f, then the plugin may distort the input signal as soon as it is added into the FX chain. The idea behind the current behavior is that the plugin shouldn't distort the input signal until the user modifies the graph's function.

With that said, I think your patch is useful.

Instead of simply clipping the input, would it make sense to 'extend' the graph's function to infinity? Here is a crude drawing to illustrate :) The green line represents the part of the function that exceeds the graph:

image

Here is another example, this time with the default graph:

image

This behavior would let you achieve soft-clipping, and it wouldn't distort the input by default.

One more note: I'm a bit reluctant to change the plugin's default behavior, since it could break backward compatibility for some users. Ideally, I think this change should only be enabled for new projects, and the plugin should keep using the 'legacy' behavior for existing projects.

@Sandelinos
Copy link
Author

Hello.

The plugin was implemented this way in order to avoid distortion in the 'default graph' state. If we clip the signal at +/- 1.f, then the plugin may distort the input signal as soon as it is added into the FX chain. The idea behind the current behavior is that the plugin shouldn't distort the input signal until the user modifies the graph's function.

I don't think the plugin clipping the signal in it's initial state is a problem. If the input signal is too loud the "pre" gain knob can be turned down. Fruity WaveShaper does it and I haven't heard anyone complain about it.

Instead of simply clipping the input, would it make sense to 'extend' the graph's function to infinity?

I think there could be some things for which it could be useful (shaping crossover distortion with more precision by bumping up the input gain and decreasing the output gain for example) but I think it would mostly just be confusing to users that there is stuff happening outside the graph that they can't see. (the current behaviour was very confusing to me for a long time until I pulled up an oscilloscope plugin to see what's going on)

I'm a bit reluctant to change the plugin's default behavior, since it could break backward compatibility for some users. Ideally, I think this change should only be enabled on new projects, and the plugin should keep using the 'legacy' behavior for existing projects.

Compatibility with old projects could be kept by adding a "clip" button to the UI similar to the "center" button to enable/disable clipping that'd be enabled by default but disabled when loading an old project.

Also I want to say a huge thanks to you for creating Wolf Shaper. Wave shaping is probably my 3rd most used effect after EQ and reverb and it's awesome to have a great waveshaper plugin on Linux.

@pdesaulniers
Copy link
Member

pdesaulniers commented Sep 3, 2023

but I think it would mostly just be confusing to users that there is stuff happening outside the graph that they can't see

Fair enough :)

Compatibility with old projects could be kept by adding a "clip" button to the UI similar to the "center" button to enable/disable clipping that'd be enabled by default but disabled when loading an old project.

Yes, I like your suggestion! However, since we're adding a new parameter, I think it might be easier to disable clipping by default for new projects as well. The default value for parameters is passed to the host when the plugin is initialized (initParameter), and I can't think of a simple way to determine during initialization whether we're loading an old project or a new one...

(In order to distinguish old project from new ones, I was planning to add some extra characters at the end of the graph's default data, such as v2. If the characters are absent, then we can assume it's an old project. However, the graph is loaded after the parameters are initialized, so I don't think this approach could be used to change the default value of the parameters...)

Also I want to say a huge thanks to you for creating Wolf Shaper. Wave shaping is probably my 3rd most used effect after EQ and reverb and it's awesome to have a great waveshaper plugin on Linux.

Thank you, I appreciate it :)

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

Successfully merging a pull request may close this issue.

2 participants