But read again please, I am talking about selective sandboxing in addition with a DMP decoder so we know what’s the issue.
Meaning that one could use it for the “problematic” plugins. Not sure if this is possible though, I don’t have the knowledge to support the idea, it is just a suggestion.
lots of things are possible, it is just a question of resources and time, although automatically analyzing crash dumps would be a challenge. You’d need to have a debugger installed anyway, which 99.x% of people don’t.
I don’t really see the need for this anyway. A general sandboxing solution like Bitwig would be nice to have, definitely… And then you already know what the problematic plugin is, because Bitwig tells you. And if that happens reproducibly, the plugin developer needs to fix it, else I wouldn’t use it anymore. What good is a plugin that regularly crashes, even in a sandbox?
Btw, analyzing crash dumps isn’t that difficult, I’ve written a short tutorial for it.
I’ve got procdump to generate dmp’s when cubase doesn’t but I don’t know hot to analyze them, just sending these to steinberg…
Yes you’re right but I wonder if it is of any benefit to have the sandboxing solution along with the one used now so you can have the best of both worlds. Plus users would be free to choose, so no complaints etc. But then you would need to have a dmp decoder too for the vsts not using the sandbox, till you swap them.
Oh, that’s great, thank you.
I will definitely check it to learn how to, since I am facing several issues lately.