To elaborate why sandboxing itself can't help performance, let's assume you have an FX chain A -> B -> C and "B" is sandboxed. After you've computed "A", you take the output and pass it to "B". You then have to wait for "B" to finish before you can go on and compute "C". So while the subprocess for "B" might run in another thread, the main audio thread has to go to sleep. See how there's actually no parallelism at play? In fact, you lose performance because context switches and thread synchronization (especially wake up from sleep) takes time.
I think jBridge might actually collect the result of the subprocess in the next DSP tick. This means that the thread can go on to compute "C" because it can take the result of "B" from the previous DSP tick. Now you indeed have things run in parallel. However, this adds additional latency of 1 audio block. If you have several of such sandboxed plugins in a row, this can easily add up.
This is technique is sometimes called the "pipelining" (see "2.3" in https://www.complang.tuwien.ac.at/Diplomarbeiten/blechmann11...). Note that you don't need sandboxing for this. You can just as well dispatch items to a thread pool, so everything stays within the same process.
So I think the speed up you observe with jBridge has nothing to do with sandboxing per-se, but is just a side effect of its implementation. I can't prove this because I can't look at the source code, but for me this is the most likely explanation.
Your assumptions are wrong, because when you run jBridge A B and C are sandboxed. You are essentially running all plugins in its own processes. As I stated in other comments, the performance is improved even with the losses coming from context switching. The effect is I am able to run much more plugins than without jBridge without Ableton having a breakdown and task manager shows better core saturation. I also stated I don't care about latency - I run my projects at 1024 buffer plus plugins introduce their own delays, so sometimes it takes a couple of seconds to hear something after hitting play. That's fine as long as the playback is uninterrupted. I am running very CPU heavy plugins and that bring Ableton to its knees. Other DAWs handle it miles better - especially Reaper. Unfortunately I cannot get used to the workflow in other DAWs so I have to use workarounds.
I am not sure why people keep defending this flawed architecture. It's what makes the Ableton community so toxic, but still better than Bitwigs though - if you dare to comment you dislike something about Bitwig you likely get crucified.
Who was defending Ableton's architecture? All I can see are seasoned audio developers (including my humble self) trying to tell you how sandboxing works, how it can't improve performance and how your observed performance improvement are likely caused by something else. So please stop claiming that sandboxing helps performance - it simply doesn't.
TBH, you don't seem to even try to understand our arguments. If a domain expert like Paul Davis tells you something, try to learn from him and not easily dismiss his arguments.
> Your assumptions are wrong, because when you run jBridge A B and C are sandboxed.
Even if that is the case, it doesn't change anything about the point I was trying to make... I acknowledge that jBridge gives you a performance boost, but you're wrongly attributing it to sandboxing. That's all I'm trying to say.
Supercollider (scsynth) and Pure Data - both I'm contributing to -, have single threaded DSP. Users told me that they can use many more VST plugins when they enable the pipelining option in my extension, which matches your experience.
Again, I can't look at the source code for jBridge. The only thing I know for sure is that sandboxing itself only causes performance loss.
To put it short: I think jBridge does “pipelining“ to avoid the context switch overhead. But pipelining can also be done without sandboxing, leading to even better performance. Without pipelining, sandboxing only gives you a performance loss. Sandboxing does not imply parallelism.
I think jBridge might actually collect the result of the subprocess in the next DSP tick. This means that the thread can go on to compute "C" because it can take the result of "B" from the previous DSP tick. Now you indeed have things run in parallel. However, this adds additional latency of 1 audio block. If you have several of such sandboxed plugins in a row, this can easily add up.
This is technique is sometimes called the "pipelining" (see "2.3" in https://www.complang.tuwien.ac.at/Diplomarbeiten/blechmann11...). Note that you don't need sandboxing for this. You can just as well dispatch items to a thread pool, so everything stays within the same process.
So I think the speed up you observe with jBridge has nothing to do with sandboxing per-se, but is just a side effect of its implementation. I can't prove this because I can't look at the source code, but for me this is the most likely explanation.