OT: "Convolution" Clarification

“Moving” convolution for the first, and “Real” convolution for the second.

take a look at alex harkers convolution externals (especially his no-latency convolution reverb), he has both time-domain and frequency-domain convolution objects: http://www.alexanderjharker.co.uk/Software.html

well, it doesn’t matter that much, I think time-domain vs frequency-domain matters more..
and if you choose your fft frame at least as big as your impulse response this is non-partioned convolution.

You can implement a realtime convolution reverb both in time-domain or in frequency-domain, the latter is computationally more efficient (if done well). However, frequency-domain only introduces a latency. However with Alex’s (partitioned) trick to do a combination of both enables him to do no-latency convolution reverb while taking advantage of the computational benefit of frequency-domain processing.

I’ve never bothered to code up a convolution with two live inputs and zero-padding to prevent time aliasing to see if it sounds better or not, so I’ve no idea, but I’d be interested in the results if anyone does.

This is on my todo list. Might be able to get to it in the next couple weeks, but most likely I’ll be writing this external in March. I’ll post a link when it is ready.

True, but these days I really prefer working with FFTs in C than in MSP.

Well, as we’ve discussed in other threads, I’ve got a need for speed and like wrapping up complicated processes in C externals for efficiency reasons—although I’ll often prototype my non-FFT signal processing ideas in MSP if that is simpler than prototyping in Octave or C.

One reason I prefer working in C than MSP for FFT stuff is that for many types of processes the sequential signal based approach of MSP is not ideal for working with frame based data like DFTs. If I want to design an effect that either requires access to the bins in another order or to all of the bins before outputting the DC bit to fftout~ or ifft~ then an additional frame of buffering is required which increases the latency of the process (not ideal for processing of live performance on acoustic instruments when you already have the latency of the sound card, I/O buffer latency, and the latency of the FFT analysis. When working in C (or Octave) I’ve got easy access to the DFT as an array that I can do whatever I’d like with it.

The other reason is the fact that FFT size and window size can not be decoupled with pfft~—making things like zero padding requiring the use of fft~ instead. I know any sort of funny windowing stuff I’d want to do could be done with fft~ and ifft~, but a couple of years ago when starting to write my general C DSP library I wrote some wrapper functions for handling DFT and iDFT that handle everything for me (i.e. any sort of combination of FFT size, window size, window function, overlap, and buffering signal vectors that are different sizes than the window size—for now I’m stuck with power of 2 signal vector sizes which is fine for MSP but I plan to fix that so I can use it in any sort of environment I need).

So these two things combined, it is much easier for me to work in C than MSP for doing FFT stuff. After explaining some of this stuff to a few friends of mine who are Max users but not C programmers I got inspired to write some externals to help users work with DFT bins out of order in MSP. I’ve got the functionality all mapped out in my head, but I’m stuck on how to build secondary DSP chains (the few experiments I tried to figure this out in December did not seem to work and I’ve been meaning to ask about this on the Dev forum when I had time to properly formulate my questions. I’m assuming starting your own DSP chains is how your dynamicdsp~ stuff works; do you have any tips you could share—on or off list—?).

Roth,

have you managed to complete this external yet? Would be interested in using a partitioned convolution….