[sdiy] IR Reverb

[Eric Brombaugh]

That's correct - window, FFT, multiply, IFFT, overlap & add.

Now do that multiple times at different window sizes and time offsets, 
sum up all the results. Amazingly enough, despite all the hokey-pokey it 
ends up being fewer operations than a straight FIR.

Eric

On 02/16/2018 11:48 AM, Tim Ressel wrote:
> Ah, okay. But you have to also do inverse FFTs, yes? So the FFT gets the 
> input into the frequency domain which gets multiplied by the IR, then an 
> iFFT gets you back to time domain. Overlap reduces congruity issues. Am 
> I getting that right?
> 
> --tim
> 
> 
> On 2/16/2018 10:11 AM, Eric Brombaugh wrote:
>> Yes - a brute force requires 100k MACs / sample.
>>
>> An FFT approach reduces the the total number of multiply / add 
>> operations required to do a convolution due to the optimization of the 
>> "fast" algorithm. FFTs reduce the N^2 operations of a DFT to N*log(N), 
>> so the larger the transform you can get by with, the more advantage 
>> you'll see. The downside is that FFTs introduce a lot of latency, so 
>> to get around this transform-based convolution engines will typically 
>> subdivide the process into a small & fast FIR to handle the early 
>> results, followed by gradually larger and larger FFTs to handle the 
>> later results.
>>
>> Eric
>>
>> On 02/16/2018 10:53 AM, Tim Ressel wrote:
>>> Thanks for all the replies!  So the concept sounds simple enough. I 
>>> get the sense the issue is going to be processing time. Am I wrong, 
>>> or would a brute-force approach to a 2-second reverb time require 
>>> 100K MAC cycles per sample? I found some open-source packages that 
>>> use FFTs to do this. I was under the impression FFTs would be less 
>>> fast than other methods.
>>>
>>> Ever get the feeling you're opening Pandora's Box only to find a can 
>>> of worms inside?
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
>> http://synth-diy.org/mailman/listinfo/synth-diy
>