[Numpy-discussion] "Dynamic convolution" in Numpy
arthur de conihout
Mon Jun 7 08:31:26 CDT 2010
thanks for all your answers. I had a look at some references in this field.
Mostly in R. Nicoll Monograph on Binaural Technology, which is the best
recent overview i could find (on AES). All the solutions mentionned in the
ones you submitted are included ;)
You might do better with interpolating in polar coordinates, though
you might have phase wrapping issues.
It appears that filters interpolation gives the best results by operating a
reconstruction by basis functions using for example spherical thin plate
splines performed separately on the magnitude and phase spectra.
There is no right way that I know of, it really depends on what you are
doing. The big issue here is that a filter which changes is obviously
not time independent anymore. For IIR, this has the unfortunate
consequence that even if your filter is stable at every interpolation
point, transitioning from one to the other can still blow up.
You re so right and here is given cross-fading as a "convenient" solution as
dynamic update of filters requires the rapid commutation between sets of
coefficients leading to signal discontinuities. I'll have a look at
J.Dattorro's tutorials on effect design.
If you have, or can generate, a lot of filters, then at least you can
evaluate the quality of the interpolation.
I m actually using public HRTF databases( there are plenty of :IRCAM,
It may be pretty cool to have an implementation of scipy
I think it to :) i would love trying my luck with the zero-delay Gardner's
algorithm(in the same prolific years as Dattorro...) which lead to reduced
convolution delay.(Cf. W.G Gardner,"efficient Convolution without
my present problem is even more simple. I actually get head
position(head-tracking) then deduced associated filters(from a public hrtf
database), convolve them with a short stimulus(0.25s) and then play using
audiolab.play on numpy arrays. And this process is so long that i can't even
get an "unproper" solution(without considering interpolation and filtering
on long stimuli using filters commutation...) just playing short stimuli
according to head position.
Should i code parrallel convolution and play? i think i also multiplied
operations cost in the part of the code getting proper filters filenames
according to transmitted position information(i m using a wiimote IR camera
for my head-tracking solution).
So before i go further and i would love to, does anyone could give hints on
these basis points?
I can provide the code i m using even if it's really messy...due to my
recent dealing with coding.
2010/6/7 David <firstname.lastname@example.org>
> On 06/07/2010 12:08 AM, Anne Archibald wrote:
> > I think the kicker is here: what is the right way to interpolate
> > between filters?
> There is no right way that I know of, it really depends on what you are
> doing. The big issue here is that a filter which changes is obviously
> not time independent anymore. For IIR, this has the unfortunate
> consequence that even if your filter is stable at every interpolation
> point, transitioning from one to the other can still blow up.
> For filters used in music processing, it is common to have filters
> changing really fast, for example in synthesizers (up to a few hundred
> times / sec) - and interesting effects are obtained for filters with
> very high and concentrated resonance. The solution is usually a mix of
> upsampling to avoid big transitions and using filter representations
> which are more stable (state-based representation instead of direct
> filters coefficients, for example).
> I don't think it is directly applicable to your problem, but the series
> of papers by Dattorro ten years ago is a goldmine:
> "Effect Design Part 1|2|3, Jon Dattorro, J. Audio Eng. Soc., Vol 45, No.
> 9, 1997 September"
> > As far as convolution, as David says, take a look at existing
> > algorithms and maybe even music software - there's a trade-off between
> > the n^2 computation of a brute-force FIR filter and the delay
> > introduced by an FFT approach, but on-the-fly convolution is a
> > well-studied problem.
> It may be pretty cool to have an implementation of scipy, now that I
> think of it :) One issue is that there are several patents on those
> techniques, but I was told there are ways around it in term of
> implementation. Not sure how to proceed here for scipy,
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion