Table of Contents
Plug-in instance re-use in Unify v1.3.x
Principle of instance re-use
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.)
Rule-based system to govern re-use
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:
- Windows: %AppData%\PlugInGuru\PluginRules-Unify
- Macintosh: ~Library/Application Support/PlugInGuru/PluginRules-Unify
Format of XML plugin-rule files
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>
- The first rule will accept any Spectrasonics plug-in, regardless of its format.
- e.g. Omnisphere 2, Keyscape, etc.
- There rule has no
formatattribute, so it matches any name, any format.
- The second rule is intended to match any of Native Instruments' Kontakt plug-ins.
- The rule will match any plug-in whose vendor name begins with
Native Instrumentsand whose name begins with
- The wildcard character
%is used at the end of the
vendorattribute, because NI's plug-ins sometimes show up as
Native Instrumentsand other times
Native Instruments GmbH.
- The wildcard character
%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.
- The third rule is intended to match Native Instruments' original Massive plug-in.
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.
- The fourth rule matches
- These strings always show up the same way, so no wildcards are needed.
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.
Editing the plugin-rule XML files
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.
About the Unify v1.3.2 default rules
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.
- Guru Sampler was found to be unsuitable, and since there is really nothing to be gained by re-using built-in plug-ins, we decided to simply deny them all.
- Omnisphere 2, which is particularly important to PlugInGuru customers, and which can also be quite slow starting up, was the primary impetus behind our decision to implement at least limited plug-in instance re-use. Our decision to try re-using Omnisphere 2 instances was based on specific advice we received from the Spectrasonics development staff, who also explained that what works for Omnisphere 2 will most likely also work for the entire series of Spectrasonics plug-ins.
- Kontakt 5 and Kontakt 6 (aka just “Kontakt”) are also extremely important to PlugInGuru customers, and re-use seemed to work well in the limited amount of testing we had time for, so we decided to include it.
- Version 1.0.0 of Brian Clevinger's Plasmonic plug-in suffered from very long start-up time, making scrolling through patches in the PlugInGuru Unified - Plasmonic patch library very unsatisfactory, so we decided to test that on as well, and again it seemed to work well.
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:
- Native Instruments FM8
- U-He Diva, Zebra2
- Reveal-Sound Spire
- Lennar Digital Sylenth1
- Vital Audio Vital
We plan to set up a special area on the PlugInGuru Forums where users can post additional results.