If Live really insists on running [ A, B, C, D, E, F, G ] all in a single thread, then I agree with you, Live is being sub-optimal at best, dumb at worst. Despite their description supporting this notion that their scheduling works this way, I'm skeptical, because they're just not that dumb (I hope! :)
However, sandboxing is absolutely not the simplest way to fix this. Ardour does not and will never sandbox plugins in processes. It just uses a topological sort and a dataflow algorithm to decide what can be run and when, and would execute [ A, B, C ] and [ D, E, F ] in parallel (or could, if on appropriate hardware), before finally running [ G ].
Moving plugins into a separate process has both overhead and complications, and is basically a crazy way to fix this issue, if indeed it is an issue as described.
Yes this is what's happening in Ableton and by your description I'd love if Ableton did the same thing as Ardour.
I understand sandbox is not the simplest, but it is exactly what jBridge does and it gives me better performance in Ableton, so by simplest I meant that Ableton wouldn't have to change how they do processing, as jBridge is just a wrapper - does not modify Ableton in any way.
Again, sandboxing is not done for performance reasons. On the contrary, it degrades performance because of the context switch and thread synchronization overhead. I am saying this as someone who has developed a VST plugin host with sandboxing options.
Finally, please make sure you understand what Paul Davis has tried to explain you. He's a well-respected industry expert.
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.
Are you sure? Because since your theory is based on grouping tracks, it is easy to test, by simply grouping all tracks in a Set with 20 or so tracks that use a decent chunk of CPU. Then all their CPU should shift from several cores into one single core/thread (according to your theory). Of course, being easy I already tested this with a Set that used Live's native devices (no CPU usage change), but I can't test with VSTs right now (none installed). Maybe VST hosting has that problem, but processing of audio summing, Live's own devices and M4L doesn't have any major problem with multi-core.
I think you may be misreading that FAQ page, it mentions sidechain as the reason for using one thread for "dependant" tracks.
Sidechain is not mere grouping/routing like the chain PaulDavis described with ASCII art (different from Sends too), with sidechain the plugin needs the audio from the other track for actual DSP processing, that's why sidechained tracks become a single thread "dependant" signal flow.
That page also mentions Live can use one thread per Chain if needed (for non Live-users, Chains are internal routings inside one single track), so it clearly states Live can use more than one core for one single Track.
Also, plugins like u-HE's use multicore just fine for a single instance, if you disable their own multicore handling (which conflicts with Live's multicore handling).
For Live's own devices, I'm pretty sure multicore works just fine, just tested again with Groups and Sends.
Don't know what problem you have, but it is not simply Live's multicore handling, it is some specific scenario you hit upon.
It doesn't do that. Whatever seems dependant gets lumped into one thread and limited to a single core.
Fortunately Ableton cannot limit what plugins do in their own runtime so as you say U-HE multicore functionality works just fine and jBridge can run plugins off of separate processes.
Not sure why people are being defensive about it or attack for pointing this flaw out. It's great that you think Ableton works as intended for you, but once you go beyond Live devices and use more professional tools, you'll hit the wall. People who I know hit this as well just moved to Reaper, but I cannot get on with its workflow.
However, sandboxing is absolutely not the simplest way to fix this. Ardour does not and will never sandbox plugins in processes. It just uses a topological sort and a dataflow algorithm to decide what can be run and when, and would execute [ A, B, C ] and [ D, E, F ] in parallel (or could, if on appropriate hardware), before finally running [ G ].
Moving plugins into a separate process has both overhead and complications, and is basically a crazy way to fix this issue, if indeed it is an issue as described.