Unbridged plugins running as separate processes

[psycodeine]

I feel like I'm jumping the gun here, since I did a cursory keyword search on the forum in an attempt to find a feature request like this one.

I didn't find anything, so I'll suggest it.

I think I'd like to see the option of running plugins that aren't using bridging in separate processes. The closest metaphor I can find that matches it is web browsers. For instance, Chrome uses a single 'process-per-tab'. The rendering of the content is sequestered to a different process than that of the UI. If the tab becomes sluggish or unstable, simply quitting it won't cause the main UI to crash or fail. Firefox is beginning to use something like this as well, but there's only one other rendering process: https://developer.mozilla.org/en-US/Fir ... ss_Firefox

VST3 has a similar design: the controller code and the processing code are separated, and can even run on different machines (with, of course, the proper remoting mechanisms).

Part of the reason I want this feature is because I haven't yet switched away from 32-bit FL Studio. I've noticed then when I run many of my projects with 64-bit VSTs under a 32-bit host, FL Studio (when using bridging) is less likely to show 100% CPU usage and start crackling and hissing. I also notice it is using my multi-core CPU more effectively and is less likely to crash in this configuration. With all of the flippant 3rd party VSTs I use, FL is always going to crash at least once a session (not much unlike Cubase), so I appreciate when it happens less (and naturally when auto-save is involved)! If preventing a crash is as simple as properly terminating IPC, I'm all ears.

If it isn't going to happen, I'll shut up. Also, if I need to be corrected because my thinking is flawed, please speak up. If it's already happened, let me know how to enable this feature.

Best Regards,
Jon

[reflex]

Bridging is what you want in that case. It's pr...

[psycodeine]

@reflex, just to clarify, I am an idiot. I just...