[sdiy] IR Reverb

[Tim Ressel]

Thanks for the tip!

I wonder if it would be possible to do a parallel processor scheme where 
one proc handles the early stuff and another to handle the longer time 
stuff. each proc would output via a codec and those outputs would get 
summed. Hmm...

--Tim (certifiable) Ressel


On 2/16/2018 11:38 AM, Eric Brombaugh wrote:
> I suspect that STM32 doesn't have the horsepower you'll need to do a 
> useful IR reverb. There are several fairly efficient FFT in the CMSIS 
> libraries from ARM but even using those the best you can do is about a 
> 4096 FFT running at less than 48kHz with long latency and large overlaps.
>
> You might want to study the various FFT easter-egg modes in the source 
> code for the MI Clouds module to learn more:
>
> https://github.com/pichenettes/eurorack/tree/master/clouds/dsp
>
> Eric
>
> On 02/16/2018 12:24 PM, Tim Ressel wrote:
>> Still, even with all that jigery-pokery, we're going to need a bigger 
>> boat, er, processor. I'd like to avoid processor choices that needs 
>> pricey tools. STM32 would be nice. Of course some good ol' fashion 
>> assembly code, highly optimized, would help things. Its been a while 
>> since I went down that rabbit hole. I wonder if someone has an 
>> optimozed FFT library for Cortex Mn...
>>
>> --timbo
>>
>>
>> On 2/16/2018 11:00 AM, Eric Brombaugh wrote:
>>> 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
>>>>
>>>
>>> _______________________________________________
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org
>>> http://synth-diy.org/mailman/listinfo/synth-diy
>>
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy

-- 
--Tim Ressel
Circuit Abbey
timr at circuitabbey.com