wheeheee

I tried out `designRateConverter` in MATLAB, although I'm not familiar with MATLAB code, and got this out (which doesn't look like the resampled + bandpass-filtered signals above?). It seems that...

I'm of the opinion that it's better to treat heterogeneous axes as offset by default if any are, since as you've found `similar` expects that too. But maybe it's easier...

> Hm, regarding the mixing of offset-ness among inputs, I wonder whether the current behavior is what we want. I've come around to disallowing mixing among inputs (permanently), after #586....

Hi, I can also somewhat reproduce. But I don't get a `BoundsError` now, not even with `julia --check-bounds=yes`, instead characters just get deleted from the REPL when I input something...

In #598 @dlfivefifty asked if convolutions could be moved out into a separate package. This PR would make it easier to do that, if the decision is made. One benefit...

I think (among others) ApproxFunBase.jl and Korg.jl also use only `conv`. Don't know if the maintainers are ok with being pinged?

> I can speak for ApproxFunBase. It's fine to ping me 😂 oh man, I saw jishnub's icon and thought that was it 😅 > `Polynomials` would likely benefit from...

There will be some in 0.8. You can find some of them in the milestone here: https://github.com/JuliaDSP/DSP.jl/milestone/3

I don't see a problem with that but what organisation should that be under? It might also make sense to ask around ImageFilters because they already have a slicker API...

I was thinking that convolutions aren't a DSP-only thing, and currently there aren't a lot of features, so claiming that package name might bar others from putting it to another...