Mulab Plugin as a multithreaded plugin container

[4u610h346]

Having "control" over the core(s) used per plugin can be nice, with older plugins. With that said, I've often seen it backfire. Also, things don't always divide up the way you'd expect. Some plugins, using 3D acceleration, don't always fit in the space the way you'd like.

For my personal use, I requested this (in a cluttered way) a little while ago. I enjoyed the idea of cores existing in a mux like view, and routing done in that space.

For most people, I just don't think it would work out well. It would be a fancy feature, but people likely would not get what they were hoping for.

I haven't used any newer version of Windows. If you can still control which core(s) an application uses, at execution, maybe a person could use more than one instance of MuLab (threads set to auto in setup)?

[robert_p]

- I need a plugin container that could allow multithread processing when using parallel signal flow. At this moment I only know running as a plugin and using multicore BlueCat Patchwork, Unify and Bidule.

NI Maschine software supports multithreading, but it's more resource hungry than Unify (which I use for synth layering). Bidule is even more CPU-friendly, however, I'm not a fan of their user interface. BC Patchwork is pain in the ass when it comes to advanced audio/MIDI routing. MuLab plugin works well with UNIFY - it's single treaded, but I can load multiple instances (each Unify layer uses separate CPU thread even when running inside a DAW). Also, Unify can be inserted as a plugin into the MuLab plugin and it will use multiple CPU threads even though the MuLab plugin is single-threaded.