I would surmise that a lot of people that purchase FL Studio don't actually ever buy plugins. (This is also the case for many PT users.) As such, they're of little concern to me, obviously. Or this conversation.
From what I know (I don't do marketing, just reporting what I've been told), FL customers actually buy a lot of plugins.. of ours.
I remember that in the beginning, others at IL weren't much interested in releasing VST versions of FL plugins, because apparently VST's don't sell (they say, after discussion with other people in trade shows).
Personally I have always wanted VST versions of our plugins mainly for them to 'exist', be listed in databases, reviewed. And of course to be used in other hosts.
But I consider the VST versions inferior, because they are, technically (they don't have features that the VST SDK doesn't allow, obviously).
Now about plugin formats: I don't believe in a new one. IMHO any host should support the VST standard, and have its own, private, proprietary format. A proprietary format has some advantages:
-you can add features tightly linked to your host, and FL's plugin SDK is full of that
-it will work better because talking more directly to your host (and you will then wrap VST's)
-it's not public, so you can make changes & add stuff when you want while not having to deal with a crowd of angry programmers. And you don't have hundreds of shitty programmers abusing its undocumented sides.
Now, why I don't believe in a new format:
-everyone has different interests, & you can't please everyone. Either you listen to everyone and the result is a bag of all of the shitty requests, which no one will use. Or you don't listen and everyone leaves.
Someone, or a little group, has to decide of it. But it has to be people with experience in both host & plugin making, and it should be free of requests from new programmers & their 'great ideas'.
It should also be free of any MIDI-related crap, and I know I'm almost alone on this one, which is why I wouldn't want to take part in it, anyway.
-no one will want to support it, because you're not Steinberg. Well, if even Microsoft failed at it..
You have to know that I have a hard time convincing *our own developers* to support FL's plugin SDK. Usually programmers already made VST's, and don't really want to support a new SDK or new features, or don't agree with the differences in concept (and this is why some FL plugins work a bit differently than others). Only me & Fred know the FL plugin SDK in depth.
About VST3, to me it's welcome, and we (well, Fred [reflex]) will certainly support it.
It has 2 major features for us:
-the 'no process when not fed' thing, which exists in FL for ages under the name 'smart disable'. So it already works for VST2 in FL, but if it lets the plugin know when its processing has been skipped, it's even better.
-accurate automation of published params. This is huge. Here too it already works in FL with VST2, since it's processing in random-sized chunks, so automated params are processed at tick boundaries (no sample-accurate envelope, though).
It's huge because so far a lot of programmers never bothered publishing parameters, and made their plugin MIDI-automatable, for the simple reason that it worked better in Cubase. Now that both work, I expect those to finally forget that stupid MIDI protocol (which they never even supported properly anyway [talking about RPN's]).
There's also the fact you can resize plugins, that will probably make Fred's life easier. And porting our FL plugins to VST will probably be easier too.
