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

9: Graphic UI - Setup View 123 Receptor Manual
Memory
This displays information about Receptor’s internal RAM. Specifically, it shows how much RAM is installed in
your Receptor and what percentage of that RAM is currently free.
Enable Zload
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.
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.
Here are a couple more details you may wish to know about Zload:
•
Some plugins keep audio in a buffer that does not get flushed when it’s set-aside by Zload. When this
happens, that plugin may make sound when re-loaded (since it will then empty its audio buffer). This
is a fairly rare occurrence and is pretty harmless in studio operations. But, if you’re using Receptor
live or sequencing with Single or Multi patch changes, you may want to check for this and, if it proves
problematic, disable Zload.
• Zload is currently disabled for all “Unsupported Plugins” whether you choose to enable Zload or not.
Future versions of Receptor will allow direct plugin-by-plugin control of Zload, so you can choose exactly
which plugins you want Zloaded and which you don’t.
Zload is a great asset that will greatly improve instantiation and patch loading speeds. Give it a try.