Massive FL STUDIO Problem

[ps]

I think I remember there were some changes recently to fix the Multiple Outputs in FL Studio I tested it all seemed fine. But unfortuantely I didn't change the host tempo in my test.
When I only change the bpm of FL Studio to below 120bpm it suddenly produces immense static noise mostly leading to a crash with my plugin.
The buffer / sample rate settings doesn't change anything. I tested on two different M1 Macs.
Any ideas?

[Lindon]

@ps make a simple sine wave generator plugin and test that...

[Christoph Hart]

WHAT? FL Studio keeps on giving :)

I can reproduce that here, let me check real quick why this is such a clusterfuck.

[ps]

@Christoph-Hart i pushed an update a few days ago with this in it hopefully only 120+ bpm producers have installed yet haha

[Christoph Hart]

OK, it appears that FL Studio is sending out bigger buffers than the actual buffer size when the tempo is < 100BPM. What on earth is wrong with them? I'll keep investigating, but this is so stupid I can't even describe how messed up that is. The maybe most important convention between DAWs and plugins is "I tell you how many samples you can expect AT MOST in the prepare call. After this I can roll a dice and send you any fucked up number between zero and this amount but I promise I won't exceed this number". FL Studio manages to violate even this basic foundation of how all plugins work, that's amazing. Even better that it only does it when a random condition is true (BPM < 100), so that it increases the chances of not being detected while debugging & testing.

Fixing this will take a bit longer, but I'm on it.

[d.healey]

Maybe someone should inform FL Studio :)

[Christoph Hart]

Yeah, maybe someone who isn't as grumpy as me can do it, but if I write them, it'll be in ALL CAPS!

[ps]

@Christoph-Hart damn. interesting that in my case it's below 120bpm - what could the correlation between bpm and this fuckup be?

[Casey Kolb]

@Christoph-Hart said in Massive FL STUDIO Problem:

OK, it appears that FL Studio is sending out bigger buffers than the actual buffer size when the tempo is < 100BPM. What on earth is wrong with them? I'll keep investigating, but this is so stupid I can't even describe how messed up that is. The maybe most important convention between DAWs and plugins is "I tell you how many samples you can expect AT MOST in the prepare call. After this I can roll a dice and send you any fucked up number between zero and this amount but I promise I won't exceed this number". FL Studio manages to violate even this basic foundation of how all plugins work, that's amazing. Even better that it only does it when a random condition is true (BPM < 100), so that it increases the chances of not being detected while debugging & testing.

Fixing this will take a bit longer, but I'm on it.

This is so wack! I can't believe FL Studio does this. Just confirmed this is happening for me too.

[Christoph Hart]

what could the correlation between bpm and this fuckup be?

I just looked in the source code of FL Studio and I could find the line in question:

if(bpm < (120.0 - Math.random() * 20.0))
{
   trollPluginDevelopers(true);
}

[Dan Korneff]

@Christoph-Hart :beaming_face_with_smiling_eyes: :beaming_face_with_smiling_eyes: :beaming_face_with_smiling_eyes: :beaming_face_with_smiling_eyes:

[Christoph Hart]

OK, I think I've fixed it now.

To be fair, this wasn't FL Studio's fault (this time), but I still had some old code in the prepare call that set a fixed blocksize of 256 back from the time when I added a 256 sample delay to have a consistent buffer size in FL Studio. I mean, of course it's FL Studio's fault because it sucks, but you know what I mean :)

With this fix I've also added a Engine.setMaximumBlockSize() call that you can use to limit the maximum block size that HISE uses in its process callback. It's basically the same logic as a container.fix64_block etc, but on the global HISE level. This might come in handy for various purposes (eg. the macro modulation system gets a better resolution if you use lower block sizes etc), so depending on your project it might justify the increased CPU load.

Be aware that these fixes to FL Studio only work with instrument plugins, however if you're exporting a FX plugin, you can just set HISE_EVENT_RASTER to 1, then it should bypass this entire topic (maybe I'll set that as default for FX plugin exports...)

[Lindon]

@Christoph-Hart said in Massive FL STUDIO Problem:

maybe I'll set that as default for FX plugin exports...

Yes please.

[Christoph Hart]

Ah, smart me in the past already did that:

#ifndef HISE_EVENT_RASTER
#if FRONTEND_IS_PLUGIN
#define HISE_EVENT_RASTER 1 // Do not downsample the control rate for effect plugins
#else
#define HISE_EVENT_RASTER 8
#endif
#endif

[Lindon]

@Christoph-Hart win win!

[ps]

@Christoph-Hart thanks!!! Time to compile again :)