CPU-friendly 'subtle to destructive' saturator/distortion?
Hi, I am trying to achieve a CPU-friendly saturator/distortion which can go from subtle to extreme/distructive by changing a paramter. Could anyone kindly share techniques or resources to learn?
Thanks a lot in advance,
Masa
a common approach around here is the tanh~ object.
try it pure or with the input multiplied for pi, or include some dynamics processing.
try it as blackbox or make a parallel layout, use it on the whole spectrum or only one freqency band of many.
one of my favorite saturation effects is to demodulate the input material (removing the envelope, tanh, adding the envelope again) so that softer passages are also affected.
This (old) thread is a goldmine of patches/ideas:
@Roman
That's an interesting idea (de/remodulating). Do you just compress the shit out of it and then use an envelope follower (of the original signal) to boost it back after?
Any patch examples to share using that?
@Rodrigo
yes, that's still an excellent resource. I remember Peter Mc used omx.comp~ in a feedback loop with fb > 1 and it was NASTY (in a good way!). Not sure where that thread is though.
Brendan
it is really simple, yes like an (lowpass/slide/based) envelope follower, you´d invert the control signal and apply it over the input and later you use the original congtrol signal and apply it again.
for slide 1000, use 500 ms latency to have the effect somehow linear - or dont, for even more fun. :)
@brendan I think it was here https://cycling74.com/forums/hippie-patching
@Rick Well found, mate!
Thanks a lot for great resources everyone!
@ROMAN THILENIUS
It would be great if I can see a simple example of your smart approach...!
After researching and experimenting more, I found that saturation~.model of Jamoma Package is very well designed. It can go from subtle saturation to destructive distortion, but it is yet CPU-friendly by using a lookup and linear interpolation approach rather than actual tanh or sinus calculation.
(you'll need to include all of the j.objects and freeze the patch, as it shows up as missing tons of objects on my system (without jamoma installed))
edit:
(actually, I think it's a 64 vs 32bit thing, I'm in 32bit Max)
Hi Rodrigo, as I am not used to share amxd, I might have made a mistake.
I 'freezed' and saved the amxd. And yes, it was saved under 64bit Max. Is there anything I can do about this?
I don't know if Jamoma is only 64bit, but once you make the Max project version of the file, you can add the 32bit versions of the objects (as well as windows (or mac)), then reconsolidate the project. That way when you make the M4L device, it will have all the versions of the dependencies (32/64 and mac/win).
add the 32bit versions of the objects (as well as windows (or mac)
Could you possibly tell me how I can do that?
Again, I don't know anything about how Jamoma works, or if the externals are mac/win 32/64 or whatever, but in this example, I have just dragged the two windows externals (.mxe) into the "Externals" section of the Project manager window on the left.
edit:
Actually, apparently this is not the correct way to do this, so ignore my last comment!
Jamoma is an officail package by the way.
Here's the updated amxd version of Jamoma saturation~.model. I am still having a problem.
When saving and re-opening a Live project, the parameters of the related live objects are properly recalled, but the internal settings of saturation~.model are not recalled properly, even though I make sure sending a bang to the related live objects when loaded. I would appreciate if anyone can fix this.