Waveshaper Bias Definition is Unintuitive with low amplitude signals

[Andreya-Autumn]

Compare the following screengrabs of the waveshaper affecting a sine wave in rack vs SCXT. The bias is clearly wrong in SC, but why?

[baconpaul]

OK Bias is not borked

That is, the signal sent to the drive is indeed "sig + bias" where bias is -1...1

the problem with this is if you send in a signal which is in, say, range 0.2 ... 0.2 and have the drive high then any bias above 0.25 or so just gives you all positive.

Let's take the case of a high drive clipper. So the output is std::clamp(d * ( x + b), -1, 1).

If we make d = 5, b = 0.5 and put in a signal in the range +/- 0.2 we end up with just 1 coming out

If you send in a full height sine wave to the wave shaper it acts just like the rack one does. You can see that above where I use bias + drive + soft to turn a full height sign into a pulse wave sweep.

So I don't think there's anything we can change here. If we make bias non-additive then it's just drive.

[baconpaul]

Here's a demo of same in vcv rack

[baconpaul]

Possible things to consider here

1. Nothing. Not a bug. Press close
2. Have the bias control be not applied linearly. So like use bias^3 or cube root of bias or whichever way makes it less extreme for small values
3. Change the definition of bias somehow to something which someone suggest
4. Remove the bias
5. Do something else clever

I'm sort of thinking 1 or 2 are best

[mkruselj]

Bias is indeed supposed to work like this exactly, I think.

[baconpaul]

yes I think the only question is do we nooj the control scaling or not.

pro: more range con: modulation becomes wierd

[mkruselj]

Yeah I think it should just be linear in amplitude scale, as it probably already is. The point of this control is to target different parts of the waveshaper's curve, and the only way this can work predictably is if it is linear.

[baconpaul]

So that’s a vote for “1. Close this issue” We could also add a pre bias gain I suppose?

[Andreya-Autumn]

Well, a DC filter after would be a good idea in any case (I think). I'll continue on Discord with other thoughts.

[baconpaul]

Our rough view here is "input and output gain control for each proc solve this" and so "we should add those to the routing pane since we want them for other things anyway" so closing this and adding that.