Yep.
Imagine Windows or Mac crashing everytime you use certain new software, instead of giving just an error message that it crashed. Well this is essentially the same logic.
Even if Windows/Mac is not the fault of a bad coded execution, the host should never crash.
Nothing more to say.
Check out their concept, try it out and then lets talk again.
I donât think IPC is the big problem, that can be solved with shared memory for audio buffers. But it is a relative big task to do a context switch, and the context need to pick right task otherwise your shared memory are gone from the cache. And that will fail often when your read-to-run queue are a lot longer than your CPU count even with CPU bound tasks.
I think Paul Davis (who developed Ardour) said something in the lines of âhaving a DAW be able to load external libraries (aka plugins) is a bad idea to begin withâ 
You have shared code that is very much the same as plugins in both windows and mac. In windows they are dll, and osx the are .so. If you have bugâs those that are used by the system your computer might fail. They need to fixed. You need to have your trust scope clear when you start to use shared code.
Yeah and he was right, that increases the chance of unpredictable things happening. But this is not only true for DAWs: also devices which run OSâ like Apple/Android/PC/MAC/Linux with their app stores, basically every âhostâ out there.
How good/bad 3rd party plugins are coded is out of your control, so what can you do?
There is only one real option: find a way to not let 3rd party plugins crash your application.
Sandbox is just one way to do it, and other DAWs prove that it can work flawlessly. Of course if there is a better solution to this, even better.
But one thing is clear: This should be a core feature of a stable host.
If you badly need that sandboxing use a audio interface with loopback and run it standalone or in a small container.
What about the plugins that relay on that they are not sandboxed?
Not the same at all. You donât seem to not understand the idea behind this and we all know now, that you donât care about this FR. But then I donât understand what youâre trying to achieve here? Just scroll on.
If you donât have any crashes, well, thats good for you. Does not mean there arenât lots of people encountering crashes by plugins everyday. Just look through the forum: most of the crashes and instabilities are indeed caused by plugins, and something like this could be a solution.
Well if you would have read what I am saying all the time repeatedly, you would have seen, that for these kind of plugins you use blacklists and whitelists (like it is in Bitwig).
So, the plugins that uses that they are not sandboxed will still have to be fixed and you can not âdebugâ that they are causing the problem? How do you know if the plugin is using some feature that wont work sandboxed?
What features and in what plugins?
Iâm not sure you understand the concept of âsandboxingâ. It is basically an additional host/abstraction layer in between the DAW and the plugin. The plugin itself wouldnât know the difference between being sandboxed or not.
There are many different ways. One is NLS plugins. I think waves, slate and brainworx have that. There is plugins that let same gui for sharing data. I think I saw that Fabfilter had for their EQ. There are plugins that uses thread pools like NI Kontakt. This does not in anyway conflict with the VST-SDK, but sandboxing is not part of the way VST works. (Nothing prevent Steinberg to add this, but then there is also a need to define HOW data should be shared between sandboxes)
So with your logic, Waves, Slate, NI Kontakt⌠they all donât work in Bitwig or Reaper?
Are you familiar with NI Komplete Kontrol (there are plenty more examples I could use, but Iâll use this one). KK is a VSTi that acts as a VST host itself. Think about it. A host within a host.
I can load Kontakt instances, Waves plugins, you name it; in the Komplete Kontrol host.
If a plugin hosted by KK crashes, does KK crash, does Cubase crash as well as a result?
I donât know. But I do know that KK could be designed so that a hosted plugin does not cause KK to completely crash.
A plugin sandbox as it relates to this discussion is a form of plugin wrapper and plugin wrappers have been around for a long time now.
Huh? Why does that need to be defined and who needs the definition?
Yes, you can wrap vst in different ways. Novation did that with automap many years ago.
That was done without any sandboxing. It did never work very well. I have no idea if they work in Bitwig or Reaper. But with a true sandboxing they should not work as intended. Kontakt is probably only adding a thread-pool for each sandbox so it will only be overhead. (Their thread pool seems to cause a lot of problem for cubase 12.0 even without sandboxing)
The problem with that plugins something crashes is due to there are things that are undefined or they break the rules. The definition is need to make all hosts and plugins compatible with each other. The worst thing that can happen is that plugin vendors start to do different tweaks for each DAW or DAW vendors have special cases for some plugins.
Undefined behaviour is likely ending in a crash, and we do this only to reduce crashes.
Now you are talking about VST2.x / VST3 developer definitions within the API. Nothingâs changed in that department.
Again, a plugin does not know if it is loaded in a wrapper or in a DAW directly. The same applies for a sandbox wrapper. What they are saying in this thread is that Steinberg should implement a sandbox wrapper in Cubendo, not that they should change the VST definition to include a wrapper in the plugin itself.
Youâre clearly misinterpreting something here as was pointed out multiple times. There is no change to the plugin format or its API.
Would be nice if you could just stop derailing this FR. Thank you!
Then it will not work. It will be functional bugs. A sandboxed plugin can not interfere with other plugins thats the hole point with sandboxing, and some plugins use this interfere possibility to do its features. For sure some vendors will develop new ways to make it possible for plugins to communicate and that will cause performance and latency problems.
Well, dream on it wont work without API adaptations.
Yes it does.
And now please stop spread misinformation here.
Sees to be a reasonable way. But note that they emphases that it will have performance impact, and in the end they say that you put 1-2 plugins. So you still need to find out what plugins is causing your problem. And this would be a grate feature for Mac users running mixed native and rosetta2 plugins and you still need to have knowledge on what plugins do internal communications. And totally silence about what latency it will add, and on what latency it will work. They dont even claim that it works for real time tasks.