Unfortunately I cannot get used to the workflow in other DAWs so I have to use workarounds. Other DAWs handle it miles better - especially Reaper. I am running very CPU heavy plugins and that bring Ableton to its knees. That's fine as long as the playback is uninterrupted.
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. 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. As I stated in other comments, the performance is improved even with the losses coming from context switching. You are essentially running all plugins in its own processes. Your assumptions are wrong, because when you run jBridge A B and C are sandboxed. I can't prove this because I can't look at the source code, but for me this is the most likely explanation. 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. You can just as well dispatch items to a thread pool, so everything stays within the same process. Note that you don't need sandboxing for this. This is technique is sometimes called the "pipelining" (see "2.3" in. If you have several of such sandboxed plugins in a row, this can easily add up. However, this adds additional latency of 1 audio block. Now you indeed have things run in parallel. This means that the thread can go on to compute "C" because it can take the result of "B" from the previous DSP tick. I think jBridge might actually collect the result of the subprocess in the next DSP tick. 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. So while the subprocess for "B" might run in another thread, the main audio thread has to go to sleep. You then have to wait for "B" to finish before you can go on and compute "C". After you've computed "A", you take the output and pass it to "B".
So, if you consider gear upgrade anytime soon, just go for it with no hesitation.To elaborate why sandboxing itself can't help performance, let's assume you have an FX chain A -> B -> C and "B" is sandboxed. It’s also just easier for eyes to get high-DPI monitor, such as mine 4K at 27″.
There are of course many others plugins with scalable GUI, which I don’t own or use however.Īll in all, high DPI is getting more accessible and useful. It is knows that Native Instruments also considers it – they recently even ran a poll, which suggested possible GUI resizability for Reaktor. It is expected that also the rest of iZotope family gets it, as well as AAS – Ultra Analog just enabled this feature, though I’m only waiting for their Chromaphone 2 update.
Massive X, Dune 3 and the newest Cableguys bundle in particular offer drop-down menu with predefined sizes, while Ozone 9 offers free scaling via mouse drag. Without it, some plugins receive incorrect DPI or try to upscale twice at a time, leading to heavy distortion and unusable GUI.Īdditionally, over last two years many plugins have received or are going to receive high-DPI scaling.
To enable internal Ableton scaling under Windows, the automatic Windows 10 scaling system needs to be turned off and use application internal scaling instead.Namely, jBridge plugins don’t work with resizable windows, neither plugins which already offer free drag-to-resize feature.