Comment by varispeed | Hacker News Reader

Comment by varispeed | Hacker News Reader

Parent Full thread

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.

So why do you think there is huge performance boost when plugins are sandboxed and running in their own processes?

I tried to explain this in https://news.ycombinator.com/item?id=25068976. Read the linked paper if you want to learn more about multithreaded DSP.

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.

PS: here's my own VST host with optional sandboxing and pipelining. Both features are orthogonal. https://github.com/Spacechild1/vstplugin

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.

Oh please, all replies to you here had facts, or at worst fair, informed assumptions.

Reply on news.ycombinator.com