Hi there,

I am trying to reasonably emulate a bitcrushing/downsampling/waveshaping guitar pedal. After having put together those three functions, I realised (looking at videos on the net - I don't actually owe the pedal) that when bit depth/samplerate are set to maximum (best sound 'quality') and a 'unitary' wavetable is used (doesn't modify anything in the sound), the actual pedal still provides a broad "distortion/fuzz" sound. (of course the video provides clean and effected sound, ensuring comprehension)

As the sound I actually get with my patch is deceiving yet logical, I came to the conclusion that the clipping stage has to be 'upgraded'. I replaced the previous [clip~ -1 1] with a [tanh~], and I found it interesting but still far from satisfactory.

Googling about analog fuzz/distortion/overdrive gave some hints, but I'm still far from being able to put together a 'simplified physical model' of such a fuzz/distortion.
So I will try to start with a good transistor electronics book, to see what is the difference between germanium and silicium devices, and see if I could use some caracteristic curves to build a [diode~] and a [transitor_amplifier~] objects.

Any help appreciated !

Thanks,

Nau

I personally find [tanh~] to be very reasonable for distortion. Many of the papers I've read on emulating distortion pedals show that the waveshaping curve is quite similar to tanh, enough that they use it in their models. You do have to seriously crank the signal going in, though. Even boosting it 30 dB gives a pretty light distortion. Crank it!

Also, distortion is highly nonlinear, meaning it will produce many more partials than what is already present in the signal. These partials will alias, which can alter the sound of the distortion in a way that you might not want. So it's a good idea to have the distortion in an upsampled patch. Filter the input at below the parent's Nyquist frequency (because upsampling causes the spectrum to repeat), apply the distortion, and filter again before the output to minimize aliasing. I should also mention that upsampling causes the energy of the original signal to be spread out, and the filter will get rid of most of it. So you will need to make up for the lost energy by multiplying the input by the upsampling factor.

I highly recommend this paper:

https://ccrma.stanford.edu/~dtyeh/papers/yeh07_dafx_distortion.pdf

It dissects and explains models for the Boss DS-1 and Ibanez Tube Screamer. Even if you don't understand all the math (I don't), there are some nice block diagrams to ease the pain. I've made an emulation of the DS-1 in Pd based on this paper (though I need to clean it up as it's doing more work in the upsampled part than it needs to), and it sounds pretty close to the Distortion unit in Guitar Rig, which has the same parameters. There's also a unit in Guitar Rig called Screamer, also with the same controls. I'm interested in how similar that turns out to be, too.

Simply awesome, Maelstorm.
Thank you so much !

Nau

Hi,

I am trying to use [rpole~] and [rzero~] objects to make a (not pre-warped thus with foldover) approaching filter for the transfer function H(s) numbered 15 page 3 of the article previously mentionned by Maelstorm.

Using the technique explained in http://en.wikipedia.org/wiki/Bilinear_transform , I'm trying to calculate the coefficient values for those [rpole~] and [rzero~] objects.
The first try lead me to coeffs that give me a plot (using the Miller Puckette's filter_graph2 subpatches) which is far from the one expected.

Tomorrow I'll give another shot, but advises would be appreciated !

Thanks,

Nau

Did you try just substituting the mappings they give on the page before? I find it easier to understand implementation-wise than the Wikipedia page. To be honest, though, I just used two [hip~] objects for that part.

But if I were to try and design it in Pd, I wouldn't get into [rpole~] and friends for that one. It's a second-order filter, so it would be easier--and more computationally efficient--to just calculate the coefficients and plug them into [biquad~].

(15) can be re-written as:

s^2

s^2 + (ω1 + ω2)*s + ω1*ω2

So now you have the s-domain coefficients needed for mapping to the z-domain using equations (4)-(9). One thing to remember is that [biquad~] assumes A0==1, so once you calculate the coefficients using (4)-(9), you'll need to factor out A0 from all of them (i.e. divide them all by A0). And then, there you go, biquad coefficients for a BJT frequency response.

Yop,

I'm on the way ... made a patch with all the calculations, but I have to debug it.
We'll see that tomorrow in the evening !

Thank you for the input.

Nau

Hi,

I figured out what was wrong in my patch. The calculations were good except that I had to multiply either fb1 and fb2 by (-1) to make it work.

I retreived this information from some objects Maelstorm's posted here : http://puredata.hurleur.com/sujet-5678-blending-blending-filter-graph.

I never found info about which H(z) equation does the [biquad~] object rely on. Now I see that the denominator is written as a substraction rather than an addition, just a matter of convention. Maelstorm, can I ask you where you picked this peculiar info?

I post here a 'didactic' patch that implements the BJT stage and draws a graph of it. This shows that the 'prescribed implementation' is very similar to the 'two [hip~]' implementation used by Maelstorm.

I'm glad I learned a bit about all that stuff, now I'm going furher with the opamp gain stage ... Maelstorm, did you use the method described 'in (9)', which is explained in an american patent document, or just the 'classic' one with upsampling ? I'm gonna try the 'classic' first

Thanks,

Nau

http://www.pdpatchrepo.info/hurleur/bjt_stage.pd

Hey nau,

Glad to hear you got it working! I don't have time to look at it right now, but I'll try and answer some of your questions.

@nau said:

I never found info about which H(z) equation does the [biquad~] object rely on. Now I see that the denominator is written as a substraction rather than an addition, just a matter of convention. Maelstorm, can I ask you where you picked this peculiar info?

Typically, a biquad filter is defined as subtracting the feedback part in the difference equation, and I don't really know why that is. But, you don't always see it defined that way, so you have to look out for it. Also, the conversion from the difference equation (y[n] = ...) to the transfer function (H(z) = ...) causes the signs of the feedback coefficients to be reversed, so subtraction in the difference equation becomes addition in the transfer function. More confusion. In fact, it caused quite a bit of frustration when I was making those filters. I'm not sure if the comments in those patches are 100% correct.

Anyway, it turns out, [biquad~] is one of the filters that doesn't follow that convention. The help file gives the difference equation in the more confusing Direct Form II. I'm guessing it's because Miller wanted to illustrate how it's implemented, since Direct Form II can be done using only two delays instead of four. But the results are exactly the same, so I don't see why that matters from the user's end. Anyway, in Direct Form I (as it's more commonly seen), [biquad~]'s difference equation is this:

y[n] = b0*x[n] + b1*x[n-1] + b2*x[n-2] + a1*y[n-1] + a2*y[n-2]

Which, in the z-domain, becomes:

b0 + b1*z^-1 + b2*z^-2
H(z) = -----------------------------
1 - a1*z^-1 - a2*z^-2

So, in order to make that line up with convention, the signs in front of a1 and a2 should be reversed.

The Wikipedia page on digital biquad filters mostly talks about the difference between Direct Forms I and II, and also gives the more conventional form:

http://en.wikipedia.org/wiki/Digital_biquad_filter

Maelstorm, did you use the method described 'in (9)', which is explained in an american patent document, or just the 'classic' one with upsampling ?

I just upsampled. I haven't taken a look at that patent. But my impression from the wording of the paper is that (9) uses upsampling, too.

Thank you so much Maelstorm !

Ok. I got the different stages working.
So if I want to do good work, I should 'encapsulate' these operations in a subpatch and upsample, I gess.

I read on wikipedia that I should upsample (a lot), distort, low-pass, and then downsample.

Could anyone give me good 'values' for those operations ?

Thanks,

Nau

You actually should upsample, lowpass, distort, and lowpass again. The spectra of digital signals are periodic; it's technically not limited to the sample rate. The sample rate determines the size of the period. For real signals, you have frequencies from 0 to the Nyquist frequency, and then everything between Nyquist and the sample rate is a mirror image of the spectrum below Nyquist (you could think of them as the aliased frequencies). That defines one period, and it gets repeated further up the frequency range. In other words, you have the spectrum from 0 to SR, and that gets repeated at SR to 2*SR, and again at 2*SR to 3*SR, and so on.

Now, when you upsample, the parts of the spectrum above the original Nyquist will fall below the new Nyquist. And when you send it through [tanh~], those frequencies will produce new frequencies, some of which will alias in the new sample rate, and some of which will fall below Nyquist when you downsample back to the original sample rate. You probably don't want that. So, you'll need to filter after you upsample to remove the repeated spectrum. And the [tanh~] will produce so many partials that you'll need to filter again before you downsample.

I would recommend upsampling by a factor of at least 8. You'll still get some aliasing, but what gets aliased will probably get masked. I think Pd only lets you upsample by powers-of-two, so the next one would be a factor of 16. That should be high enough, though it could be cpu intensive. As for the filters, they should just be far enough below the original Nyquist so most or all of what is above it is filtered out. I would recommend using [lp10_cheb~] for this as it has a very steep roll-off. You could probably set it to about 18kHz without aliasing.

Thank you, Master !

Hi there,

I am testing the upsampling method.
I got an upsampled version of my processing working, but as I like seeing things in addition to hearing them, I made a filter graphing patch using Miller's H12 patch.

And back to very basic testing ...
The first test here is with a [hip~ 2000], and I graph it with or without upsampling (8 times). The response curves are very different ! (no cheb filtering yet here, just a basic test) !

Why is this ?

Thanks,

Nau

http://www.pdpatchrepo.info/hurleur/upsample_filtering_test.pd

It's the upsampling itself that's causing the problem. When you upsample, all the new samples are set to 0. So, when you upsample by a factor of 8, you'll have the original samples with 7 zeroed samples in between them. One of the purposes of low-pass filtering right after upsampling isn't just to get rid of the repeated spectrum; it also smoothes out those zeroed samples to get the signal closer to matching the shape of the original. So if you low-pass the upsampled filter and multiply by the upsampling factor (because, remember, you need to make up for the lost energy being filtered out), you'll get something closer. In the attached I've added that. You'll see it's similar except for the ripple that the chebychev filter adds.

Also, if you just change the sample rate in the original (non-upsampled) part and plot the response, you'll again see what you'd expect since the generated signal is already at the high sample rate. You'll have to save and reopen the patch for it, though, because the butterworth abstraction only check for the sample rate on load.

http://www.pdpatchrepo.info/hurleur/upsample_filtering_test.mmb.pd

Is there a way to do this with FIRs? I would think there should be a more "modern" alternative to Chebyshev filters.

Hi acreil,

it's interresting ... by now I'm using article https://ccrma.stanford.edu/~dtyeh/papers/yeh07_dafx_distortion.pdf as a thread to follow and learn more about filters, and the 'upsampling method' is just one of the two strategies proposed in order to "fight" hi-freq foldover. I am interrested in any input about 'best low-pass filter to use' (I was wondering wether elliptic was not another good choice), but I think I won't spend many evenings in trying to figure it out, as I had already planned to study (and experiment?) http://www.freepatentsonline.com/5789689.pdf .

In the prev. cited article, they propose "better design methods" that can be found in http://eceweb1.rutgers.edu/~orfanidi/ece348/peq.pdf . This will be my next step in my learning journey ...

Thank you acreil,
Thank you Maelstorm,

Nau

Older hardware uses high order Elliptic or Chebyshev (analog) filters as anti-aliasing filters before or after a DAC. Modern sample rate conversion is usually done with an FIR filter, which can be made (at some computational cost) to have near ideal performance- very steep slope, very little pass band ripple, and no (or minimum) phase shift. I'd rather use an FIR for general purpose band limiting and reserve the Elliptic or Chebyshev types for applications that require "character", i.e. an emulation of a vintage reverb algorithm.

Sure, you could use an FIR filter, but I tend to shy away from FIR filters for this because they would have to be very high order and in an upsampled patch, which makes them computationally expensive. But, yes, if you want to preserve phase then that's the way to go, though for distortion I'm not sure how important that is.

Ok. Now I need log/log scales to 'visually control' correctly transfer fonctions (I need to find correct weight to chain low/hi pass first order stages to get the desired tone section.
If I remember well (can't find back the topic where I first read it), it's difficult (impossible) to render an 'horizontal axis logarithmic scale', so the best would be vectors loaded in Matlab or so. As I work under linux, I'll try scilab. A brand new world to discover !

Nau

My [filterplot.mmb] abstraction is log-scaled. Just plug them in as biquad coefficients.

http://puredata.hurleur.com/viewtopic.php?pid=24281#p24281

Doh !

I remember now that you said in another post that you were to post it in the 'patch section' ... which I follow much less than this one. Sorry and thank you Maelstorm !

Nau