Adapt YINFFT to store its FFT, rather than allocating per frame (usin…

[AlexHarker]

…g the default allocator)

This is an update for #169.

This is not only a speed optimisation. It also fixes the fact that even in SC it will currently allocate an FFT using the default allocator for every frame whoever yinFFT is called.

I will check the tests, which failed last time and make any necessary updates as a second step.

[AlexHarker]

If @weefuzzy has a chance to look at the sizes for instantiation that would be useful [or to say if there's no time for that]

[AlexHarker]

Currently broken - and not as relevant as it used to be - investigating...

[AlexHarker]

Now fixed.

So:

• Ths main speed advantage to this approach is no longer relevant as Flucoma now uses a single static FFT setup (creating a setup per frame was previously a major cost but yinFFT is now about twice as fast as it was before - this change was introduced when allocators/memory assignment were dealt with).
• This PR still addresses lingering issues of memory allocation on the real-time thread, which were not addressed previously
• It's unclear whether any visible speed benefits still remain

[AlexHarker]

Did you speed test this? Also did you check if the unit tests work correctly with the two different commits?

[tremblap]

if it is approved it means it passes my QC. I reproduce expected results and it is faster.

[AlexHarker]

Great - I couldn't judge the speed on realtime, but I haven't tried it offline yet - I will do so.