CONCEPTS - CPU Optimization & Conservation

 

 

One of the most difficult questions to answer is how much CPU power Omnisphere uses. The reason it's so difficult to answer is because STEAM™ was designed as a very flexible and open system, which allows you to freely add FX and more editing power based on the needs of what you want to create. This means that Omnisphere is capable of using all available CPU power and then some!

It's to be expected that the average patch in Omnisphere uses more CPU than the average patch in most other synths. That's for the simple reason that the average patch in Omnisphere has more things going on than the average patch in most other synths. Simple bread and butter sounds have been done...we're aiming for something beyond that with Omnisphere. However, we are always striving to improve CPU performance and hope to further improve performance in future updates.

There are a large number of features that you can enable in Omnisphere, and if you turn enough of them on you'll eventually overload any CPU. The point at which that happens depends on a lot of things: the number of Omnisphere parts in use, the number of plugins in use, the CPU power, etc. As a result it's impossible to predict what represents a reasonable number of enabled features for every given situation. If you are running into performance issues, it's best to turn off unnecessary features. Here's a summary of example things to try:

• Turn down polyphony.
• Turn down amplitude envelope release.
• Look for effects that can be turned off.
• Look for oscillator section features that can be turned off.
• In the case of Unison, try turning down the depth.
• Metal Pipe and AllPass filter types use more CPU than other filter types.
• Use one filter instead of 2.
• Glitching in the absence of a CPU overload might indicate a streaming underrun. If that's the case, try turning up the Pre-load memory size.

As you can see, there are several ways to help conserve CPU power in Omnisphere. The following detailed tips and techniques are especially useful in busy sessions when trying to make the most of your computer’s resources.

 

64-bit Instruments & Hosts

If you are using a 64-bit host (such as Logic 9.1), it can access all available system memory without the usual 3Gb limit. This means that you are less likely to run out of memory when loading very large instruments, or a large number of instances. If you find yourself running low on memory, you should add as much physical RAM as possible to get the most from your 64-bit software. 

All Spectrasonics instruments are 64-bit, on both Mac and PC. 

Sample File Server (Mac only)

For Macs running 32-bit host software, the Sample File Server allows you to load large sounds into physical RAM, bypassing the usual 32-bit System Memory limit. It is recommended to have a minimum of 6Gb of RAM installed when using the Sample File Server. 

Windows users should use 64-bit host software.

 

NOTE: If you are running a 64-bit host (such as Logic 9.1), the Sample File Server is unnecessary, and you may get better performance with it disabled.

 

Sample Thinning

Sample Thinning allows Soundsources, Patches, and Multis to be loaded with fewer samples when selected, so that less system memory is used. This is especially important when loading large Trilian sounds into Omnisphere, using Omnisphere Library Integration.

Omnisphere provides Thinning options from the System Page, the Edit Page (Soundsource Zoom Edit View), and from the Patch & Multi Browsers

There are four types of Sample Thinning available; Round Robin samples, Legato samples, Velocities, and Pitch Thinning.

When loading larger sounds, such as Trilian sounds inside Omnisphere, using Thinning can make a huge difference in overall system memory demand, and these can be used in combination to balance between the best sound possible, and the conservation of resources.

 

Host Buffer Size

Performance and CPU load with all virtual instrument plug-ins are sensitive to the host's audio buffer size - particularly with an instrument as powerful as Omnisphere. If you experience performance issues with Omnisphere such as audio drop-outs, you can gain further Performance headroom by raising your host's audio buffer setting. A setting of 256 is usually a good compromise between good performance and acceptable latency, but you may wish to increase the buffer size if you need more CPU power. Omnisphere will also work with larger buffer sizes, so you can try adjusting this setting in your host.

 

Host Sample Rate

Omnisphere has been designed for optimal playback at 44.1k or 48k sample rate. If a host's project sample rate is higher than this, (88.2k, 96k, 192k, etc) it can have a significant impact on reducing Omnisphere's performance, without any real sonic benefit to Omnisphere. In fact, certain patches may not sound correct at higher sample rates. So we recommend keeping your host's sample rate at 44.1KHz or 48KHz for the optimal experience with Omnisphere.

 

Multi-Instance vs Multi-timbral

On single and dual-core systems, it's best to load multiple Parts (on different MIDI channels) within a single instance of Omnisphere, before opening any additional instances of the intrument. This is the best way to utilize the available CPU power for Omnisphere.

However, if a multi-core system is used, it can be beneficial to open multiple instances of Omnisphere to distribute the processor load between the cores. The resource handling is done by the host, so in this case it's useful to open more than one instance of Omnisphere. So the most efficient use on a multicore machine is to use a couple of instances multitimbrally - if assigning all Parts to a single instance is using up all the resources of a single core. Consult your host's documentation to make sure that it has support for multi-core/multi-processor systems.

 

Limiting Voices

Omnisphere allows up to 64 voices of polyphony per Part. This can put tremendous demand on the CPU, so limiting polyphony is one of the most important things you can do to manage CPU usage.

As a general principle, set the voice count according to the type of Patch you are working with. For example, Texture or SFX Patches typically don’t need 16 or even 8 voices of polyphony. Anytime you are running low on CPU power, this is the first area to look at for conserving CPU.

To adjust polyphony for a Part, use the VOICES stepper on either the Main or Edit Pages.

 

Voice Multipliers

When using Granularity and Unison, the Depth sliders control the number of simultaneous voices that are playing, and so can have a big impact on CPU usage. You can often achieve the desired effect using a lower Depth setting.

 

Oscillator Sub-Pages (FM, RING, WS, MULT)

It’s easy (and fun!) to use all of the oscillator sub-pages at the same time, but used together these can demand a significant amount of CPU power. Using them sparingly will often lead to better sonic results and be easier on the CPU load.

 

Single Layer vs Dual Layer Patches

There’s a lot that can be done with a single Layer. If you can achieve the desired sound or complexity using one Layer instead of two, it’s likely that a significant amount of CPU power can be conserved.

 

Common FX vs Layer FX

Using Common FX whenever possible is a great way to save CPU power. Instead of loading separate delay units into each Layer FX Rack, try sharing a single unit in the Common FX Rack.

 

Waveshaper

The Waveshaper is a great feature, but it can be very CPU intensive, because it is polyphonic. To save CPU, you can try alternate approaches to achieving the desired sound. For example, try experimenting with the Flame Distortion unit first. You could get similar results without putting as much demand on the CPU.

 

FM/Ring Mod

Both FM and Ring Mod have dedicated oscillators, thus using additional CPU power. Combining these with additional oscillator features like Waveshaping or Unison can add a lot of required processing.

 

Unused Modulation Routings

Modulation routings sometimes use CPU power, so be sure to remove any unused routings. For example if you are modulating FM Depth with a Mod Envelope, but then decide to turn FM off, remove the modulation routing to further reduce demand on the CPU.

 

Bypass Unused FX

When Bypassed, FX Units do not consume CPU power. To conserve CPU power, Bypass any loaded FX when they are not in use. This especially applies to Aux Send FX, since the entire Aux Send system is enabled even if you are only using one Send.

 

EZ-Verb vs. PRO-Verb

EZ-Verb doesn't necessarily use less CPU power than PRO-Verb. PRO-Verb has a variable CPU Power parameter, where EZ-Verb's CPU Power is fixed. This parameter changes the number of reflections in the reverb signal, and a higher setting is not always a “better” sound -but more reflections require a higher amount of power to achieve. Sometimes lower CPU settings will produce a more desirable result. If PRO-verb is set to maximum CPU, it takes much more power than EZ-Verb - while lower PRO Verb CPU settings (like the default settings) can actually require less power than EZ-Verb.

 

Sharing FX with Aux Racks

When using FX like reverbs, it's often better to use the reverb on an Aux Rack, instead of as an Insert.  There are times when several sounds need reverb, and instead of inserting 6 reverbs into 6 individual Parts, you could instead place only one reverb on an Aux Rack and then use the Aux Sends to send all six sounds to the single reverb unit.  This is far more efficient on the CPU.

 

Aux Sends

If you are not using the AUX Sends on the Mixer Page, make sure all of them are off (all knobs turned fully counter-clockwise). When all of the Aux Sends are off, the entire AUX system is disabled, which saves CPU power.  If any of the Aux Sends is on, the entire Aux Send system on all Racks and Parts is enabled, even if no audio is passing through it.