FFT Analyser Path - Need help drawing the magnitude to height
-
@HISEnberg @oskarsh Has handling the FFT path in a background task solved the problem for you? A user described exactly the same problem to me with one of my plugins and I can't reproduce it. In Studio One on Windows 11, the plugin has so much lag that it is unusable for him and sometimes even crashes, whereas in Mixcraft it runs without any problems. I then installed Studio One in a Windows 10 VM for testing and the plugin runs without any problems.
-
@Consint I kind of gave up on it and used HISE's stock FFT instead, I couldn't risk the issue coming up again. So in short I never tested moving it to a background task. I did edit my original code so that it only repaints when a new FFT path is shown and to reduce the amount of bins. According to the profiler it was more efficient than the stock FFT but this doesn't necessarily address the issue users are facing.
Sorry wish I could offer more help with this issue.
-
@HISEnberg I tried it and it fixed the problem. It doesn't seem to have caused any other problems either. I did exactly as @ustk suggested and simply moved the path creation to a background task.
-
@Consint Do you mind sharing an example snippet? I recall trying this but it didn't work in my case. Perhaps I was doing something incorrectly.
-
@HISEnberg I couldn't make a better example snippet than @ustk has already done above. Maybe you can post your code and we can see if we can get it to work.
-
@oskarsh Hey man, I tested the FFTVisual.
It works the first time (importing the snippet), but after just one change in the namespace and hitting compile, Hise freezes and crashes. Any ideas? -
@ILIAM crucial 'one' change?
-
@Chazrox Nah, just changing a number!
-
@ILIAM not sure what is going wrong can you share a snippet and what to change? Are you using windows ?
-
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:
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);