CPU-friendly 'subtle to destructive' saturator/distortion?

    Apr 29 2017 | 3:59 pm
    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

    • Apr 29 2017 | 5:08 pm
      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.
    • Apr 29 2017 | 5:58 pm
      This (old) thread is a goldmine of patches/ideas:
      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?
    • Apr 29 2017 | 6:29 pm
      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.
    • Apr 30 2017 | 4:52 pm
      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. :)
    • May 01 2017 | 4:11 am
      @brendan I think it was here https://cycling74.com/forums/hippie-patching
    • May 01 2017 | 8:22 am
      @Rick Well found, mate!
    • May 04 2017 | 11:45 am
      Thanks a lot for great resources everyone!
      @ROMAN THILENIUS It would be great if I can see a simple example of your smart approach...!
    • May 05 2017 | 3:01 pm
      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.
    • May 06 2017 | 1:37 pm
      I made an amxd verson of Jamoma saturation~.model. It is designed to be controlled within Live more easily, including a cheeky oneknob feature.
    • May 06 2017 | 2:42 pm
      (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)
    • May 06 2017 | 5:21 pm
      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?
    • May 06 2017 | 7:57 pm
      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).
    • May 06 2017 | 11:00 pm
      add the 32bit versions of the objects (as well as windows (or mac)
      Could you possibly tell me how I can do that?
    • May 06 2017 | 11:06 pm
      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.
      Actually, apparently this is not the correct way to do this, so ignore my last comment!
    • May 24 2017 | 9:27 pm
      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.