I made some progress towards solving the UI lag from the FFT. @Consint & @oskarsh @Oli-Ullmann this may be of some interest to you.
Basically I found that if you run the FFT inside of a scriptnode network, you need to script the buffer size in order for it to take effect (editing the buffer size within the scriptnode will not work).
Now in my case I need to drop the size to at least 4096 samples which is barely tolerable, but it seems to have cleared up the UI lag issue. The minimum the FFT will accept is 1024 samples (which is virtually useless imo). There's also a direct correlation between the size of the FFT on your UI and the lag you experience (smaller ones don't seem so bad).
You can kind of see the refresh rate slowing down here:
giffymetimbers.gif
I created a script to resize my visual/buffers, and I use sliders to control their sizes. It looks something like this:
namespace BufferManager
{
reg isUpdating = false;
const var BUF_SIZE = [1024, 2048, 4096, 8192, 16384];
// FFT Buffer Properties
const var FFT_BUF_PROPERTIES =
{
"BufferLength": 1024,
"WindowType": "Blackman Harris",
"Overlap": 0,
"DecibelRange": [-100.0, 0.0],
"UsePeakDecay": false,
"UseDecibelScale": true,
"YGamma": 1.0,
"Decay": 0.5,
"UseLogarithmicFreqAxis": true
};
for (i = 0; i < fftBuffers.length; i++)
{
fftBuffers[i].setRingBufferProperties(FFT_BUF_PROPERTIES);
}
// ----- CONTROLS -----
// Control - FFT Size
inline function onknb_fftSizeControl(component, value)
{
if (isUpdating)
return;
isUpdating = true;
// Stop all processing
for (b in fftBuffers)
b.setActive(false);
//Engine.allNotesOff(); // I was using this but doesn't seem necessary
// Updates
local newSize = BUF_SIZE[value];
FFT_BUF_PROPERTIES.BufferLength = newSize;
// Apply to all buffers
for (b in fftBuffers)
b.setRingBufferProperties(FFT_BUF_PROPERTIES);
LafFftAnalyser.createReadBuffers();
// Restart processing
for (b in fftBuffers)
b.setActive(true);
isUpdating = false;
};
knb_fftSize.setControlCallback(onknb_fftSizeControl);
