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.