Hello 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, CIPIC...). 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 Input-Output delay",AES.org)but.... 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. Thank you. 2010/6/7 David <[email protected]> > 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, > > David > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
