I notice that whenever I add an embedded Unify layer, the CPU meter shows constant activity in the parent Unify patch, even if the embedded Unify has just a simple utility loaded (like Combobox).
I'm using the VST3 version of Unify.
Is this normal and expected? Any way to avoid this?
Reason being is that I'm trying to set up some master templates with many embedded Unify patches in layers to enable as needed in a live performance, which is unfortunately creating quite a strain on my CPU even when most layers are completely idle.
Just checking to see if I'm missing something here. Thank you!
Hi, I performed the test on my Windows 10 PC - Unify VST2 and VST3 in Studio One 6.1.1 - 1 and 23 embedded Unify layers (each one contains ComboBox only). Here are the results:
This is normal. Unify has a certain amount of overhead due to the way it processes multiple threads. This is mostly inconsequential once "real work" is being done, but you will notice it exactly as you report when all those threads are "idle".
And these are the results of 23 embedded Unify layers with 23 ComboBoxes each (total number of Comboboxes = 529). CPU utilization about 50%, VST performance 36%. Zipped patch attached.
And these are "true bypass" results. 23 Layers - each one contains an instance of MuLab VST Rack. Each rack is loaded with Unify VST containing 23 Layers of ComboBoxes. Again, total number of ComboBoxes = 529, but CPU Load and VST Performance is the same as with 23 ComboBoxes. The "Auto Bypass" available in MuLab is enabled for each rack.
All that embedding creates a huge number of threads, which must all be synchronized. I'm not surprised by the CPU usage figures. If you try hard enough, you can bring any CPU to its knees.
Some day, I might be able to make Unify a bit more efficient, but to be honest, I just want it to work tolerably well for musically-useful patch structures.
All that embedding creates a huge number of threads, which must all be synchronized. I'm not surprised by the CPU usage figures. If you try hard enough, you can bring any CPU to its knees.
Some day, I might be able to make Unify a bit more efficient, but to be honest, I just want it to work tolerably well for musically-useful patch structures.
It's not a problem for me - I combine Unify with MuLab if I need to. It's just the concept of the "Master Templates" with embedded Unify for live performance made me perform that test. The Unify's performance as it is now is just fine for my needs.
Thank you so much @robert-p for your tests! And thank you Shane for your thoughts. So far, my live use is working without clipping, so the CPU overhead isn't crippling. Was just wondering if there was anything else I could do to lower the overhead.
One last question, Shane... Do you have a sense of what the lowest load "default" patch be? An empty Combobox seems to invoke more CPU than I expected. I tried Midi Monitor previously.
Alternatively, would it be possible to lock a layer # on Macro Controls? The reason I'm having to include all these "blank" embeds in the "master template" patch is to set up the mix volume on Unify layers INST 1 to N to be mapped to Macro controls for a MIDI controller. I then change the embedded Unify patch as needed.
The only way to reduce patch overhead is to avoid using MIDI and AUX layers and deactivate the Master Effects layer. That's a true deactivation; the layer won't be processed at all.
As for the business about setting up macro controls, etc., I think you're basically trying to push past the limits of what Unify was designed for. To help you more, I'll need to understand exactly what you're trying to achieve.
Please tell me in detail about your live setup. Are you on Windows or Mac? Do you basically want a set-list with one Unify patch per song, or do you need something more complicated?
Attached is a diagram of my live set up. It currently works "as is", so Unify is already doing me a huge blessing! Thank you for that!
I can MIDI enable and control the mix level of up to 7 embedded Unify layers (plus an AUX track, used for AudioDamage's Enso looper) with Macro control mappings using a Novation Launch Control XL for MIDI channel 1-4, which correspond to the Keystep Pro's 4 tracks.
When performing live, I can record loops into Enso per track and then jam over top of them, mix track levels, play with FX, etc, all in real-time.
I'm on Mac. I switched from Logic to Ableton, as Ableton seems to handle multitrack record enable much more gracefully than Logic for live performance.
The two minor issues I'm encountering are:
1. Each layer of these 8-track Unify "master" templates is constantly using some CPU activity even while nothing is playing, which adds up. I note that this does not happen in Unify standalone, so this may be a DAW thing. I recognize that you might not be able to do anything about this.
2. The empty "placeholder" Unify embeds are necessary to pre-map the Macro Controls for mix level and midi enable on the Launch Control's rows of 8 knobs. I can double-click into those Unify embeds to load a new patch if/when needed, but I can't Shift-Load a Unify patch to replace an embedded Unify layer without remapping the mix level and midi enable parameters for that layer.
In a perfect world, I'd love to be able to set a Macro parameter to, say, Layer 8, and have that locked to Layer 8, whether there's an 8th layer or not. Right now, if/when the 8th layer is deleted, the mapped Macro parameter changes to Layer 7, etc. This would allow me to Shift-click to swap patches in and out from the Unify library on the fly during a performance. I can currently do this by clicking into the embedded Unify layers, and enabling 1 or more tracks there, or swapping in a new patch.
One workaround is to set up a Unify patch per "song", but among the many wonders of Unify for me is being able to save a single Unify patch with several favourite presets from a single instrument to pick and choose at will during a performance.
And yes, I know I'm pushing it by loading so many tracks and trying to do it all on the fly... hence wanting to optimize CPU by disabling everything that's not currently actively playing something whenever possible.
Hope you find this helpful!
Thank you for this detailed description. I've started a new topic in the "Unify Live" section of the forum, with a copy of this post. Let's carry on the discussion there.
VST instruments can be effectively disabled when they are placed inside the ComboBox (right click on the instrument and "Toggle Bypass"). We could save quite a lot of CPU power (in live performance scenario) if this could be done "outside of the ComboBox" with the option to link "Toggle Bypass" to the Macro Knob:
- Bypass On - 16 x Hive VST, CPU 8%, VST performance 3%
- Bypass Off - 16 x Hive VST, CPU 22%, VST performance 20%
VST instruments can be effectively disabled when they are placed inside the ComboBox (right click on the instrument and "Toggle Bypass")...
Very interesting results, thank you. I will look into adding the ability to bypass instrument plug-ins in Unify itself, but I still think I can do better by disabling entire layers.
I will also look into adding the ability to link bypass of plug-ins inside ComboBox, to macro knobs, as I see that's not available yet.
One more interesting thing: the ComboBox loaded to Audio Effect slot on Instrument Layer can also contain a VST Instrument (the slot receives MIDI). Bypassing the FX Slot itself also disables the instrument and reduces CPU load.
ComboBox loaded to Audio Effect slot on Instrument Layer can also contain a VST Instrument (the slot receives MIDI). Bypassing the FX Slot itself also disables the instrument and reduces CPU load.
Excellent observation, and probably the best work-around available at this point. The diagram below (taken from this page of the Unify manual) shows how on INST layers, incoming MIDI is filtered/modified based on the layer's MIDI controls, then sent to the instrument plug-in AND all audio-effect plug-ins, so you can indeed put an instrument plug-in inside a ComboBox in an audio-effect slot, and even bypass that ComboBox to reduce CPU usage.
What is NOT clear from the diagram is how the pre-filtered MIDI stream is also sent to input of the INST layer's MIDI-effects chain, whose output goes to the instrument plug-in, but NOT to any audio-effects on the audio-effects chain. This means if you want to use MIDI-effects with instruments hosted inside ComboBox in an audio-effect slot, you should put them inside the ComboBox.
(...) This means if you want to use MIDI-effects with instruments hosted inside ComboBox in an audio-effect slot, you should put them inside the ComboBox.
Things should get easier when we place the embedded Unify inside the ComboBox - we could recall patch from the library (with its MIDI effects already configured). I didn't test it but I think it would work.
Thank you so much for your ComboBox bypass tests.
I changed my template to have the embedded Unify patches inside a ComboBox MIDI-effect (using MIDI Monitor for the main layer instrument), allowing me to bypass the layers not needed. The ComboBox bypass button can even be mapped to Macro controls for a hardware toggle button.
Doing so has made a massive difference to the CPU usage. I'm now able to load 30GB+ of plugins on a MacBook with only 16GB of RAM (yikes, I know) without slowing my system to a crawl. There's still an upper limit on how many simultaneous layers can be enabled at once, but the ComboBox bypass works like a charm to cut CPU usage on any layer that's not needed.
A full layer bypass in a future update would be wonderful!
I changed my template to have the embedded Unify patches inside a ComboBox MIDI-effect (using MIDI Monitor for the main layer instrument), allowing me to bypass the layers not needed. The ComboBox bypass button can even be mapped to Macro controls for a hardware toggle button.
Doing so has made a massive difference to the CPU usage. I'm now able to load 30GB+ of plugins on a MacBook with only 16GB of RAM (yikes, I know) without slowing my system to a crawl. There's still an upper limit on how many simultaneous layers can be enabled at once, but the ComboBox bypass works like a charm to cut CPU usage on any layer that's not needed.
Thank you for working through this. This feedback will definitely inform the design of future versions of Unify!