VST Plugin sandboxing

[ShibuyaCyana]

Your idea

Running VST plugins in a separate process, to prevent VST crashing from bringing down the whole MuseScore. I do hope VST support come stable before anything else, but this may worth considering in the long run.

Problem to be solved

Some crashes are caused by VST, and MuseScore suffers from that. This kind of processing, tho may reduce stability and compatibility in some cases, could defend MuseScore from this kind of crash.

Prior art

BitWig has a good reputation for its plugin sandboxing, and some options are provided to reduce compatibility or performance problems: https://www.bitwig.com/learnings/plug-in-hosting-crash-protection-in-bitwig-studio-20/ and REAPER do have similar options, tho, from my experience, could be problematic sometime.

Additional context

No response

[jessjwilliamson]

Hi! We have designs for a VST manager that can help handle problematic VSTs to prevent crashes in future. Implementation for this is still in progress. :) Have a look at https://github.com/musescore/MuseScore/issues/15967

[ShibuyaCyana]

Have a look at #15967

Great, I'll follow that. But notice these are two different things: plugin sandboxing means to put VST in a different thread when running audio in real time, therefore if a VST crashes it won't cause MuseScore to crash, then user may try to reload that VST or switch to another one. This feature - if implemented one day - could be integrated into the VST manager, tho. btw I don't think blacklisting a plugin 'cause it has crashed once is a good idea. Many major VSTs crashes a lot, and we still (have to) live with them...it's a different thing when scanning, ofc.

[jessjwilliamson]

Have a look at #15967

Great, I'll follow that. But notice these are two different things: plugin sandboxing means to put VST in a different thread when running audio in real time, therefore if a VST crashes it won't cause MuseScore to crash, then user may try to reload that VST or switch to another one. This feature - if implemented one day - could be integrated into the VST manager, tho. btw I don't think blacklisting a plugin 'cause it has crashed once is a good idea. Many major VSTs crashes a lot, and we still (have to) live with them...it's a different thing when scanning, ofc.

Ah I understand better what you mean now - that's a pretty neat feature from Bitwig :) That might be more for the developers side to look into but we look forward to implement the above task I just sent you first. Thanks!

[jeetee]

I'd like to mention/link this somewhat to the process/thread architectural considerations being investigated in #12647 . Not that it has to do with how windows are managed or is a direct part of that other issue; but it will touch upon part of the IPC conversation and process management structure surrounding it.

@ShibuyaCyana Note that sandboxing requires a different process, not just a different thread, as a crashing thread still may bring down (or result in unsafe assumed state) of the entire containing process.

[ShibuyaCyana]

@ShibuyaCyana Note that sandboxing requires a different process, not just a different thread, as a crashing thread still may bring down (or result in unsafe assumed state) of the entire containing process.

Thanks for correcting that, I don't know much about the code, just feeling that if MuseScore's accepting VST then it may need this one day, and this feels like some fundamental problem that need to be planned in advance...

In REAPER if I run a plugin in dedicated process, docker on Windows will look like this:

process manager looks like this:

Bitwig only has a single docker icon, and looks like this in process manager: and this doesn't change when you ask it to create multiple "sandboxes", looks like more things are happening under the hood rather than simply bridging with a dedicated process.