Digital LPF with adjustable resonance and cutoff

[volting]

Im designing a MIDI controlled digital monosynth synth based on a dsPIC33F, at the moment it has three NCOS, an LFO and ADSR.

Iv been looking for the last few weeks for algothrithms, code, theory etc. (basically anything) on digital filters that can have adjustable resonance and cut-off, but Iv come up with nothing useful -maybe I'm missing some terminology which would provide better search results!

I'm in coding C using MPLAB C30, and plan to utilize MCHPs dsp library if possible, so solutions compatible with would be preferable, but really I'm just looking for anything to get an idea of how I can do this.

[JovianPyx]

My favorite is the digital State Variable Filter. It has 2 pole response and can be any or all of bandpass, lowpass, highpass or bandreject. One parameter controls Fc, another parameter controls Q.

http://www.earlevel.com/main/2003/03/02/the-digital-state-variable-filter/

http://www.musicdsp.org/archive.php?classid=3#142

I used the block diagram to construct the code to implement it in an FPGA.

Note that the Q input is really 1/Q. With my synths that use this filter, I use a patch editor written in VB.NET which lets the user select a Q value which is converted to 1/Q before sending to the synth. This relieves the synth of having to do a divide (which is time expensive). The other thing I should mention is that the F input is not exactly Fc, you can see that the computation involves the sine function, but because the filter is useful only up to about 1/6 of the sample rate, it turns out that the value is linear enough at the low end to use directly as a pitch control (as in when the filter is used as a resonator) for several octaves (I got 5).

When I started doing this stuff, I too had a need for a filter with easily adjusted Fc and Q. I found lots of filters, but most required complex arrays of coefficients and that to change the cutoff or Q would require tables of data that needed interpolation.

The main drawback of the SVF is the fact that it doesn't work well with Fc set above 1/6 of the sample rate. For 44.1 KHz, this is 7.35 KHz. For this reason, I run those synths with a sample rate of at least 100 KHz, but many are 200 KHz or 250 KHz (which I know you can't do with the built in DACs on dsPIC - but they will operate at 100 KHz).

Another thing to remember about this type of filter is that it suffers from Q enhancement. A static Q value will not have the same resonance at all values of Fc, rather, resonance increases as Fc increases and the filter acts as if the Q were increased. Also, the resonance causes amplification of the signal at the frequency of Fc. This means that if the level of the system is set to just touch the upper amplitude limit with Q = 1.0, increasing the Q will cause distortion either from wrapping or from clipping if clipping is implemented. So this must be considered. I solve this by limiting the level of the input so that at maximum intended Q, the signal doesn't distort.

[volting]

Thanks for your reply, rich with useful info. Funnily enough I had read about SVFs but obviously not enough -I didn't realize they allowed adjustment of Fc and Q.

At present I'm running the DAC at 77.4K to allow for enough cycles for synthesis between DAC loads, I guess once I implement the filter Ill do some testing to determine the trade-offs to see if its worth increasing Fs (prior to reading your post I had been considering lowering it!).

[volting]

I tried to implement the algorithm, hardcoding the paramaters for testing... I reduce the amplitude of the sample before filtering to avoid clippling, but all Im getting is noise on the output. Does signage matter to this algorithm, as my current setup is for signed ints for sample and DAC..

Below is a snippet of the code, which resides in the DAC update ISR. ISR execution time is fine, so this is not the problem.

[JovianPyx]

For integer based DSP there's a some important points:

As with floating point, the algorithm needs to deal with signals that range between -1 and 1. That probably makes your face screw up because you're dealing with integers and those values allow for only 3 DAC values -1, 0 and +1.

While the arithmetic the processor will do is integer - we fool it a little by "pretending" the integers represent fixed point numbers in the range of -0.99999 to 0.99999. This means that (for 16 bits) 0x3FFF is about .999. This has an odd effect on multiplication (and division).

What happens if we multiply 0.999 by 0.999 ? Well, in floating point, the answer is 0.998001.

Now do this: 0x3FFF * 0x3FFF and the answer is: 0x0FFF8001 OH NO... OVERFLOW - there are more than 16 bits there!

What is needed is to then right shift the result by 15 bits to get the result back into the 16 bit range and preserve fixed point magnitude. This means that while your processor may allow 32 bit numbers, you can use only 16 of the bits (now knowing that 16x16 bit multiplies can result in 32 bit products). Note that the right shift must be arithmetic and not logical. Logical right shifts will insert zeroes from the left where arithmetic shifts will shift in a copy of the sign bit.

I've never used a divide operation in DSP, so I don't have a well thought out explanation for how it's done - I work with FPGAs which aren't divide friendly, so I avoid them at all costs... That doesn't mean that DSP can't work, it does. On the odd occasion where I must use a divide, I use either a table or if the divide is by a power of 2, I do arithmetic right shifts.

[volting]

You are correct the problem is overflows. I had been avoiding using fixed math (sticking to what I know) probably at my own peril! and almost have this working without it.
When Q1 is less than 0.5 or Fc is not too low (havent done alot of testing here but its fine if its over 1Khz),
the output is as expected for all input frequencies, but if these conditions arent met then at higher input frequencies say over 1500Hz a lot of sharp edges are introduced which to me
looks like overflows are occuring somewhere.

This (the below code) is where Im at, at the moment which Ill admit looks bit ugly...
The builtin functions for multiplication return long ints and the numerator parameter of the builtin signed division function is also a long int,
so should this should take care of overflows and in most cases it does.
I think the problem is in the third line from the bottom,
The max possible return val of __builtin_divsd(__builtin_mulus(F1_num, H), F1_denom) is 29490
i.e (9*32767) / 10 = 29490, and B can be anything up to 32767 so obvious overflows here, not really sure how this could be avoided.

[JovianPyx]

I'll just write this inside code blocks because it's being a pain in the rear... It keeps eating and changing what I write ... GRRRRR

[volting]

Iv been busy, so I havent been able to spend much time on this,
but today Iv managed to get it working.
I switched to using fixed point math, and made better use of the DSP engine by using some of __builtin functions that are C wrappers for assembly instructions. To avoid over/underflow addition and subtraction is performed using the Microchips fixed point library functions.

Cutoff adjustment sounds a little bit granular at the moment, but I think that due that fact that adjustment value is been scaled from 10 to 16bits. The reason its scaled from 10bits is that its coming from the ADC of PIC18F. The PIC18F is handling all the i/o lcd, switches, pots, midi etc.. The pots are temporary, Im waiting on rotary encoders which should give me as much adjustment resolution as I need.


The code ain't pretty but it works!!!
It generates 74 instructions and runs at approx 1.88us at FCY = 39MHz.

[JovianPyx]

Ah! Very good! I wasn't aware you were doing this on a PIC. I've got a project I want to do on a dsPIC that will use the same filter! But I will be doing my project in assembly, I "feel" I have more control over what is going on that way.

It sounds like you are using a PIC for mundane stuff and dsPIC for DSP... yes?

[volting]

Yes your right, Im using a PIC18F43K22 for processing all IO (except audio of course). It serializes all the inputs into a simple command set which it pipes over SPI to the dsPIC, using a synchronous protocol like SPI eliminates the overhead of software syncing and buffering of the the midi and other commands. The other nice thing about using the PIC18F is that its a 40pin IC (35 GPIO) so I can connect a number of switches, rotary encoders and a parallel interface LCD without the need for shift registers , muxes or port expanders etc...

I have been following your thread on your dsPIC synth, ...good to hear your still working on it.

Coding the DSP intensive stuff in Assembly (i.e writing C callable assembly functions) is probably the way to go I think as you cant really gain access to the DSP engine through C unless you use the builtin functions, even though there is one for each DSP instruction, and from what I can tell using the builtin function is the same as using inline assembly, I think it would be possible to write more efficent code in pure assembly. Some day soon (when I run out of cycles..) Ill learn it, until then Ill see how far I can push it with C & the builtins, --I just halfed my DAC ISR time by switching to fixed point math, and therefore removing any divide instructions which I just found out take 18 cycles !! so this has given me a lot of breathing room.

Thanks again,
V