Muse Research Receptor manual v1.2 - Manual (Page 70)

5: View Buttons in Depth 70 Receptor Manual
SETUP: Disk Free
Rotate the top display knob to select the Disk Free option. This displays information about Receptor’s
internal hard disk. Specifically, the second number (in parenthesis) shows the total amount of user-accessible
Hard Disk space. The first number shows how much of that hard disk space (in GB) is currently free (unused).
S U D i s k F r e e < >
III III 2 5 . 2 1 G ( 3 1 G t o t a l )
NOTE: You may wonder why the total amount of disk space does not equal the size of Receptor’s internal hard
drive. The reason is that this field displays the total amount of user accessible disk space. Some amount of
Receptor’s disk contains the operating system and the Receptor application, itself -- these applications cannot
be removed by the user and, as such, are not reported as part of the total disk space. The total disk space
display is, therefore, the total amount of disk space available for all plugins, patches, and samples.
SETUP: Enable Zload
Rotate the top display knob to select the
Enable Zload
option. Zload™, when enabled, can dramatically
improve the speed at which plugins instantiate. When plugins instantiate faster, Receptor is more responsive to
patch change requests. Multi patches, in particular, will load dramatically faster.
Zload works as follows: When you first instantiate a plugin, it takes the normal amount of time to load
(equivalent to the amount of time it takes to instantiate on a Mac or PC). Then, when you remove that plugin
from Receptor’s mixer, it’s set aside in RAM, rather than fully uninstantiated. The next time you try to
instantiate that plugin (either directly or by recalling a patch that uses that plugin), Receptor will re-use the
instance previously set aside in RAM, which is nearly instantaneous.
S U E n a b l e Z l o a d < >
III III D i s a b l e d
So why is Zload disabled by default? Because, regrettably, nothing in life is free. Since plugins, once
instantiated, are set aside in RAM, Zload demands a greater share of your Receptor’s RAM. In general, this
won’t be problematic, but there are a couple of things to consider when you’re deciding whether or not to use
Zload:
•
Zloaded plugins will never max out your RAM. When Receptor has only 40% of its available RAM
remaining, then the oldest Zloaded plugins will be dropped, allowing you to regain the RAM that they
previously occupied. Obviously, the more RAM you add to Receptor, the more plugins that Receptor will
be able to set aside in RAM and the “snappier” the box will be.
• One possible downside to enabling Zload concerns customers who use large sample libraries. Because the
set-aside cache of Zloaded plugins may consume up to 60% of your unit’s available RAM, this memory
may not be available for loading samples. For example, if you have a sample that currently consumes 70%
of your Receptor’s memory, you’ll be able to load that sample as long as your Zloaded plugins haven’t
consumed more than 30% of your Receptor’s RAM. But, if your cache of Zloaded plugins exceeds 30%
of the available RAM, then the sample will not load. Again, the best remedy is to purchase and install
additional RAM into Receptor.
Obviously, to see the effects of Zload, a plugin must be instantiated at least once. But, once instantiated, that
plugin remains in RAM and any future instantiations will occur very quickly. If you tend to use a lot of the same
plugins in all your patches, then Zload will dramatically speed up plugin instantiation and patch loading.
When you turn Receptor off, all Zloaded plugins are cleared from RAM. This means, when you turn Receptor
back on, first instantiations of plugins will again occur at normal speed, but subsequent instantiations will be
very fast.