fix max fft size fiasco

[weefuzzy]

What is the road to where paved with?

This hopefully fixes #258

FFT had been altered some time ago to use a global setup object in order to cut down on these expensive things being redundantly created all over the place (quite possibly on the heap? Can't remember...). Instead an assumed hard limit of 2^16 Became A Thing. Unfortunately, nobody (i.e. me) told the rest of the codebase, which happily assumed that anything was possible. Moreover, (a) FFT::resize() is assumed by calling code not to fail (!?) and (b) its assert was useless because FFT was still cheerfully accepting fft sizes > 2^16, even if its setup object could never honour that.

(Seems like now would be a good time to have more unit tests)

So. I still like the idea of 'normal' FFT usage not spraying lots of these setup objects out into the world, but have attempted to accommodate the adventurous by allowing a local setup object in a std::optional when a chunkier size is requested.

So far, this is tested only to the extent of seeing if I could run NMF in Max with a FFT of 217. I will at least confirm that when fft size is <= 216, it continues to use the default path, but more dedicated tyre kicking by @tremblap will be helpful.

[weefuzzy]

The ubuntu CI is failing because one of the tests won't build. Seems like GCC has decided that in that test I'm trying to copy a move only object, but not at all clear why it's decided that now because this was always the case.

[tremblap]

oh ubuntu is bailing at the tests (any idea why?), but I ran the SC unit tests and they all run fine... and nothing crashes now with the large fft size.

[tremblap]

otherwise I should test on ubuntu and windows as this is potentially 'big' right?

[tremblap]

I mean, running the UTs on locally compiled things?

[weefuzzy]

Yes, whenever you're able!

[tremblap]

doing it now as I practice this hard bass line I can't play to save my life :D

[tremblap]

ok it refuses to build on Ubuntu 20. I get loads of similar errors to this:

/home/pa/Documents/source/flucoma-core/include/clients/rt/../common/../../algorithms/public/STFT.hpp:27:7: error: use of deleted function ‘fluid::algorithm::FFT& fluid::algorithm::FFT::operator=(fluid::algorithm::FFT&&)’
In file included from /home/pa/Documents/source/flucoma-core/include/clients/rt/../common/../common/FluidContext.hpp:17,

[weefuzzy]

'it' is the tests, or a build for a cce? (and – what? – that function isn't deleted 😭 )

[tremblap]

I've pulled the tip of main in SC, and the PR 281 in core, and building in ninja. I can send the full error stack but there are a lot.

[weefuzzy]

e-mail it to me if you can. sounds horrible

[weefuzzy]

Ok, received, thanks. That does give me a clue, now off to cppreference to see if I can figure out what exactly I've done to make gcc so sad (it's definitely this change, to do with adding a std::optional to the FFT class).

[tremblap]

in case this helps explaining why MacOS doesn't bail but Ubuntu20 does: on the latter I have gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.2)

[weefuzzy]

Ok, think I figured it out. Can you check a full build again?

[tremblap]

It builds in all 3 OSes, I am running the UTs in SC now in all 3

[tremblap]

it all works perfect, you can merge