Parametric EQ

[rocko]

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

[tor]

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


[rocko]

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

[CoreStyler]

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.

[Warmonger]

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.

[Xtinct]

[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

[trogluddite]

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.

[Dell]

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.