FL Studio parameter randomize feature stops audio processor from calling processBlock


I’m facing this bug where my audio processor stops calling the processBlock function after using the FL Studio’s randomize feature. The plugin doesn’t crash or anything. It isn’t something getting stuck in the processBlock function either since I also tried commenting everything out. Has anyone else encountered this issue? Thanks so much.

Ps. Most plugins don’t have the dropdown menu at all, and my plugin doesn’t need it since it has no presets. Is it possible to get rid of it somehow?

I’m having the same problem. Did you find the way to fix this?

I spent a fair amount of time trying to find an answer to no avail. I then checked if other popular plugins made with JUCE behave the same way and found out that yes, they do. I don’t know if this is a problem with JUCE or some common programming mistake that even some big companies have made. Either way, I decided to just move on it since I have never actually seen anybody using the randomize button haha.

Does the plugin always fail when randomizing parameters, or is it intermittent? I haven’t tested this, but I wonder whether FL is randomizing the bypass parameter. Could you try overriding processBlockBypassed and seeing whether it starts being called after randomizing parameters?

Hi reuk.
It does happen always. Or at least with my testing.

I overwrote the processBlockBypassed function and found out that it does indeed bypass the plugin. The problem is that once it bypasses with the first press of the randomize button, you can’t go back.

You could try overriding AudioProcessor::getBypassParameter to return your own bypass parameter, and then add a button in your plugin UI to control the bypass state by toggling this parameter.


i have actually used it a lot for sounddesign. it can give you some really perculiar sounds if you give it a huge synth to randomize. just make sure to put a limiter behind it

Thank you for helping, adding the power button sounds reasonable.

Although I have tested randomizing many times, I haven’t get it back to call processBlock(). I assume it’d call processBlock() sometimes if this is caused randomly. And it seems this problem doesn’t occur to some other plugins.

As far as I tried, AU works fine.


I’ve tried to override getBypassParameter and seems to work, thank you.

But my problem is my plug-in is a synth, so it looks a bit strange to have a bypass parameter.

And as far as I checked, bypass parameter is always added as a host parameter at juce_VST3_Wrapper::setupParameters() regardless the plugin is effect or instrument.
so, the following if-condition is always true and never reaches at the line “return false”.

bool isBypassed()
    if (auto* bypassParam = comPluginInstance->getBypassParameter())
        return (bypassParam->getValue() != 0.0f);

    return false;

Is this correct?

As work around, I’m thinking like

void processBlockBypassed() override { processBlock(); }

and to disable Bypass automation,

std::unique_ptr<juce::AudioProcessorValueTreeState::Parameter> dummy;

and set dummy’s isAutomation as false, then

juce::AudioProcessorParameter* getBypassParameter() { return dummy.get(); }

then, the plug-in can hide bypass parameter from the list of automation, and always call processBlock().

Let me know what you think of this.

Thank you in advance.

I think the cause of the issue is the check against 0 in that function. FL sets the bypass parameter to a random value between 0 and 1, but the plugin will be bypassed for any non-zero value. I’ve got a potential fix for this issue which I’ll push after the next point release.

I think that your suggested fix should work. However, on inspection, I discovered that some of the plugin wrappers don’t implement bypass as documented, i.e. processBlockBypassed should never be called if the plugin overrides getBypassParameter to return a parameter. I’ve got a fix for this issue too, which will also need to wait until after the next point release.


Great! Thank you for your help.

I’ve updated the wrappers so that the bypass value is checked against 0.5 rather than 0. This should improve the parameter randomisation experience in FL:


There is a simple way to solve that problem with FL.
If you don’t need presets, or if you do handle them directly within the plugin, you can simply make getNumPrograms() return 0.
That way FL will not show the preset drop menu and randomizer entry.

There is a potential catch though, as the original processor stub does return 1 for that method with the following comment:

// NB: some hosts don't cope very well if you tell them there are 0 programs,
// so this should be at least 1, even if you're not really implementing programs.

Is it still a valid concern?