Experimenting with FIRs

[steph_tsf]

Hello, I'm quite new with Flowstone and I would like to share various experiments using FIRs (Finite Impulse Response) filters.

FIR_16 (400 pix).png (53.8 KiB) Viewed 42311 times

There is a pink noise as source, grabbed from the old Synthmaker forum.
All FIR coefficients get randomly updated each time you press the trigger (red) button.
The audio output is in stereo, routed to the PC soundcard/speakers.
Left output channel is the unprocessed pink noise.
Right output channel is the FIR-filtered pink noise.
Playing with the left/right balance you will hear a clear difference each time you press the trigger (red) button.
Seems such FIR is working.

Is this a valid framework, for experimenting with relatively short FIRs, say maximum 16 coefficients?
Are there better ways to implement FIRs using Flowstone?

What about longer FIRs? I don't see myself drawing all the required signal lines, for a 128-tap FIR ...

I'd like to rely on the "Text Load" component for entering the FIR coefficients as individual Floats, into the Float array, from a text file residing on the harddisk. Is this feasible ?

[steph_tsf]

Attached is a FIR lowpass.

[steph_tsf]

Attached is a FIR highpass.

[steph_tsf]

Improved 2-ch audio analyzer featuring triangle windowing.
See attached files.

[MyCo]

Here is my contribution. It's a FIR filter core with up to 255 points. The filter is nearly completely done in code, for passing the coeffs in, I needed a workaround. The coeffs are loaded in sequentially (one coeff per sample), so there is atleast an initial delay that is as long as the nr. of coeffs. That can be compensated with a delay and plugin delay compensation, but that isn't included right now.

The DSP code can be highly optimised in Assembler. Right now it uses random access to the memory, which is extremly slow. In Assembler you could do sequential reads... although the code would be unreadable

[steph_tsf]

I went looking the STEM Examples Projects available in http://www.dsprobotics.com/support/viewtopic.php?f=82&t=1211&p=3853#p3853. There is a FFT plotter with a nice LIN(F) or LOG(F) axis capability. Unfortunately, the dB axis has wrong labels.

I solved this, adding explicit TOP(dB) and RANGE(dB) controls.
I also converted it into a 2-ch FFT analyzer. Now it displays a transfer function (frequency response only).

I used it for checking a 19-tap FIR filter. See attached .fsm.

[steph_tsf]

Here is my contribution. It's a FIR filter core with up to 255 points. (...)The DSP code can be highly optimised in Assembler. Right now it uses random access to the memory, which is extremly slow. In Assembler you could do sequential reads.

Many thanks for such clever serialization workaround. I'm interested in trying this in assembler. Any hints?

[MyCo]

I'm interested in trying this in assembler. Any hints?

The basic idea is, to convert all array indeces from the code into x86 integers, and store them somewhere. And when you need them you load them directly into the an x86 register and do your math in there so you don't have to convert between single and integer anymore and you could use bitwise operations to clip to the memory length. In the SynthMaker forum is an optimized delay code from Trog that you could use as reference:
synthmaker.co.uk/forum/viewtopic.php?f=9&t=10216&st=0&sk=t&sd=a#p75754

The most important thing for optimization: Optimize the code first, before you convert it into Assembler. My code version of the FFT was just the first shot, so there is propably some space for tuning.

I'll try to optimize it, but it'll take some time...

[MyCo]

OK, here is the optimized version. It uses only half as much CPU as the code version. Maybe there are some parts that can be optimized a little bit more, but it's really hard to find'em.

[steph_tsf]

99-tap FIR as simple as possible, coefficients loaded from a text file.