Guidelines

These are some requirements for 'Fruity approved' plugins. You're free to build your Fruity plugins whatever way you want, but we will only support such 'system friendly' plugins.

Plugins that don't respect all those rules could be seen as working (or not crashing so often) plugins, but in no way 'nice' to the system. Keep in mind that most of the users will see FL Studio crashing instead of the plugin crashing.

A Fruity plugin should:

Share most of its resources between each instance of the same plugin
That is, a plugin shouldn't recreate all its bitmaps or lenghty precalculated tables each time an instance of it is recreated. Instead it should create all its resources in its DLL startup code, & let each instance of the plugin class access the same ressources (if possible). This is important in order to lower the minimum memory requirement for & its plugins, but also very important because graphic resources (handles) are very limited under Win9x, & opening 8 times a plugin that eats 10% graphic resources (& doesn't share them) would crash the system. FL Studio itself now eats about 10% of the graphic resources, but used to eat over 30% in its early versions. The trick here is to prefer DIBs (*not* using CreateDIBSection that eats a handle too) over DDBs, & to group bitmaps if possible.

Not eat too much CPU for what it does
A plugin eating 20% of the average CPU is almost useless, unless it's not made to be used in a complete song. Don't create any threaded timer, FL Studio itself uses standard Windows timers for its animation, because it's a music app & the music has a higher priority. Threaded timers are only used for the mixer & MIDI message delivering. Any timer used to animate something should be switched off when the interface is hidden.

Install nicely
In the tools folder, you can find the FPSetup program. You can call this from your installer program (or unzipper or whatever), with a script file as parameter. This will then install your plugin in the right place. Look here for additional information about this.

Not be published in its beta state
This not to crowd the plugin list with ten versions of the same plugin (though a second or enhanced version is acceptable). Plugin presets are definitely *not* compatible between them, so an enhanced version of a plugin won't be 'told' to load presets from another version, which is considered as another plugin. A better way to support future enhancements is to store a version # as the first entry in the plugin saved state. That way, any enhanced version will be the same plugin (same name, & overwriting its old version), & check the version stored in its state to 'adapt' old presets to its new version. It's also nice, though not required, to make the plugin not load a state of a version it doesn't support.

Have a name that works as a valid directory name
Plugins will store their presets inside a subdirectory of the same name, so plugins can't use \ or any invalid character in their name. Additionally (but it's more a limitation), the plugin 'long' name (published by the DLL), the plugin DLL name, & its subdirectory name should be the *same*. Ex: 'BeepMap/BeepMap.dll' publishes the name 'BeepMap' (but is free to publish anything else as the 'short' name).

Have a unique name
Please do not name it 'Flanger', or just 'Distortion' of course. We're not using GUIDs to recognise plugins, so plugin names have to be unique. A good idea is to put your initials before the name & to check that no plugin already has the name you chose. Several DX plugins chose to name their plugin 'AUTHOR plugin function', so that they're easy to store in sub-entries in a menu list. FL Studio might support that in the future.

Follow all the rules described in the SDK
The SDK publishes many things not supported yet, so please don't assume your plugin works by trials/errors. Do not touch things or use flags you don't know about.

NOT MESS WITH THE CPU STATE
This is important & is part of the bad reputation & instability of VST & DX plugs in FL Studio. Plugins shouldn't modify the CPU state (including the FPU state), or at least restore it as they got it.

Respect the guidelines about when plugin functions are called
FL Studio can call plugin functions by its main thread, or the mixing thread, meaning that 2 of your functions could be executing at the same time. For example, your DLL could be mixing a piece of buffer in another (FL Studio) thread just when you're updating a parameter (by one of your visual control), so in some cases a thread synchronisation system has to be used. The FL Studio host class publishes 2 functions to 'lock' & 'unlock' the mixer thread.