This page is under construction. There are many more details to add—coming soon!

When making libraries for Unify, you have to be very careful about commercial plug-ins:

• If you make a library using only plug-ins that are included with Unify, EVERY Unify owner will be a potential buyer.
• If your library also requires ONE commercial plug-in, your market shrinks to Unify owners who already own that plug-in, plus a few more who might buy it just because of your patches.
• If your library requires TWO commercial plug-ins, you would be able to do some really interesting creative things, but your market will be smaller still.
• If you make a library that uses MANY commercial plug-ins in various combinations, almost no one will buy it, because they won't know how many of your patches will work for them. Those that do buy will be very upset every time they see all the other patches they paid for, but can't use.

You also have to think about cross-platform (Mac/PC) issues:

• Any plug-ins you use MUST be available for both Mac and PC, IN THE SAME FORMAT, e.g. VST or VST3.
• Unify saves the “state” (all settings) of each plug-in, as a chunk of binary data which the plug-in itself provides. When a Unify patch is re-loaded, it instantiates each plug-in, passing in the appropriate binary data.
• The data formats for VST, VST3, and Audio Units are VERY different, and there is no automatic way to convert one to the other, because the differences are plug-in dependent. If you create a patch using, say, the VST3 version of Spire, someone who only has the VST version will not be able to play it.
• In our experiments, we have found that VST (i.e., VST2) provides the best cross-platform compatibility. Patches created using only VST2 plug-ins on a Mac will play correctly on a PC, and vice versa.
• VST3 also seems to work cross-platform, but many plug-in vendors are still figuring out the details of the VST3 standard (Steinberg has not been very helpful), so VST3 plug-ins are often quirky.

• You can always create a patch-library as just a collection of shared patches, which you can distribute yourself.
• If your intent is to create a paid-for product, you will most likely want to have it encrypted and licensed for individual use. This is possible by publishing through PlugInGuru.com. Contact John Lehmkuhl admin@pluginguru.com for details.
• PlugInGuru.com is NOT a vanity-publishing service. Third-party libraries must meet John's very high standards to be published under the PlugInGuru brand.

There are a few VERY important details to understand before you start making a patch library for Unify:

1. Every .unify file contains a setting for the Library it’s supposed to be in. Just moving the file to a different folder does NOT change this.
   1. This may change in future versions of Unify
2. Unify v1.0.6 or earlier permits saving a file without specifying its Library at all.
   • This was a mistake, and will be corrected in later versions.
   • It results in files with a blank Library setting; this confuses Unify as described below.
3. When you specify a new library name when saving a patch, Unify creates a folder with that name, AND a Patches folder inside it, where it saves the patch.
4. Both Guru Sampler and KlangFalter save references to sample/IR files relative to the main Unify data folder.
   • For your library to be self-contained, your library’s patches to point to your library’s samples
   • If you put your library’s samples into the Samples folder beside the Libraries folder, you’ll need to re-select them all, as described below.

While on the subject of library names, don't choose something too generic like “Dance vol.1”. Think ahead to when a user has 80 different libraries. They'll need to be able to find yours easily, so name your library's the way you'd name a band, in a way which is somehow unique to you.

Here’s what you need to do when creating a new library:

• Create the first patch (even an INIT patch is OK) and hit Save
  • Choose “New Library…” and enter a new library name
    • If you can’t do that, see below
  • Click Save New… and make sure you’re saving into the Patches folder under Libraries/<your library name>
• Create your library’s Samples folder (see below)
• Select your library name when saving each new patch you create

If you choose the “New Library…” item in the library list, but Unify does not present a text editor where you can type the new name, it’s because you previously saved some patches without specifying a library at all. This confuses the program.

• In the patch browser’s Libraries menu, choose <none specified>
• Open each patch and Save As with a real library name. If necessary use “User Library”.

Once there are NO more patches with a blank Library field, the <none specified> item should disappear from the Libraries menu. If not:

• Quit and re-start Unify
• Rebuild patch database

All of your own samples should go into a Samples folder under Libraries/<your library name>. This folder won’t be created automatically; you have to make it yourself. If the parent folder (shown below as “Your Library Name”) doesn’t exist, go back to the top and save one patch there like I said. This will create the parent folder and the Patches folder. COPY (don’t move) all of your samples into the Samples folder, grouped into sub-folders according to the following folder structure:

• Main Unify data folder
  • Libraries
    • Your Library Name
      • Patches
        • All your patches (.unify files) go here
      • Samples
        • Subfolder 1
          • SFZ files
          • one or more folders containing WAV, AIF, etc. files
        • Subfolder 2
          • SFZ files
          • one or more folders containing WAV, AIF, etc. files
        • etc.

Note you should not put SFZ files directly inside the Samples folder. They should always be grouped under sub-folders (even if there’s only one), or Guru Sampler won’t be able to load them properly.

The reason you should to COPY, not MOVE your samples is that in all your patches, the saved state every Guru Sampler instance is set to look for them in the user Samples folder beside the Libraries folder. To fix this:

• Open every single one of your patches, one at a time, and re-select the sample, starting by choosing your library name in the first menu
• Save each patch (you can do a quick save by Option/Alt-Clicking the Save button)

Only AFTER you have fixed every single sample path in this way, you can finally remove the original samples from the user Samples folder (if you want to; it’s harmless to leave them in there).

If you have already created a ton of patches:

• In Finder/Explorer, MOVE the patch files into your library’s Patches folder.
• In Unify, rebuild patch database. Note this WON'T change the library names in each patch.
• Load each patch one at a time, select your new library name, and hit Save New to save them in the new library's Patches folder.
• Because you moved the patch files in there already, you should be asked each time if you want to overwrite the file; say yes.

These steps should be sufficient to rebuild your library so it’s self-contained. If you can, test on another machine by copying ONLY your library’s main folder. (Make sure to rebuild the patch database on the test machine after you do this.)

At some point in the future, we’ll be adding features to Unify to make some of these procedures a bit more automatic, but that won’t happen soon.