## Parametric EQ

Sound synthesis techniques, DSP and related mathematics

Moderators: electrogear, exonerate

### Parametric EQ

Hi all,

I have been experimenting with SM's parametric EQ - the basic one that comes with the program.

I have noticed major instability issues with it, move the gain up/down a bit fast and the audio signals becomes completly corrupted.

I wonder why is that and what can be done to avoid it in a future design parametric IIR EQ of my own.

Any suggestions welcomed.

Thanks,
Rocko
rocko
essemist

Posts: 59
Joined: Mon Dec 07, 2009 5:25 pm

### Re: Parametric EQ

I do not have SynthMaker on the machine I am at right now, but if I remember correctly, the stock param EQ calculates the coeffs in green. It makes the coeffs jump around if you move parameters to quick. Green math is just not responsive and precise when it comes to tings that should happen fast.
Take a look at this:
viewtopic.php?f=7&t=592&st=0&sk=t&sd=a&hilit=rbj
In theese examples the coeffs are calculated realtime at sample rate. I you think it consumes to much CPU read about 'hop' in the user guide under the code section. The coeff part of the code can be calculated inside a hop like this:

Code: Select all
`hop(64) // The number after hop must be a power of two: 2,8,16,32,256.....{Coeff calculations in here}Realtime filter code here`
Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke, "Profiles of The Future", 1961 (Clarke's third law)

http://www.audioteknikk.net

tor
essemilian

Posts: 462
Joined: Wed Apr 14, 2010 8:52 pm

### Re: Parametric EQ

Hi,

So green calculations are slower than sample rate?
My knowledge of computer science is low, but I always thought sample rate (~44100 Hz) is slow when compared to computer calculations, so my "understanding" was that green math is faster than 44100 Hz.

I guess I got it wrong.

Anyway, you suggest to do the calculations on "code" and put it in "hop" to avoid CPU load.

Correct?

Rocko
rocko
essemist

Posts: 59
Joined: Mon Dec 07, 2009 5:25 pm

### Re: Parametric EQ

rocko wrote:Hi,

So green calculations are slower than sample rate?
My knowledge of computer science is low, but I always thought sample rate (~44100 Hz) is slow when compared to computer calculations, so my "understanding" was that green math is faster than 44100 Hz.

I guess I got it wrong.

Anyway, you suggest to do the calculations on "code" and put it in "hop" to avoid CPU load.

Correct?

Rocko

Green is slow under synthmaker. And maybe not precise as enough. the fact is that Green is easy to use insted of code that requires a bit more knowledge.
http://www.thecorestylerz.net
Sound Design, synth development and websites building...

SM COMMUNITY IS MOVING TO
www.synthmakers.net

CoreStyler
essemilian

Posts: 474
Joined: Sun May 23, 2010 1:25 pm

### Re: Parametric EQ

Green calculations are performed only when their input changes, so they do not consume CPU as long as settings remain constant. Even during tuning by hand, the input will be recalculated not more than a few dozens times per second. I recommend Trogz tutorial on triggers.

Green components, however, are tiring to use.

Warmonger
essemist

Posts: 172
Joined: Wed Jul 20, 2011 5:40 am
Location: Warsaw, Poland

### Re: Parametric EQ

[quote Green components, however, are tiring to use.[/quote]
Tell that to Billv how he does what he does with green is
so never say never about ant type of flow.
Though my rule of thumb static (read once calcs) or very slow = Green
audio rate = Stream
compiled stream plus stuff you can't do with stream primatives = code
optimised code = ASM
Or so the wiki apppears to say. Something like trogs trigs giving a more comprehensive overview would be nice
though not definative as I mentioned Billv does amazing things in green but then he's from the land that gave us severed heads (a band in case you were confused) and the fairlight though they scorned that in favour of 30 foot tape loops
Xtinct
essemist

Posts: 182
Joined: Thu Feb 10, 2011 11:06 pm

### Re: Parametric EQ

The problem with the filters is down to synchronisation rather than outright speed.

All of those co-efficients going into the filter have to be in perfect harmony to generate a good filter response.
Green signals are designed to be 'low priority' so that they use very low CPU when they are not changing, and so that going mad with the controls doesn't eat up CPU and cause the audio sections to start glitching.
Trouble is that when a control is connected to lots of maths stuff, sometimes SM cannot get all of the maths done in the space of a single sample - and the code then 'sees' the values changing at different times instead of all at once.

So for a short time, the combination of co-efficient values is not 'valid' and creates the wrong filter response. Inside the filter are some very carefully tuned feedback loops - and just like any feedback loop, they will 'howl-round' if the values make the gain too high. So the filter can get very unstable until the values synchronise again - and even for a short time after, as the glitch 'fades away' around the feedback loops, just like the echoes in a delay effect.

The hopping method is usually the best tactic to sort this out. Although hopping will still lower the CPU, and slow down the control changes, it makes sure that every co-efficient value changes at exactly the same time, so that the filter is always working with a stable combination of values.
Feel free to use any schematics and algorithms I post on the forum in your own designs - a credit is appreciated (but not a requirement).
Don't stagnate, mutate to create. Without randomness and serendipity the earth would be just another barren rock.

trogluddite
smychopath

Posts: 3024
Joined: Mon Oct 20, 2008 3:52 pm
Location: Yorkshire, UK

### Re: Parametric EQ

trogluddite wrote:The problem with the filters is down to synchronisation rather than outright speed.

All of those co-efficients going into the filter have to be in perfect harmony to generate a good filter response.

This is what many who build equalisers have difficulty understanding. Everything is based on a principal. Frequencies are far more complex than you might imagine when accuracy is the key. The acurracy of green is no better or worse than code. When your projects become larger in size code is less time consuming at the expense of more CPU drainage. Green is lower CPU usage at the expense of taking more time to create large projects.
Dell
essemilian

Posts: 474
Joined: Sat Sep 26, 2009 6:45 pm
Location: New York