I can certainly understand that, as I said I do IT work for engineers and there are plenty of programs out there where you have no choice. There is one thing that does what it does. However when you are in that situation you have to accept that and work with it. That doesn’t mean you don’t ask the vendor to try and fix things, but you accept that to make that happen, you are going to have to bisect the problem and give them useful feedback to do so, and that even then they may not. I remember when Agilent steadfastly declared that Windows 10 sucked and so their software would only work with Windows 8 for some of their high end hardware.
It’s not the criticism that got me, it is the unconstructive way it was done. His original post was one of “This is a universal problem with the software,” when clearly that is not the case, and then the refusal to try anything on his end to try and figure out why he has a problem that others don’t. That is not useful, and criticism like that to a company doesn’t help. For developers to fix issues they have to be able to figure out what the issue is and when that issue occurs on your platform but not on theirs, you have to help troubleshoot the problem.
I know it sucks, but it is how it works. Flaws in code don’t show up in some bright red line that they just ignore, it is subtle and hard to find, particularly when it is an interaction between multiple pieces from multiple vendors, as with plugins. So you have to work on trying to find out what the issue is, then report it if you want anything done, not just declare the software to be bad and that they should just fix it, as though they know what the solution is and just won’t implement it.
I mean I had the same general issue: Hanging on exit. I posted on the forum, seeing if others had it, which they did. Plugins were listed as a common culprit. Took me a bit, since I used BFD3 in all my projects, and since it didn’t always hang on exit. However once I removed it, problem was solved. In my case, I was able to start using it again after migrating to Inmusic and getting a new version, but even if I hadn’t, I’d at least know what was causing the issue and be able to let Steinberg and Inmusic know of the problem so hopefully they could find a solution.
Telling a company “When I load project X, with plugin Y, and then have it do thing Z causes an issue,” is productive. It doesn’t mean they will know what the solution is, but at least they know where to look for the problem. Saying “This software is broken and you need to fix it,” with no details is not productive.
It would be nice. I’m guessing it is a pain to implement and/or has other issues because it seems like very few DAWs have it. What I would like is three choices for plugins:
-
Native loading, the lowest latency and least CPU, but it means if they are unstable it’ll likely bring down the DAW.
-
Universal sandbox for ones that are suspect. This would load all the “universal sandbox” plugins in their own separate process, kinda like doing a VEPro setup. More overhead than DAW native, but not too bad since it is all in one other process. However if one dies, everything in that container is going down with it. Does mean the DAW could just auto-restart the container though.
-
Individual sandbox, for real problem children. This would have the most overhead, and you wouldn’t want to do it with every plugin, but it would allow for real isolation of the plugins that are real gremlins, but you just can’t live without.
I think it would be a great feature to have, but I also understand that it may be something that is fairly difficult to implement well.