FIR filter design functions

[jfsantos]

Add FIR filter design functions (window method, Remez exchange algorithm). These functions could be ported from Scipy.

[rickhg12hs]

In addition to what has already been mentioned, it would be nice to be able to design filters with finite word-length coefficients (MIP?), resamplers, and integrated filter/downconversion/decimate functions. Are there functions in the JuliaOpt packages that can be leveraged?

Edit This journal article shows some other interesting techniques.

[jfsantos]

That is a good idea. I have some Python code that I wrote for designing and testing fixed point FIR filters that can be translated. We can for sure rely on existing optimization packages to do the heavy lifting.

[jfsantos]

JayKickliter/Radio.jl has FIR design functions (based on windowing) and the author is interested in merging with DSP.jl.

I will also add a weighted least-squares design method soon, and I'm investigating some other possible methods based on convex optimization.

[JayKickliter]

Here's a package that implements stateless & state-preserving multirate filters. I moved the code out of my Radio package to make it easier to merge into DSP (if you want to). I'd be fine with keeping it as separate package, depending on what the JuliaDSP community thinks.

[JayKickliter]

Now that I have those resamples working, I plan on revamping the window-based design functions.

[jfsantos]

I think at least the FIR filter design functions should have a place in DSP.jl and not in an external package. Multirate may or may not be included, I still do not have an opinion on that. I'm a bit busy at the moment with travels and my doctoral exam, but I plan to take a look at this as soon as have some free time.

One thing that should be done is to replace the "enum-style" for filters with the type-style we use in DSP.jl, but that should take 5 minutes to fix. We also need to add tests to the design functions (I see you have tests for the package but they only compare the processed filters, not the filter coefficients).

[simonster]

I think fast and accurate resampling is of sufficiently broad interest that we should include the multirate functionality in DSP.jl.

[JayKickliter]

@jfsantos The filter taps design code was some of the first julia code I wrote, so I basically mimiced matlab/octave style. I agree with you about that. I also threw it into Multirate as an afterthought to get it out of Radio. The real goal was the resamplers. I'll write some tests that compare against the output from some other reference. It need to make sure it works so I can write resampler object constructors that create the filter for you, similar to GNURadio's python code.

Referencing your original post, it would be great to have have native Julia Parks–McClellan FIR design methods. I would offer to write it, but I don't understand the math at all.

[JayKickliter]

@simonster Thanks for encouragement in the other thread. I thought a pull-request required you have code that is ready(isn) to be merged.

[JayKickliter]

A really good place to find algorithim-references is Liquid-DSP. He has the best documentation I've ever seen for an open-source project.

[simonster]

You can submit a pull request whenever you want :smile:. You can always update it later. In Julia-land there is a well-established tradition of pull requests for work in progress.

If there are changes you know you need to make, you can make those before opening a PR, or you can submit the PR immediately and note that you're aware those pieces need changes. But once you're ready for input from others, you should definitely open a PR; it's the easiest way to let others see and comment on your code.

[ssfrr]

Just be careful with licensing on the Liquid-DSP stuff. That code is GPL licensed so we can't port it to Julia as part of DSP.jl (which is MIT licensed), and shouldn't even look at that code while implementing a Julia version.

[ssfrr]

Also, @JayKickliter , I don't think I've said yet that I'm super pumped you're doing this work. Thanks a lot! The github/PR workflow takes a little getting used to, so feel free to ask questions if you're not sure what the process is "supposed to be".

I like using the hub tool, which adds some nice github features to your git command line. The section "Example workflow for contributing to a project" might be helpful.

In case it wasn't obvious from @simonster's comment, when you add commits to the branch you're using for the pull request, they get added to the github pull request page so you can continue to work on the branch. That one of several reasons it's good to do work in a separate feature branch rather than in master directly.

[JayKickliter]

@ssfrr Thanks a lot. It was your demo that made me want to genericize the streaming filters for general use.

I don't want to get too far off topic here, but I thought of a demo involving AudioIO and DSP. If you go into a large room and record the sound of a starter pistol or clap some boards together, you can use that recording as the taps for a FIR filter. Whatever audio you process through that filter will sound like it was recorded in that room. I know when I first got interested in DSP I didn't really understand many of it uses. Some demos like that would be cool.

[ssfrr]

Yeah, that's a pretty widely-used technique in music production, typically referred to as a "convolution reverb". Usually you get the impulse response with a sin sweep instead of a real impulse because you can get better signal-to-noise, and probably fewer nonlinear effects. There are also a lot of impulse responses available for download on the internet. You can also get some very cool sounds by convolving with other weird sounds that aren't real impulse responses.

Because of the length of the impulse responses (cathedrals can be on the order of 10 seconds x 44100 Hz = a 441000-tap FIR) they're usually implemented as a partitioned FFT convolution for efficiency.

Anyways, agreed that would be a cool demo. In the short term it would be easy to load in a sound and impulse response into arrays with AudioIO, convolve them with your FIR code, and play it back with AudioIO. At some point it would be awesome (and pretty easy) to build a FIR AudioNode to run live sound through filters.

If you have some ideas on integrating the FIR stuff into AudioIO feel free to try some things out, or open an issue to discuss.

[rickhg12hs]

Would the SciPy license be compatible for translation to Julia?

On 9/1/14, Spencer Russell notifications@github.com wrote:

Just be careful with licensing on the Liquid-DSP stuff. That code is GPL licensed so we can't port it to Julia as part of DSP.jl (which is MIT licensed), and shouldn't even look at that code while implementing a Julia version.

---

Reply to this email directly or view it on GitHub: https://github.com/JuliaDSP/DSP.jl/issues/10#issuecomment-54079987

[simonster]

Yes, SciPy is 3-clause BSD which is compatible with the MIT license.

[JayKickliter]

Update: I've added the last filter I wanted to implement (Farrow) to Multirate. Now you can resample at any rate, even irrational rates like π. All of them handle one-time and batch-streaming operation. Next step is to initiate a pull request.

[simonster]

This will be awesome to have!

[ClemensFMN]

I stumbled across the discussion; I recently wrote a routine for designing FIR filters using the window method. It is here: https://gist.github.com/ClemensFMN/7cd12901cb30bab6d42e It needs some attention (error handling...) but are you interested in me opening a PR?

[JayKickliter]

It pays to ask: Liquid DSP is going to transition to MIT license.

[jfsantos]

We already have the FIR design functions that came from Multirate.jl, and @JayKickliter has a proposal for a firls implementation in other issue. I think we can close this issue for now.