Valve Distortion

    Jan 10 2012 | 7:22 pm
    totally new to max, but im building a guitar processor for a project, im struggling on how to build a distortion effect in max. i would preferably want to create a valve distortion effect using soft clipping. i was wondering if anyone had done this before, please be gentle, like i said im new

    • Jan 11 2012 | 12:20 am
      Welcome, you should really do a search of the form. There are loads of ideas for different distortions.
      One of my favourites is the simple tanh~
      Check it out
    • Jan 11 2012 | 2:35 am
      It is incredible how deep the resources are on this website - check out the community/articles section and keep scrolling and scrolling down and you will find Darwin Gross's articles on guitar processing. I have not read them all but this would be a darn good starting point!
      Good luck! Happy processing in Max!
    • Jan 11 2012 | 8:10 pm
      Also, if you go the tanh~ route, consider the following:
      - tanh is an expensive calculation. Make a lookup table for x in [-4,4], since it's -1 / 1 outside that range and you'll save a ton of CPU. (lookup~) If you have gen~, you might even try doing the lookup with spline interpolation. - Oversample your lookup inside a poly~ (even if you just use tanh~, do this) to improve the quality and reduce intermodulation distortion.
      Good luck!
    • Jan 15 2012 | 4:24 am
      I tried making a lookup table with tanh using a line~ into a tanh~ and then into a record, and it seems to have worked up until I write it to a file. The file it outputs is just 1024 samples of 1.0. Before and after writing it to a table though, the buffer I'm using displays the wave table I'd expect. Can anyone figure out what's going on?
    • Jan 15 2012 | 7:58 pm
      I hadn't actually tried the distortion in the guitar patch since I've used the overdrive~ object before and wasn't blown away. The usage in that patch is pretty effective (with a filter in between).
      I'm surprised we haven't seen more gen~ stuff for valve distortion, tape saturation and things like that yet.
    • Jan 16 2012 | 4:08 am
      Here's the more or less standard approach to generating static functions. You'll notice that there's no signal rate stuff going on. (or you could do it with only signal rate functions, but in general, pick one or the other, not a combination of the two because of the potential for timing errors)
      @Rodrigo: I think it's a question of the types of algorithms; static non-linearities are easy enough without gen~, though their quality is not the greatest. The other issue which gen~ doesn't address explicitly (though Max6 definitely does) is oversampling (via poly~). There's also a higher learning curve with gen~, since it requires more low-level knowledge of DSP. I've been playing around with non-linearities inside traditional filters; tanh works will inside of a reson loop.
    • Jan 16 2012 | 8:51 am
      I didn't realize you couldn't oversample in gen~. I've never really used it as it's over my head.
      That looks great, I'll have a play with this later when I get home.
      edit: sorry for the nooby question here, but how to you implement the lookup table version of tahn? (in terms of adding distortion like the first example posted)
    • Jan 16 2012 | 10:38 am
      Thanks for the annotated touch up Pete! Helped a lot
    • Jan 16 2012 | 1:07 pm
      "but how to you implement the lookup table version of tahn?"
      - use [tanh] and run a series of ascending numbers from 0-1 through it - use peek~ to write it into a buffer~ - make a buffir~with the same name as the buffer~, see buffir~helpfile. - like someone said, upsample it in a poly~to reduce the problem between latency and quality.
    • Jan 16 2012 | 1:08 pm
      beg your pardon, buffir~ should read lookup~ ^^
    • Jan 16 2012 | 2:41 pm
      Ah that's pretty awesome. I've never used lookup~ before.
      So at low gain settings this table version of tanh sounds pretty crappy, is that due to the intermodulation/upsample stuff?
      Regular tanh seems to fair alright for low gain stuff.
    • Jan 16 2012 | 4:43 pm
      @Rodrigo, you need to build the table with bipolar values; it will sound like crap if you use 0-1 to build your table. (since it's now bent in a weird way and unipolar. (Use the code that I posted above)
      For tanh, use a value from -4,4 to build your table. That's the point where tanh's value is asymptotically close enough to -1,1 that you can just clip it to -1,1 after that.
      You can scale your input before it hits lookup~ if you like. This will adjust the extremeness of the effect. You should also consider post-gain to adjust for differences in volume. Other typical tricks used are to add a slight DC offset so you get even harmonics as well as odd. You can use a highpass filter to remove the DC afterwards.
    • Jan 16 2012 | 5:27 pm
      I used your example from above and just added a lookup~
      I might just be in over my head code wise, but are you saying to make a -4/4 table, then clip it to -1/1 (literally using clip~)?
      I would add a post gain control to bring the volume back in line with whatever the boost was adding.
      That's an interesting trick (adding DC then removing it). So you would just add a [+~] to the audio signal before the lookup~/tanh~ (a little? a lot? or is this a 'tunable' thing like gain), then a straight highpass after the lookup~?
      Then there's the upsampled poly trick.
      Any other nuggets of distortion creating gold that stops short of gen~ stuff?
    • Jan 16 2012 | 8:56 pm
      I think we just need to collectively get one reaaally good gen~ patch with a lot of inlets to tweak stuff and a buffer~ loader thing. That would be an excellent place to start for our own nasty patches as well.
    • Jan 16 2012 | 9:39 pm
      That would indeed be badass. It's crazy how complicated tone shaping stuff can be.
    • Jan 17 2012 | 1:35 am
      Here's a bit more elaborate of an example:
      and TanhVox~:
    • Jan 17 2012 | 10:45 am
      Man there's a lot to take in in that patch! Thank you!
      The start of the signal path confused me until I figured the delay is to probably keep phase alignment with the cross fading input gain (a nice touch!). With regards to that part, wouldn't running the "dry" signal into normalize flatten it's dynamic range a bit? I ran the output of sfplay right into delay and ran the normalized version into the envelope follower and it sonds alright.
      The +/- gan thing is really interesting too. I'm wondering if it would be best to control asymmetrically using a couple of scale objects and a single num box.
      So much to play with, and this not even into eq/filter territory (I'm tempted to duplicate this whole section and run it in series with a one pole it be middle (like the gtr patch).
    • Jan 17 2012 | 4:07 pm
      Glad to help. Normalize will normalize it to the highest peak. It's handy for signals like electric guitar that are pretty stable in terms of dynamic range. It also makes sure that you get some peaks on the envelope follower. You could do this all with gain, but this works much quicker. I like to use asymmetric envelope followers like slide~ after average~ so that you get the decay, but the attack is still crisp.
      The reason for the scale with the asymmetry is that I wanted to smooth the discontinuity in gain levels. You can try different crossover ranges (or even no cross-over range) by setting the values for clip~ and scale~'s input range in parallel.
      I'd highly recommend the last approach you mentioned. This is the basis of some of the early digital distortion effects. Speaking of which, there was a paper not too long ago (ICMC Proceedings or maybe CMJ?) that summarized a lot of the approaches to digital distortion. It's totally worth a read. I'd bet some of the early patents have also expired, so Google may be your friend on that.
    • Jan 17 2012 | 5:33 pm
      Yeah each little section of the patch is a nice little educational resource. I'll try doing that series/filter thing to get some joy. It's also more computationally expensive than I had realized, so I might use a more straight ahead version (not unsampled, or smaller table etc..) in my main (already big) patch as I can't afford to give up 6% just for distortion. Unless I wrap the whole thing up in a poly and mute it when I'm not using it. Hmm.
      I'll have a look around for the paper.
    • Jan 17 2012 | 8:11 pm
      Here's the paper:
      Both waaay too heady for me, and believe it or not, not a single compressed max patch example in either to copy!
      Also found this which has more practical info:
    • Feb 18 2012 | 10:38 pm
      Just bumping this for any new distortion related revelations...
      I've leaned back towards an overdrive/onepole/overdrive type system since tahn~ distortion seems to have some brittleness to it (or at least how I was implementing it).
      Would be amazing to have a convolution-based tape/saturation type effect for more subtle/warming effects. (similar to the tritone digital colortone pro type thing).
    • Feb 19 2012 | 1:44 pm
      there are so many ways to approach this, largely depending on your input signal. i have many many of these non-linear saturation type equations stored up over the years - i'll post some if i get the time.
      oversampling is key. and making input / output gains simple eq's / filters rather than just linear gain controls, and as peter says, including non-linearities in your filters.
      the one advantage of using cpu + equations rather than lookup tables is being able to modify them dynamically. attached is a visualisation of this i did this morning, i hope it is interesting. requires max 6.0.4.
    • Feb 19 2012 | 4:34 pm
      Man that sounds really nice, quite simple too. I'd definitely love to see more of your examples if you wouldn't mind sharing.
    • Feb 19 2012 | 10:37 pm
      ok, here are two more.
      one is another Tom Szilagyi plugin port, still in progress and needs work. << single patch
      the other is a Julius Smith cubic non-linear saturation curve which Peter McCulloch told me about, so kudos to him. << .zip folder, abstraction, open the .maxhelp file first
      there is no great need for these to be in gen~ - i just happen to be accumulating gen~ things at the moment as i have become obsessed. also, much much easier porting C-code that way. hence, max 6.0.4 required.
      also, one more thing - disclaimer: i have no idea what i am doing.
    • Feb 20 2012 | 12:35 am
      More good stuff. Very handy patches to throw around at the end of signal paths. Is it possible to wrap an upsampled poly in another poly for dsp muting?
      Also, for the sake of tidying things up, is there any reason why the gen stuff is all over the place with cubic one? Like the gen object refers to an actual gen file, which then refers to another gen file. Is there a reason why the body/text of cubicnl.genexpr isn't written into a codebox straight up?
    • Feb 20 2012 | 9:59 am
      no need to put it in another poly~, you can just mute the poly~ it is already in. from the abstraction prepend 'poly' to get there.
      well, there is no good reason why the version i posted was all separated / abstracted like that, other than it was pasted together from a larger project where that does make sense. although, for me i always abstract - so that i can get to different versions of the code from wherever i am patching - e.g. any GenExpr code with a simple include. that is the main reason why all this is gen-ified, rather than just an MSP patch.
      attached is another version which only requires itself and the poly~ file, all other code embedded. it also makes muting explicitly clear in the helpfile. hope it is of use.
    • Feb 20 2012 | 10:23 am
      Yeah I thought that after posting it. My main patch is starting to hover around the 20-25% CPU usage so I'm trying to be more careful/efficient with the things I add, though I'm probably creating a misleading situation for myself when I turn on all the CPU heavy stuff at once and get the % way up.
      That makes sense for just using 'include' messages. Also trying to be mindful of the file count in my patch as it's already at 22 supporting files (polys and pffts mainly).
      I've have a gander at this when I get home. It does sound really good this one, and has a nice range of control. I found that harmonics above 0.01 seem to aggressively gate the signal, so I've left that super low.
    • Feb 20 2012 | 5:47 pm
      mute~ is handy as shit! I've never seen it before. It would've saved me tons of hardship as I've been wrapping everything expensive in a poly~ which takes forever......
    • Feb 20 2012 | 5:57 pm
      pcontrol is also worth knowing about.
    • Feb 20 2012 | 8:32 pm
      yes, as peter says, [pcontrol] is also very useful if you have other things going on. in true cycling74 style, the best [pcontrol] example is in the [mute~] helpfile. in fact they are some of the oldest objects i think. [mute~]/[pass~] are great - but you can get burned with third party externals that have not utilised them correctly (whereas [poly~]/[pcontrol] always get them). and NEVER FORGET YOUR INTERNAL [PASS~].
      @rodrigo, you mention "harmonics above 0.01 seem to aggressively gate..." - yes, it is actually a brutal offset to the signal, and you are looking at values between 0.001 and 0.009 really, although you can achieve special effects higher, which is why i left the range that way. it is dcblocked on output.
      i am glad you like the effect and that you may use it.
      @Wetterberg, and anyone else interested, attached is a collection of about 20 or so waveshaping algos side-by-side, to hack and re-use should you be interested. and you can use peter mcculloch's buffer writing method in this thread to turn them into lookups if you need.
    • Feb 20 2012 | 8:48 pm
      I don't know why I've never come across it before, I just learned the poly/mute method and went with that I guess. It was always so tedious to make something, then wrap it up in a poly just to be able to mute the dsp.
      Re: the gating/harmonics. I ended up using 0.008 I think, but as a fixed value.
      Ooh, I'll take a look at that waveshaper stuff.
    • Feb 20 2012 | 8:50 pm
      this waveshaper stuff is great and a very nice resource to be able to dip into. Thanks a lot. I can see hours of noise to come .
    • Feb 20 2012 | 10:28 pm
      @stkr: This is awesome. Many thanks. Please consider making this part of your toolbox, as it'd be a great resource for others.
    • Feb 20 2012 | 10:49 pm
      this is most excellent. I'm way too fond of way too many of these shapers already... :)
    • Feb 21 2012 | 8:23 am
      fantastic patches, thanks!
    • Feb 21 2012 | 10:40 am
      as a wise man once said: "in distortion lies truth" :)
    • Feb 21 2012 | 2:18 pm
      well, those are some great responses. maybe i need to look into this whole scary 'toolbox' thing.
    • Feb 21 2012 | 2:27 pm
      Most definitely! There's definitely a lack of these kind of 'bread and butter' effects.
      The only thing would be since all the files are clumped together in bigger gens it would be very inefficient for people with only the gen runtime (me included) as they can't single out the one they want to use.
      I only wish I was working more patches that need distortion.
    • Feb 21 2012 | 9:08 pm
      Not specifically distortion related but since it was mentioned in this thread, I'm having a hard time muting the dsp in a subpatch (on startup) that contains an FFTease object. Mute~ wasn't working so I tried the pcontrol method and still nothing. I can mute it manually but on load it turns on from default.
      I can wrap it in a poly I guess, but the mute/pcontrol method is so much more convenient.
    • Feb 25 2012 | 12:04 pm
      ok, it appears that this toolbox thing works in 'stealth mode', i.e., i have no idea if it is up or not. but this seems to work at this link:
      i added a .genexpr file, so that if you do not have a Gen license you can at least see the code in full and port to patching land yourself if needed. although, if that really does not sound fun, let me know which are your 'favourites' and i'll try and put them all into separate basic abstractions for you.
      @rodrigo, that is annoying about the muting, yes. usually this is because of an error in the third party object. however, those objects are made by one of the worlds external-making geniuses, so i doubt that. maybe it is a max6 issue. poly~ the only way for that unfortunately.
    • Feb 25 2012 | 12:18 pm
      I saw it come up on the rss feed so it's 'out there'. Thanks again for putting those things together, amazing resource.
      Yeah I just threw it in poly~ and sorted it out.
    • Mar 06 2012 | 9:55 pm
      Hmm, the upsampled cubic distortion seems to enjoy blowing up my audio for some reason.
      Every now and again I'll load up my patch and the moment I engage the distortion (muted with mute~/pass~) I got a pop, my meter goes (and stays) red, and I have no audio, until I turn off the dsp and turn it back on again.
      Any thoughts on what could be causing this?
    • Mar 07 2012 | 2:06 pm
      hi rodrigo. sorry about this. i had used that abstraction a lot myself before posting so i thought it would be fine for others.
      i have been trying to reproduce your problem and cannot. at first i thought it might be an issue with NAN's or denormals but it seems not. i may have found some strange behaviour of the [pass~] object though.
      could you tell me: - are you using [cnld4~] or cnld8~]? - are you using the abstraction's own mute~/pass~ system? or do you mean you have it inside yet another mute~/pass~ system of your own? - do you have your own gain ramping system on the muting command?
      if you are on [cnld8~] and using its own mute~/pass~, could you try instead using the internal [poly~]'s muting as shown in the helpfile, and report back? feel free to pm me if you'd rather.
      in the meantime, i will try and get to the bottom of it some more.
    • Mar 07 2012 | 5:34 pm
      Yeah it's weird. It's been quite inconsistent in terms of when it happens so that makes it hard to pinpoint. I have lots of other modules that are mute/pass'd and this is the only one that seems to blow up, though it could perhaps be related to what comes before or after it.
      I'm using the 8 version. I'm using the mute/pass that's there (sort of). I'm using a line~ and !-~ to bypass the audio (fading dry out and fading wet in).
      Not sure what you mean about the internal poly muting. I've not tried just muting the poly directly. It'd be nice free up all the DSP (the biquads/onpole) but if that makes it more reliable then I'm all for it.
      Here's the (slightly reworked) implementation I'm using.
    • Mar 27 2012 | 11:27 am
      Inspired by the amazing patches in the thread i had a go myself :) First in 5 but having upgraded last week i ported it to gen but i'm not too sure about the codebox-algorythm? It sounds different...
    • Nov 12 2013 | 1:08 pm
      great thread! I am a bit late to the party but big thanks to everyone for the info!
    • May 04 2017 | 5:05 pm
      Sadly all the awesome Max patches posted by STKR are expired. Could anyone possibly re-post them...?
    • May 04 2017 | 5:28 pm
    • May 04 2017 | 9:26 pm
      Thanks a lot MP.