[Ardour-Users] GUI toolkit support

[Paul Davis]

On Fri, Nov 16, 2018 at 4:31 PM jonetsu <jonetsu at teksavvy.com> wrote:

> On Fri, 16 Nov 2018 20:29:59 +0100
> Robin Gareus <robin at gareus.org> wrote:
>
> > On 11/16/2018 08:22 PM, jonetsu wrote:
> >> At the moment each plugin is a distinct linvst process, which
> >> prevents them from communicating between each other (very minor
> >> drawback).
>
> > Try that with 64 tracks, 2-3 plugins (Compressor, EQ) per track and
> > the cost of context switches will become obvious.  It's far from
> > minor, even on modern CPUs.
>
> Fortunately, in the Ardour/Mixbus(32C) family the compressors and EQs
> per track are already built-in.
>

Absolutely not true of Ardour.

So that leaves the processing power for other, specialized, plugins.
> Maybe a special compressor is needed.  Or a special EQ.  Or of course,
> effects of all kinds.
>
> And also, if 64 tracks with 2-3 plugins is what constitutes a
> processing challenge, then that leaves a lot of room for other uses.
> So far at the creation stage, which is done in Bitwig (all mixing is
> done in Mixbus32C) I've ran perhaps 35 tracks with maybe 20 of then
> being soft synths (both Linux native and linvst) and others being audio
> tracks with some having plugins (also both Linux and linvst).  All of
> them running in the default config of what Bitwig calls 'independent
> plug-in host process for each plugin'.  On a i5 3.2GHz with 16G RAM.
>

You're not really understanding the challenge.

The context switching between the plugin "host" and the actual DAW takes
time. Actual time. Not very much time, but actual time.

Multiply this up across many plugins in many tracks, and it starts to be an
appreciable fraction of the entire time available to process a buffer's
worth of audio.

Now, if your DSP load without the out-of-process plugins was very low, then
the out-of-process aspect won't push it up into territory where you have
problems (though the chance of this increases as the buffer size goes
down). But the out-of-process part is "stealing" time from the available
processing part. Your system may be fast enough to deal with it - that's
great. But the "theft" is real whether it causes you problems or not, and
it points to the fundamental problem with this design. It's not hard to
come up with scenarios where even though there are zero problems, your CPU
is spending more time context switching than actually processing audio. And
for what? To workaround buggy code?

For movie post-production, 64 tracks is the bottom end of the track count
scale. 200 might be common.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-users-ardour.org/attachments/20181116/7dd43fb6/attachment.html>