SoftClip to allow smooth transition to saturated audio #136
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,50 @@ | ||
| #ifndef SOFT_CLIP_H | ||
| #define SOFT_CLIP_H | ||
|
|
||
| #include "AudioOutput.h" | ||
|
|
||
| template<unsigned int SMOOTHING, typename T = AudioOutputStorage_t> | ||
| class SoftClip | ||
| { | ||
| private: | ||
| const unsigned int max_threshold = (unsigned int) SMOOTHING * PI / 2; | ||
| T lookup_table[(unsigned int) (SMOOTHING * PI / 2)]; | ||
| T max_value; | ||
|
|
||
| public: | ||
| SoftClip(T max_val) | ||
| { | ||
| max_value = max_val; | ||
| for (unsigned int i = 0; i < max_threshold; i++) | ||
| { | ||
| lookup_table[i] = SMOOTHING * sin(1.*i / SMOOTHING); | ||
|
There was a problem hiding this comment. Just a thought: We're already shipping sinewave lookup tables. Arguably, that's 8 bits, only (not sure, what values you have in mind for SMOOTHING), but could perhaps be reused, here? That would save the heavy computation, but could possibly save RAM, too, in case that table is already used in some Oscil in the same sketch. There was a problem hiding this comment. Note that the calculation is done only once, probably before audio starts if the user does not try to have "local" version of this class in the main loop, hence it is very fast. Memory is more my concern however, as you pointed, the main problem of the tables is that they are 8bits only whereas this can compute a soft clip on any resolution, which is crucial for the final flattening (when reaching saturation) otherwise there are huge jumps in the output values which are more like an hard clip. We could potentially interpolate them though, but for non power of 2 values of the |
||
| } | ||
| } | ||
|
|
||
| inline T next(T in) | ||
| { | ||
| if (abs(in) < max_value - SMOOTHING) return in; | ||
| else if (in > 0) | ||
| { | ||
| if (in < (T) (max_value - SMOOTHING + max_threshold)) return lookup_table[in - max_value + SMOOTHING] + max_value - SMOOTHING; | ||
|
There was a problem hiding this comment. My guess is that it may be worth caching There was a problem hiding this comment. Indeed! That's a good point! |
||
| else return max_value; | ||
| } | ||
| else | ||
| { | ||
| if (-in < (T) (max_value - SMOOTHING + max_threshold)) return -lookup_table[-in - max_value + SMOOTHING] - ( max_value - SMOOTHING); | ||
| else return -max_value; | ||
| } | ||
| } | ||
| void setMaxValue(T max_val) { | ||
| max_value = max_val; | ||
| } | ||
|
|
||
| T getMaxValue() { | ||
| return max_value; | ||
| } | ||
|
|
||
| }; | ||
|
|
||
|
|
||
|
|
||
| #endif | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My gut feeling is that SMOOTHING should not be a template parameter (it would rather be specified in the constructor). This is a relatively heavy class, anyway, and having this as a regular parameter may allow a little extra flexibility (allowing to adjust smoothness, at runtime, even if it will be a somewhat slow operation).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did that so that the lookup table would be statically allocated. If the lookup is the right way to go, then if this is not a template parameter, I do not see the way to statically allocate it without a template but maybe you can enlighten me on that?
Note that, for a "compressor" effect, the
maximum_valuecan be changed at runtime (and compensated afterward for a full compressor). This is a bit the way analog soft clipping works: if one is using a diode, the response of the diode cannot be changed, but the level of what goes in can, which is equivalent to changing the maximum value (or boosting the signal with the same maximum value).