waveshaping - parabolic curve function


    Jul 27 2006 | 11:24 am
    trying to write a patch which distorts audio with a parabolic waveshaping function. for the moment, i am not interested in using wavetables in a buffer. i would rather do it as demonstrated in the patch below. my problem is adjusting the curve factor of the waveform...
    any tips or helpful URL appreciated?
    BTW, my maths aint too hot but am willing to learn!
    thanks
    justin

    • Jul 27 2006 | 1:53 pm
      use overdrive~?
    • Jul 27 2006 | 2:24 pm
      i have not been too impressed with overdrive cos it cliks and pops if u change the drive factor quickly with the mouse. that's why i like to keep things in signal domain... (maybe c74 can fix this!)
      also i'm curious about the maths behind tweaking the transients of a waveform...
    • Jul 27 2006 | 2:38 pm
      i find scaling the audio signal going into overdrive~ gets me all my waveshaping fun with out clicks and pops. so like:
      insig~ line~ / [*~ 32.]
      overdrive~ outsig~
      then again one might be able to plug a line~ object into the drive factor input of overdrive~. that might also eliminate the clicks and pops of changing audio parameters at control rates...
      > i have not been too impressed with overdrive cos it cliks and pops > if u change the drive factor quickly with the mouse. that's why i > like to keep things in signal domain... (maybe c74 can fix this!)
    • Jul 27 2006 | 2:49 pm
      -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
      On Jul 27, 2006, at 10:24 AM, justin wrote:
      > i have not been too impressed with overdrive cos it cliks and pops > if u change the drive factor quickly with the mouse. that's why i > like to keep things in signal domain... (maybe c74 can fix this!)
      take a look at [sig~] to convert your floats to signal control and [slide~] to smooth out changes.
      feed this into [overdrive~]'s second inlet.
      -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin)
      iD8DBQFEyNJpRvcxtaNGgooRAj9qAJ9KO02lEcvHlsNRbEcI9GXCnZM+lQCfd1Am OStX/J3BZNk/42C765aIOLE= =vv8W -----END PGP SIGNATURE-----
    • Jul 27 2006 | 3:01 pm
      didnt think overdrive could take sig to control drive factor, thought this was only float... i will try it out a bit later, busy at mo!
      any clues as to maths behind it would still be appreciated?
      cheers, j
    • Jul 27 2006 | 4:55 pm
      > any clues as to maths behind it would still be appreciated?
      hm, just took a quick look at your patch and i guess you confused the inlets of the pow~ object. left is exponent right is base. try swapping and see if it gets you closer to where you want to go. there are a lot of different approaches towards creating waveshaping functions. i don't know which one overdrive~ uses, but it looks kind of similar to an arctan-distortion.
      also check the archives, i think jhno once proposed some techniques. gruess, vb
    • Jul 28 2006 | 11:52 am
      cheers vb!
      i managed to get it to work with pow thanks to swapping inputs. i knew i was along the right lines...
      i also looked at ur patch which seems much cleaner. for a start you dont have to split positive and negative signals, which means less objects... however i managed to find jhno's thread on reaktor saturation module, and discovered you can go even simpler!
      *~ (drive factor) > tanh~ = saturation / distortion
      (IMO) this also seems to produce a warmer tone with less fuzz in the hi end than my pow~ attempts, which is harsher on the transients. not sure how it compares to ur patch, altho my guess is they are probably quite similar...
      thanks again!
      j
    • Jul 28 2006 | 12:57 pm
      Here's another approach using sinus. Looking at the patch it might look ridiculous, but it sounds really good and warm. I believe this is the distortion jhno ended up using for the overdrive in radiaL.
      Me and Tim discussed these issues a lot a while ago, and ended with Tim implementing both this and the tanh approach in the overdrive external used in Jamoma: jmod.saturation~. Note that using tanh or sinus in the signal loop like this is computationally expensive. Lookup tables are much cheaper. jmod.saturation use lookup and linear interpolation AFAIR.
      I should add that for some funny reason the mach-o version of jmod.saturation~ don't like to load on Max 4.5.7 or lower. In Max 4.6 it works fine.
      Best, Trond
      justin wrote: > cheers vb! > > i managed to get it to work with pow thanks to swapping inputs. > i knew i was along the right lines... > > i also looked at ur patch which seems much cleaner. for a start you dont have to split positive and negative signals, which means less objects... however i managed to find jhno's thread on reaktor saturation module, and discovered you can go even simpler! > > *~ (drive factor) > tanh~ = saturation / distortion > > (IMO) this also seems to produce a warmer tone with less fuzz in the hi end than my pow~ attempts, which is harsher on the transients. not sure how it compares to ur patch, altho my guess is they are probably quite similar... >
    • Jul 28 2006 | 1:54 pm
      only problem i have with table lookup is that changing the curve in real-time becomes problematic, especially as far as pluggo is concerned.
      i tried to use defer to de-prioritize the uzi>function>peek~ part of the patch. but it still goes mental - gui in ableton live goes real slo and automation is a no go... maybe i'm doing something wrong? not quite sure where the defer bit should go in the patch!
      your sine patch is quite different to the tanh, seems to be more subtle. can u still overdrive it as much as tanh? looks like ur kinda folding a sine wave twice over itself... but doesnt seem to have the grunt of tanh if u see wot i mean!
      j
    • Jul 28 2006 | 2:15 pm
      I can understand that, but it depends on what kind of changes you want to be able to do. If you look at the example I posted, I'm effectively changing the curve. This because input is scaled before being wave shaped, and then rescaled afterwards according to the maximum output value possible for a signal in the range [-1,1]. So if the overdrive value is close to 0 almost no distortion is added, as only a small almost linear section of the sinus curve around origo is used. As it is increased to 100% the distortion gets more and more pronounced. But all the way maximum amplitude of the output stays consistent.
      If you want to be able to move between radically different kinds of curves (and not just use a larger or smaller part of it), you could also contemplate using a jitter matrix. If you have for instance a jit.matrix 1 float32 512 2, and use jit.peek~ @interp 1 you could load one curve into row 0 and another into row 1. By moving back and forth between row 0 and 1 you will move between the curves. Of course this is more expensive than using a single lookup table as you are interpolating in 2D instead of 1D.
      You would be able to expand this further either by adding more rows so that you have more curves to choose between, or by dynamically changing the cell values of one or the other row so that you substitute an old curve for a new one.
      You could also check out 2Dwave~.
      Best, Trond
      justin wrote: > only problem i have with table lookup is that changing the curve in real-time becomes problematic, especially as far as pluggo is concerned. > > i tried to use defer to de-prioritize the uzi>function>peek~ part of the patch. but it still goes mental - gui in ableton live goes real slo and automation is a no go... maybe i'm doing something wrong? not quite sure where the defer bit should go in the patch! > > your sine patch is quite different to the tanh, seems to be more subtle. can u still overdrive it as much as tanh? looks like ur kinda folding a sine wave twice over itself... but doesnt seem to have the grunt of tanh if u see wot i mean! >
    • Jul 28 2006 | 2:37 pm
      actually i quite like ur sin distort patch to get a bit more warmth... works a treat if u put it before tanh!
      thanks for all suggestions!
      j
    • Jul 28 2006 | 5:55 pm
      > your sine patch is quite different to the tanh, seems to be more subtle. can u still overdrive it as much as tanh? looks like ur kinda folding a sine wave twice over itself... but doesnt seem to have the grunt of tanh if u see wot i mean! > > j
      hmm hmm i would call the effect you can reach with mult with [tanh~] a "saturation effect" - and i find it still quite a subtile effect. :)
      i get good results in that direction by using two [tanh~] based DSPs in series.
      if your signal input is not music, but only sinewaves of a known frequency, then it can be worth looking into [kink~] instead
    • Jul 28 2006 | 6:13 pm
      that arctan distortion uses half the CPU of overdrive~. very nice
    • Jul 29 2006 | 12:38 am
      simpler! > > *~ (drive factor) > tanh~ = saturation / distortion > >
      adding a +~ between *~ and tanh~ is also nice, because it creates asymetrical distortion.
      cheers,
      mzed
    • Jul 29 2006 | 2:36 am
      save this as
      [110.saturn~]
      [110.saturn~.help]
      -110
    • Jul 29 2006 | 10:16 am
      i've been using something like this for waveshaping in an FM synth.