<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 16, 2018 at 4:31 PM jonetsu <<a href="mailto:jonetsu@teksavvy.com">jonetsu@teksavvy.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 16 Nov 2018 20:29:59 +0100<br>
Robin Gareus <<a href="mailto:robin@gareus.org" target="_blank">robin@gareus.org</a>> wrote:<br>
<br>
> On 11/16/2018 08:22 PM, jonetsu wrote:<br>
>> At the moment each plugin is a distinct linvst process, which<br>
>> prevents them from communicating between each other (very minor<br>
>> drawback).  <br>
<br>
> Try that with 64 tracks, 2-3 plugins (Compressor, EQ) per track and<br>
> the cost of context switches will become obvious.  It's far from<br>
> minor, even on modern CPUs.<br>
<br>
Fortunately, in the Ardour/Mixbus(32C) family the compressors and EQs<br>
per track are already built-in.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Absolutely not true of Ardour.</div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So that leaves the processing power for other, specialized, plugins.<br>
Maybe a special compressor is needed.  Or a special EQ.  Or of course,<br>
effects of all kinds.<br>
<br>
And also, if 64 tracks with 2-3 plugins is what constitutes a<br>
processing challenge, then that leaves a lot of room for other uses.<br>
So far at the creation stage, which is done in Bitwig (all mixing is<br>
done in Mixbus32C) I've ran perhaps 35 tracks with maybe 20 of then<br>
being soft synths (both Linux native and linvst) and others being audio<br>
tracks with some having plugins (also both Linux and linvst).  All of<br>
them running in the default config of what Bitwig calls 'independent<br>
plug-in host process for each plugin'.  On a i5 3.2GHz with 16G RAM.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">You're not really understanding the challenge.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">The context switching between the plugin "host" and the actual DAW takes time. Actual time. Not very much time, but actual time.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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. <br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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? <br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">For movie post-production, 64 tracks is the bottom end of the track count scale. 200 might be common.</div><br></div><div> </div></div></div>