3 ms·
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 o
by varispeed 6y ago
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.
- pottering 6y agoOh please, all replies to you here had facts, or at worst fair, informed assumptions.
- spacechild1 6y agoWho 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.
- spacechild1 6y ago> 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.
- varispeed 6y agoSo why do you think there is huge performance boost when plugins are sandboxed and running in their own processes?
- spacechild1 6y agoI tried to explain this in https://news.ycombinator.com/item?id=25068976 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.
- spacechild1 6y agoPS: here's my own VST host with optional sandboxing and pipelining. Both features are orthogonal. https://github.com/Spacechild1/vstplugin 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.