Will Live ever get "Sandbox for Plugins" feature?

[silentio246]

How do you specify which plugin gives you the crash?

Remove the plugins from your plugin folder, then copy them back, one by one, and check every single plugin within Live.
So you can exclude the good ones and find the bad ones. Could need some time.

[FurkanTopal]

How do you specify which plugin gives you the crash?

Remove the plugins from your plugin folder, then copy them back, one by one, and check every single plugin within Live.
So you can exclude the good ones and find the bad ones. Could need some time.

That's f*cking oldschool approach man. I spent whole night by looking at the log.txt and tried to detect what causes problems. Everything is frustrating here. Someone from Ableton support doesn't reply my questions, she's ignoring my complaints. I created new ticket and got an answer within 2 minutes from someone else and I sent him the files and waiting for a respond.

But I guess I'll apply your method but what if not one but two or more than two plugins are causing this? Then I guess I'm f*cked up.

[Machinesworking]

How do you specify which plugin gives you the crash?

Remove the plugins from your plugin folder, then copy them back, one by one, and check every single plugin within Live.
So you can exclude the good ones and find the bad ones. Could need some time.

That's f*cking oldschool approach man. I spent whole night by looking at the log.txt and tried to detect what causes problems. Everything is frustrating here. Someone from Ableton support doesn't reply my questions, she's ignoring my complaints. I created new ticket and got an answer within 2 minutes from someone else and I sent him the files and waiting for a respond.

But I guess I'll apply your method but what if not one but two or more than two plugins are causing this? Then I guess I'm f*cked up.

If you're on Max OS and if you're lucky the OS will publish a crash report, the plugin last mentioned in the crashed thread is usually the guilty plugin.

Another point, make a folder next to your VST folder named "Disabled VSTs", then put half of your plugins in it, this give you a 50% chance of disabling the right one or ones. You repeat this enough and it's much faster than one by one.

[EricBuist]

Unfortunately, I suspect this would require a major rearch on Ableton's side. The only way to sandbox VST so if one crashes, the whole DAW doesn't crash, is to run each VST in a separate process and have inter-process communication between the VST and the DAW. That would cause scalability issues for projects with a lot of plugins. A good tradeoff would be the ability to selectively sandbox a VST that is causing crashes, but even that would require a major rearch. It is "simpler" and more profitable for Ableton to assume VSTs are well-written and just blame the VST in case of crashes.
Unfortunately, any native code compiled using C/C++ is subject to crashes. It is almost impossible for developers to completely prevent this from happening. You need a runtime that will manage memory and do no call to unmanaged code (e.g., Go), or a compiler that will help with memory management (e.g., Rust), period. A DAW written for a managed runtime like Java or .NET, running VSTs in a managed language would be great. At worst, a VST would throw a NullReferenceException and would just be shut down or rebooted by the host, no DAW crash, but performance would suffer. Testing C/C++ alleviates issues, better coding practice helps, but unless the program is dead simple, there will be an hole, it will eventually crash. Having VST capable of crashing the whole DAW is becoming a major deal breaker for creativity. Ableton Live worked correctly for years. Enter VST like ROLI's plugins, and bang, crashes almost once per recording session. I sent crash logs to Ableton, they pinpointed the plugin, sent report to plugin maker, they point the DAW.