Productivity : Optimizing Pyramix
26 - 591
dent trade-off cost is a possible reduction in Windows performance and (in the extreme) rendering the
entire system sluggish and even unstable.
VST Core Allocation
VST threads are one of the highest priority threads (godlike) in relation to the overall Pyramix priority scheme
because we try to keep the latency of VST plug-ins as low as (humanly) possible. Pyramix treats every instance of a
real-time VST plug-in in the mixer’s strips and busses as a separate thread of processing.
Each group of VST plug-in threads in a single Strip or Bus will receive that Strip’s or Buses’ audio stream of data to
be processed, one plug-in after the next, so they cannot be dissociated and become a single “thread process
group” in themselves.
When Pyramix has only one core allocated for VST use then all VST thread process groups are sent to that single
core (logical enough). The more VST threads are added and the more those threads are CPU intensive, the more
that core will peak. However, when two or more cores are made available for dynamic VST thread distribution,
Pyramix divides the mixer as per it’s “best guess” of which combination of groups of strips and busses will con-
sume as equal amount of CPU resources as predictably possible and distributes the VST process threads between
the number of available cores allocated for VST plug-ins.
This means that if you had, for example, a mixer with 8 strips of which each strip has an evenly distributed array of
identical VST plug-ins and Pyramix has two cores allocated for VST plug-ins then Pyramix assigns strips one
through four to the first core and strips five through eight to the second core at the moment of mixer allocation.
This helps to keep the chances of peaking on one VST core through unevenly distributed VSTs.
Another more complex example would be to illustrate an uneven distribution of plug-ins on a system with three
cores allocated for VST plug-ins. Picture a mixer of eight strips with two instances of a huge VST reverb on strips
one and two with strips three through eight only having low-consumption VST instances of an equalizer plug-in.
Pyramix would find that the big reverb on strip one consumes nearly half of the resources required to process all
VST threads for that mixer and assign it to one core on its own. It would then assign the second instance of the
reverb on strip two to the second core. The remaining EQ plug-ins on strips three through eight would then be
allocated to the third core basically cutting the mixer in three VST processing zones. Zone 1= Strip 1, Zone 2= Strip
2, Zone 3= Strips 3-8 (and buses).
With this understanding of the distribution by Strips and Buses of VST plug-ins over the allocated cores, you can
analyze more clearly the consumption of CPU resources displayed in the VST core meters at the bottom of the GUI
and better understand when you need to widen the core allocation to compensate for VST core peaks.
Note: As a general rule of thumb it should be considered that the allocation of every available
core for VST plug-ins be an exceptional event and not a recipe for a normal Pyramix setup. This is
much the same as pushing audio buffers to extremes for a demanding Project and resetting
them to their default values for smaller Projects and day-to-day use whenever possible. Pyramix
was designed to work at optimum efficiency with the default values and should be “tweaked”
only when demanding Project circumstances call for it.
To Next Page
Loading...
