Early versions of Unify used to purge all of the current patch's plug-in instances from memory, before loading a new patch. This approach had a subtle disadvantage with a few large third-party plug-ins (most notably Omnisphere 2 and others by Spectrasonics), where loading the first instance required extra set-up. Such plug-ins would always load slowly in Unify, because the first instance loaded in every Unify patch was effectively always “the first instance” (as all previous instances had been purged).
To work around this problem, Unify v1.2.x deferred discarding the current patch's layers (and their associated plug-in instances) until after the new patch finished loading.
Unify v1.3.x takes this approach further: As a new patch is being loaded, Unify inspects the current patch's INST layers, to see if any of them use an instrument plug-in that can be re-used. If so, all MIDI and audio-effect plug-ins on the layer are purged (the reasons for this are too complex to explain here), and the new INST layer is built starting from this stripped layer. The instrument plug-in instance is thus not purged from memory at all; it is simply updated with the state-data from the new patch.
This approach works very well with the the Spectrasonics plug-ins and some others, but not all. A few plug-ins perform certain initialization steps when first instantiated, which are not repeated each time they are updated with new state-data. (This is not too surprising, since DAWs normally load state-data into each plug-in instance only once, when re-loading a saved project, so the programmers don't expect them to receive new state-data again later.)
Because we don't know which plug-ins can be re-used and which cannot, we decided to make Unify 1.3.x flexible enough that the set of allowed plug-ins can be altered just by changing some files. There are two files, ReuseDenyRules.xml and ReuseAcceptRules.xml, and they are found in a new folder called PluginRules-Unify as follows:
As you will see below both files are basically a series of
PluginRule items (which we call “rules”), each of which can optionally have
name attributes. A percent character
% at the end of the
name attribute is a “wildcard” which will match any suffix.
When Unify considers re-using a given plug-in instance, it compares that plug-in's format (
Built-In), vendor name (e.g.
Native Instruments), and plug-in name (e.g.
Massive) against each of the available rules, in order to decide whether to reuse it or discard it. (See Unify's Known Plug-Ins view for the exact spelling and capitalization of these attributes.)
The “deny” rules are applied first. If ANY of the “deny” rules is matched, the plug-in will not be reused. Unify v1.3.2's default ReuseDenyRules.xml file contains just one rule, and looks like this:
<?xml version="1.0" encoding="UTF-8"?> <PluginRules> <PluginRule format="Built-In"/> </PluginRules>
Basically, if the plug-in type is
Built-In, it will NOT be re-used. This is partly because Unify's built-in plug-ins were not designed for re-use, but mostly because new instances can be created so quickly that there is nothing to be gained by reusing them.
If the plug-in instance being considered does not match any of the “deny” rules, it is checked against the “accept” rules. The plug-in WILL be reused if it matches AT LEAST ONE of these rules. Unify 1.3.2's default ReuseAcceptRules.xml file contains four rules, as follows:
<?xml version="1.0" encoding="UTF-8"?> <PluginRules> <PluginRule vendor="Spectrasonics"/> <PluginRule vendor="Native Instruments%" name="Kontakt%"/> <PluginRule vendor="Native Instruments%" name="Massive"/> <PluginRule vendor="Rhizomatic" name="Plasmonic"/> </PluginRules>
formatattribute, so it matches any name, any format.
Native Instrumentsand whose name begins with
%is used at the end of the
vendorattribute, because NI's plug-ins sometimes show up as
Native Instrumentsand other times
Native Instruments GmbH.
%is also used at the end of the
nameattribute, so that the rule will match both
Kontakt(Kontakt 6 and later) and also
Kontakt 5or earlier.
vendorattribute ends in
%as explained above for the second rule.
nameattribute does not end in
%, in order that
Massivewill be matched, but
Massive Xwill not.
Note the attribute
descName can be used instead of
name, to use the so-called “descriptive name” instead of the full name. On some systems (especially Windows PCs), the full name for a plug-in might be something like
Serum_x64, but the descriptive name may be simpler, e.g.
Serum. Hence using the descriptive name may be easier than using the wildcard character
% on the full name.
These are XML files, which are in UTF-8 plain-text format (see about_plain-text_files). Please do not attempt to edit these files unless you have a true text-editor program and are comfortable with using it, AND are familiar with XML encoding and the need to match start- and end-tags.
Suppose you wanted to test Native Instruments' Massive X plug-in, to see if it can be safely re-used. You could either add a new rule to ReuseAcceptRules.xml like this
<PlugInRule vendor="Native Instruments%" name="Massive X"/>
or, in this case, you could simply modify the existing third rule by adding a
% at the end of the
name attribute like this:
<PlugInRule vendor="Native Instruments%" name="Massive%"/>
Note this only works because we know for sure that Native Instruments does not have any other plug-in whose name begins with the prefix
Massive. If they were to introduce a new one called, say
MassivelyHugePlugin, you would either have to use the non-wildcard form of the rule, OR you could use the wildcard form, and then add a rule like this to ReuseDenyRules.xml:
In this case, it's reasonable to omit the
vendor attribute, if you are pretty sure no other vendor offers a plug-in with that very distinctive name.
The handful of rules included in the default ReuseDenyRules.xml and ReuseAcceptRules.xml files, which Unify v1.3.2 creates automatically if they don't already exist, were chosen based on VERY preliminary testing, and the general idea that it is better to be prudent, and not attempt to re-use plug-ins which had not yet been absolutely proven to work.
A few of the Unify beta-testers have already begun experimenting with altering the rule XML files to test numerous other commercial plug-ins, and good results have been found with the following:
We plan to set up a special area on the PlugInGuru Forums where users can post additional results.