<p dir="ltr">Coincidentally I have found this really simple and concise definition of the FFT today:</p>
<p dir="ltr"><a href="https://www.reddit.com/r/Python/comments/1la4jp/understanding_the_fft_algorithm_with_python/">https://www.reddit.com/r/Python/comments/1la4jp/understanding_the_fft_algorithm_with_python/</a></p>
<br><div class="gmail_quote"><div dir="ltr">On Sat, 11 Feb 2017 11:30 Mikko Helin, <<a href="mailto:maohelin@gmail.com">maohelin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Forgot to mention the method is called non-uniform partitioned<br class="gmail_msg">
concolution, the paper can be found here:<br class="gmail_msg">
<a href="http://www.cs.ust.hk/mjg_lib/bibs/DPSu/DPSu.Files/Ga95.PDF" rel="noreferrer" class="gmail_msg" target="_blank">http://www.cs.ust.hk/mjg_lib/bibs/DPSu/DPSu.Files/Ga95.PDF</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On Sat, Feb 11, 2017 at 12:27 PM, Mikko Helin <<a href="mailto:maohelin@gmail.com" class="gmail_msg" target="_blank">maohelin@gmail.com</a>> wrote:<br class="gmail_msg">
> Proper way to handle large filter kernels (IR's) is to use partitioned<br class="gmail_msg">
> kenel and various combined methods (FIR for initial response, FFT for<br class="gmail_msg">
> larger delayed partitions) to get lower overall latency, see the<br class="gmail_msg">
> answer to this questin on StackExchange forum:<br class="gmail_msg">
><br class="gmail_msg">
> <a href="http://dsp.stackexchange.com/questions/25931/how-do-real-time-convolution-plugins-process-audio-so-quickly" rel="noreferrer" class="gmail_msg" target="_blank">http://dsp.stackexchange.com/questions/25931/how-do-real-time-convolution-plugins-process-audio-so-quickly</a><br class="gmail_msg">
><br class="gmail_msg">
> So your hardware should be built around this in mind. For two second<br class="gmail_msg">
> IR (mono) youll need at least (sampling at 48 kHz) 192 kbytes of RAM<br class="gmail_msg">
> (not necessary continuous). It can be done easily by the board Mark<br class="gmail_msg">
> Seel is going to put to Kickstarter soon. It uses XF232 XMOS chip with<br class="gmail_msg">
> 32 cores and total of 1024 kbytes or RAM. Please to to forum and ask<br class="gmail_msg">
> any question there. One of the main uses for the board is going to be<br class="gmail_msg">
> guitar speaker simulation using IR:s (in addition to any other<br class="gmail_msg">
> conventional stompbox functions).<br class="gmail_msg">
><br class="gmail_msg">
> <a href="http://www.diystompboxes.com/smfforum/index.php?topic=114354.120" rel="noreferrer" class="gmail_msg" target="_blank">http://www.diystompboxes.com/smfforum/index.php?topic=114354.120</a><br class="gmail_msg">
><br class="gmail_msg">
> On Fri, Feb 10, 2017 at 10:27 PM, cheater00 cheater00<br class="gmail_msg">
> <<a href="mailto:cheater00@gmail.com" class="gmail_msg" target="_blank">cheater00@gmail.com</a>> wrote:<br class="gmail_msg">
>> I assumed as much - that's why I think a convolution box should be within<br class="gmail_msg">
>> reach of even a novice dev. What about libraries for: reading off sd card or<br class="gmail_msg">
>> usb stick; using data structures like ring buffers; driving lcds; text<br class="gmail_msg">
>> driven menu uis; scanning front panels... is this sort of stuff available?<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> On Fri, 10 Feb 2017 19:56 , <<a href="mailto:rsdio@audiobanshee.com" class="gmail_msg" target="_blank">rsdio@audiobanshee.com</a>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Hello all,<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Note that Texas Instruments has open source libraries that include most<br class="gmail_msg">
>>> common DSP routines. These libraries are almost exclusively written in<br class="gmail_msg">
>>> assembly, but the routines can be called from Standard C code. It's possible<br class="gmail_msg">
>>> to write firmware mostly in C, while linking in assembly routines written by<br class="gmail_msg">
>>> the experts at TI. When developing for the TMS320 C5000 family, I looked at<br class="gmail_msg">
>>> how the different variations of FFT were optimized for different goals and<br class="gmail_msg">
>>> applications, and then designed my own hybrid FFT that was optimized for my<br class="gmail_msg">
>>> exact data. Because the libraries are open source, I was able to contribute<br class="gmail_msg">
>>> bug fixes and optimizations to the Texas Instruments library that should now<br class="gmail_msg">
>>> be available to other developers on the C5000 family.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> I assume that the C6000 family has similar open source libraries. In other<br class="gmail_msg">
>>> words, you might not have to learn TMS320 assembly to get optimal code. I<br class="gmail_msg">
>>> haven't checked, but it's possible that convolution is already available in<br class="gmail_msg">
>>> the library. You might benefit from tweaking their code, but as a starting<br class="gmail_msg">
>>> point you might be able to get up and running quickly with a DSP library.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Brian<br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> On Feb 10, 2017, at 8:43 AM, Terry Shultz <<a href="mailto:thx1138@earthlink.net" class="gmail_msg" target="_blank">thx1138@earthlink.net</a>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> I use the Code Composer tools from TI and I have been using these tools<br class="gmail_msg">
>>> since they were in Alpha state.<br class="gmail_msg">
>>> Assembly code is difficult on the TI DSP Sitara platform. Pipeline length<br class="gmail_msg">
>>> and such.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> I find it easier to use one DSP as the Decoder for Atmos and the 2nd as<br class="gmail_msg">
>>> post processing and Bass manager etc.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Also found it easier to do assembly programming on the ADI 4th Generation<br class="gmail_msg">
>>> Falcon parts as the pipeline line was a bit shorter. The longer the<br class="gmail_msg">
>>> pipeline,<br class="gmail_msg">
>>> the more difficult to re-order efficiently.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> In some cases I have had to build a small library for hand tuned FFT’s and<br class="gmail_msg">
>>> IFFT’s. Can’t show this IP as I was paid to develop for Automotive apps. by<br class="gmail_msg">
>>> Semiconductor company.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> The compilers have gotten pretty good for TI and ADI and I do less<br class="gmail_msg">
>>> assembly work more and more.<br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> _______________________________________________<br class="gmail_msg">
>>> Synth-diy mailing list<br class="gmail_msg">
>>> <a href="mailto:Synth-diy@synth-diy.org" class="gmail_msg" target="_blank">Synth-diy@synth-diy.org</a><br class="gmail_msg">
>>> <a href="http://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" class="gmail_msg" target="_blank">http://synth-diy.org/mailman/listinfo/synth-diy</a><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> Synth-diy mailing list<br class="gmail_msg">
>> <a href="mailto:Synth-diy@synth-diy.org" class="gmail_msg" target="_blank">Synth-diy@synth-diy.org</a><br class="gmail_msg">
>> <a href="http://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" class="gmail_msg" target="_blank">http://synth-diy.org/mailman/listinfo/synth-diy</a><br class="gmail_msg">
>><br class="gmail_msg">
</blockquote></div>