@getdunne Shane, after all this time, this may seem like a total noob question when it comes to the advantages of using Unify, but I guess I'm just looking for an answer from the source.
I realize there are lots of variables involved with system configurations, DAW, plugins, etc., but will I always be better off in terms of a more efficiently operating environment if I load an instance of Unify with the plugin and preset that I want over just loading the plugin and preset in a DAW channel?
In other words, in the interest of efficiency and better utilization of resources, should I always use an instance of Unify over just the plain plugin? Will I be better off with 6 or 12, or 48 channels of Unify than multiply individually loaded instruments?
Hi, I’m also interested in this topic (in Windows PC context). To find out more, I created four projects in Studio One containing 80 instances of the following plugins (per project): Unify, KV Element, BC PatchWork and Image Line MiniHost Modular. OS CPU Performance Monitor shows similar number of processes for each scenario, but number of threads is almost doubled in case of Unify (which also has the highest CPU load - with its Init patch - than other plugins according to OS and DAW performance monitors).
What worries me, is that inserting 1 instance of MusicLab Real Guitar to Unify layer shows similar CPU load to NI Maschine running 4 instances of the same plugin (on 4 different MIDI channels with audio routed to 4 different stereo outputs). On my system, Unify seems to be adding up to 30% CPU load to all plugins I tried comparing to running these plugins directly (projects usually contains up to 20 Vsti).
Loading individual plug-ins directly in the DAW will be more efficient than using Unify. Unify offers some nice capabilities for working with combinations of plug-ins, but there is a cost to this.
You are comparing Unify, which is multi-threaded, with three single-threaded hosting utilities. Multi-threading involves some overhead, which is usually low compared to the CPU usage of the actual plug-ins hosted within. To magnify the overhead to the point where it's measurable, you're loading 80 instances.
It has taken some effort to keep Unify's overhead down, and I may need to review it soon, given that we have added a lot to Unify since version 1.
I see, thanks for the detailed explanation. I understand that to do all the magic, Unify needs to reserve some resources first.
Loading individual plug-ins directly in the DAW will be more efficient than using Unify. Unify offers some nice capabilities for working with combinations of plug-ins, but there is a cost to this.
You are comparing Unify, which is multi-threaded, with three single-threaded hosting utilities. Multi-threading involves some overhead, which is usually low compared to the CPU usage of the actual plug-ins hosted within. To magnify the overhead to the point where it's measurable, you're loading 80 instances.
It has taken some effort to keep Unify's overhead down, and I may need to review it soon, given that we have added a lot to Unify since version 1.
I'm a bit confused by this, as it does not match my experience. In my thread about the Beethoven midi files, In Cakewalk I found that it was much more efficient to load 12 instances of BBCSO Core in Unify than it was to load 12 separate instances directly in Cakewalk to play the same 12 midi files.
I had similar results with NI Kontakt some time ago - it worked better inside Unify than loaded directly into DAW tracks
@getdunne Shane, thanks for the clarification.
I guess since the beginning I misinterpreted some comments about the advantages to using even SINGLE instances inside Unify, and the utilization of the multithreading/cores on the Mac, especially in reference to Omnisphere. It definitely makes sense with layered patches and multiple instruments.
I guess that will keep me from wasting time and an extra step placing single instances of an instrument inside Unify inside my DAW.
As you see, this is not a simple issue at all. @mschiff and @robert-p report cases where even single instances of some plug-in exhibit lower CPU usage inside Unify than directly in the DAW.
This is the case with Omnisphere 2, and I happen to know why, because the developer told me: Opening even one instance of the plug-in's GUI triggers a substantial amount of ongoing activity. In most DAWs, instantiating a plug-in automatically opens its GUI; the only time this does not happen is when you load a previously-saved DAW project. Hence in the case of Omnisphere 2, you'll always see higher CPU usage whenever you add an instance of the plug-in via the DAW's GUI.
Also, there are good reasons to want to load even single instances of a plug-in via Unify, but for most plug-ins, reduced CPU usage is not one of them. The main reason is for improved work-flow; this is the whole basis of Stefano Maccarelli's unified Ethera Gold 2.5 libraries.
Unify might not reduce CPU usage for single hosted plug-ins (except in a few cases like Kontakt and Omnisphere 2, which are rare but very significant), but for plug-ins whose CPU usage is actually significant, it won't increase it substantially either.
@getdunne Shane,
I was just about to write you back regarding Omnisphere, because I kept thinking about John's comments regarding Tetrasonics, and specifically how some of the presets were so brutal that even a single one would experience issues when directly loaded in a DAW, or even in Omnisphere standalone, yet ran super-efficiently in Unify, even to the point that they could be stacked.
I realize that there are many advantages beyond CPU issues/performance for loading plugins inside Unify, inside a DAW, but I'm also just trying to be mindful of working as efficiently as I can, since I'm on a 2012 Mac Mini, 2.6 GHz Quad-Core i7, with 16gb of RAM.
Thanks again for all the info, and for all the great work!
David
My main studio machine is a 2012 Mac Mini with exactly the same configuration!
No matter how powerful a computer you have, if you you use a lot of heavy-duty plug-ins, you eventually have to resort to DAW techniques like "freeze" and "bounce in place".
Also, there are good reasons to want to load even single instances of a plug-in via Unify, but for most plug-ins, reduced CPU usage is not one of them. The main reason is for improved work-flow; this is the whole basis of Stefano Maccarelli's unified Ethera Gold 2.5 libraries.
I don’t mind giving away a few CPU cycles in return of the workflow and flexibility – If I had to create a separate MIDI Fx track in my DAW for each instrument I use (instead of combining them inside Unify), overall CPU load would be probably even higher. Also, with the upcoming optional multi-output extension, we’ll be able to combine up to 16 instruments (or multi-instruments) within one instance of Unify and send the audio from each instrument to separate DAW/Mixer track.
