Massive FL STUDIO Problem
-
@Christoph-Hart i pushed an update a few days ago with this in it hopefully only 120+ bpm producers have installed yet haha
-
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.
-
Maybe someone should inform FL Studio :)
-
Yeah, maybe someone who isn't as grumpy as me can do it, but if I write them, it'll be in ALL CAPS!
-
@Christoph-Hart damn. interesting that in my case it's below 120bpm - what could the correlation between bpm and this fuckup be?
-
@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.
-
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); }
-
@Christoph-Hart :beaming_face_with_smiling_eyes: :beaming_face_with_smiling_eyes: :beaming_face_with_smiling_eyes: :beaming_face_with_smiling_eyes:
-
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 itsprocess
callback. It's basically the same logic as acontainer.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...) -
@Christoph-Hart said in Massive FL STUDIO Problem:
maybe I'll set that as default for FX plugin exports...
Yes please.
-
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
-
@Christoph-Hart win win!
-
@Christoph-Hart thanks!!! Time to compile again :)