CPU meters have been added to Unify at v1.0.10. They are OFF by default; use the main ops button (center, bottom of the GUI) to toggle them on and off.

There are three kinds of CPU meters:

1. Each layer has its own meter, displayed in the top-left corner of its title bar
2. Total CPU usage is shown on the left side of the icon strip at the bottom of the GUI
3. Proportional usage is shown on the right side of the icon strip.

The Layer and Total meters show the percentage of available CPU time used in GREEN, and if this ever goes above 100%, a small part on the right will indicate the excess in RED.

The Proportional usage meter is always completely filled with color, with the lengths of the five color bars indicating how much of the total usage (green portion of the Total CPU usage meter) is accounted for by MIDI, Instrument, AUX, and Master layers, with a final off-white bar for “overhead” (everything else).

The CPU meters are hidden by default. Use the main ops button (two concentric circles at center, bottom of the GUI) to toggle the CPU meters on and off.

• A single click on the ops button pops up the “main operations menu”; “Toggle CPU meters” is the first item.
• As a shortcut, click the ops button while holding down the ALT button (Windows) or OPTION button (Macintosh)

If you would like to have CPU meters shown by default, go to Settings and check the “CPU meters: Show by default” checkbox.

Computer audio systems process audio data in chunks called “buffers”, each containing a certain number of samples (e.g. 256), which corresponds to a certain amount of time. For example, at 44100 samples/second, 256 samples represents about 5.8 milliseconds; we can call this the “buffer time”. To ensure no interruptions, each buffer MUST be processed in less than this amount of time. How much less it actually takes is a good measure of performance of the system.

Each of Unify's layer CPU meters indicate how long that layer takes to process, as a percentage of the available buffer time. As the percentage gets longer, the length of the green bar gets longer. At 100%, the green bar reaches almost all the way to the right-hand end, and a tiny bit of red will be shown. Above 100%, the amount of red will get progressively longer, maxing out at 150%.

In general, short green bars are good, and red is bad. An occasional flash of red might be OK, but meters consistently “in the red” indicates overload, which you will hear as crackling and drop-outs in the output audio.

The total CPU usage meter tells you the fraction of buffer time Unify as a whole is using up. Due to Unify's use of multi-threading, this will not be quite as simple as the sum of all the layer fractions.

Unify processes each buffer in up to four stages as follows:

1. All MIDI layers (if any) are processed simultaneously, in separate threads.
2. All Instrument layers are processed simultaneously, in separate threads.
3. All AUX layers (if any) are processed simultaneously, in separate threads.
4. The final mix is computed, and the Master Effects layer is processed.

The amount of time required for each stage is, roughly, the amount of time taken by the slowest layer involved. Think of all the layers of each type as running a race: they all start at the same time, but the “winner” isn't important, because the next stage can't begin until they are all done, i.e., until the one in “last place” is finally done.

In addition to the measured per-layer times, there is also a certain amount of “overhead” for thread management and copying data into, and out of, each layer.

The proportional usage meter indicates how the total CPU usage fraction (shown by the total CPU usage meter) is divided, using colors similar to those used for the corresponding layers:

• BROWN represents the time to process all the MIDI layers
• LIGHT GREEN represents the Instrument layers (including any insert effects on each)
• DARK GREEN represents the AUX layers
• PURPLE represents the MASTER EFFECTS layer
• The OFF-WHITE portion at the right represents OVERHEAD

If the total CPU usage meter is showing heavy activity, the proportional meter and the individual layer meters can help you identify the cause.

When the total CPU usage meter shows only light activity (under 25%), you will tend to see a much larger percentage allocated to “overhead”, but this is basically meaningless.

Measuring CPU usage in modern multi-core computers is complicated. Multiple cores can work at the same time, so multiple threads (units of work designated by the program as candidates for simultaneous execution) to run simultaneously. This sounds wonderful in theory—you think “my CPU has 8 cores, so I should be able to run 8 heavy-duty synth plug-ins at once—but in practice it's not that simple:

• A modern operating system has thousands of threads competing for the handful of CPU cores.
• Threads are assigned priority levels, so “high-priority” threads (like audio processing) generally take precedence over lower-priority threads (like flushing data from RAM to disk), BUT they can't do so forever—every thread's priority gradually rises as it gets denied CPU time again and again, until eventually its request is granted no matter what.
• Threads almost never run to completion, because even operations like reading or writing RAM are so slow, in comparison to operations within a CPU core, that it makes more sense for the core to switch to another thread while waiting for them to complete. (The cores only operate directly on data in the CPU's faster cache memory.)

When Unify's CPU meters indicate that certain processes are taking, say, 10% of buffer time, all this really says is that was the time it measured between when the operation started and when it finished. How much of that time was actually spent on audio processing, and how much was spent waiting for the CPU as it worked on other tasks, is impossible to know. In order of decreasing priority, these “other tasks” might include:

• Other audio threads, e.g., other tracks in a DAW, or perhaps other audio-processing programs such as screencasting or networking applications.
• Other hardware-related processing, e.g., handling interrupts from USB, disk, and network interfaces.
• Any other CPU-intensive programs, which set their thread priorities fairly high to provide good GUI responsiveness.
• Every one of the thousands of active threads on the system at any given moment.

You must also be aware that “buffer time” may not be constant.

• The present stand-alone Unify app actually does use constant-length buffers. (You set the length in Audio/MIDI Settings.)
• Most DAWs use a similar system of fixed-length buffers, most of the time.
  • Image-Line FL Studio is the most important exception. Unless you tell it to use fixed-size buffers for Unify, its buffer sizes vary constantly, and can be as short as one or two samples.
  • Logic Pro X uses the buffer length you specify (e.g. 256 samples), except when processing automation, in which case it drops to only 16 samples. It sometimes also switches to much longer buffers (1024 samples) for “idle” tracks (not currently playing or recording).

Unify's overhead processing depends only on the number and type of layers in a patch, NOT the buffer size. Hence, overhead tends to dominate if you (or your DAW) use extremely short buffers.

• If you set your buffer length short enough, Unify will get completely bogged down with overhead, and CPU usage will quickly rise to 100% or more.
• When a DAW switches to shorter buffer lengths automatically (e.g. while processing automation), you may see the “overhead” fraction (white part of the proportional CPU meter) become noticeably larger.
• This is why FL Studio users MUST specify “fixed-size buffers” for Unify. When FL Studio decides to use ridiculously short buffer sizes (which it does all the time, for no apparent reason), Unify won't be able to keep up (due to the very overhead that makes it so efficient with normal buffer sizes).