Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ableton Live 11

ableton.com

Post reply on HN
Print view View original

261–268 of 268 posts

Re: Ableton Live 11

#261

Post by pottering »

varispeed wrote: post #257
spacechild1 wrote: post #240

Earlier quoted context omitted.

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 pl…

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…

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

Re: Ableton Live 11

#262

Post by filoleg »

adamnemecek wrote: post #61
enumjorge wrote: post #59

Earlier quoted context omitted.

I’m seeing a pattern in the lack of detail ;)

The main problem is that I'm going for something somewhat different than what current DAWs are and I feel like what I'm going for will be easier to understood by seeing it. Tell me what you expect I will tell you whether your workflow is supported. If you are interested, sign up and I'll notify you when I launch.

>I feel like what I'm going for will be easier to understood by seeing it

Agreed, but I hope you realize this is pretty much why people are having such negative reactions to it in this thread. For something that is "easier to understood by seeing it", the biggest mortal sin is pushing it without having anything to actually show that people can see.

Re: Ableton Live 11

#263

Post by varispeed »

pottering wrote: post #260
varispeed wrote: post #259

Earlier quoted context omitted.

Yes I did such tests and then compared the same scenario with jBridge.

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…

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.

Re: Ableton Live 11

#264

Post by spacechild1 »

varispeed wrote: post #257
spacechild1 wrote: post #240

Earlier quoted context omitted.

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 pl…

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…

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.

Re: Ableton Live 11

#265

Post by spacechild1 »

varispeed wrote: post #257
spacechild1 wrote: post #240

Earlier quoted context omitted.

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 pl…

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…

> 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.

Re: Ableton Live 11

#266

Post by varispeed »

spacechild1 wrote: post #265
varispeed wrote: post #257

Earlier quoted context omitted.

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…

> 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?

Re: Ableton Live 11

#267

Post by spacechild1 »

varispeed wrote: post #266
spacechild1 wrote: post #265

Earlier quoted context omitted.

> 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.

Re: Ableton Live 11

#268

Post by spacechild1 »

varispeed wrote: post #266
spacechild1 wrote: post #265

Earlier quoted context omitted.

> 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?

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.

Post reply on HN