Notifications
Clear all

Recommended steps for creating common 'stationary' and 'mobile' Unify configs

9 Posts
2 Users
1 Reactions
249 Views
(@robert-hunter)
Active Member
Joined: 1 year ago
Posts: 14
Topic starter  

I'm working towards getting both of my Unify configs to be mirrored ...exactly the same, so that patches developed in either config, can then be properly copied into the other config, maintaining access to whatever I create ...in either the stationary rig (Intel iMac) or portable rig (M1 Macbook Pro.

I suspect that many of the steps are already documented in previous responses to library-related questions, and so being pointed to those would indeed be helpful, but ...I think I'm asking a wider question. Unify is obviously accessing both Pluginguru content, and 3rd party synths, FX, samples etc., so I think my overall question takes in the need to not only include all that data, but also the overall file structure (to the greatest extent possible) on both setups.

If I just straight-up ask ...if I copy the data and file structure exactly (from Stationary Unify rig for example ...currently all held within under 3TB on a single drive), and copy it onto a single drive for the Portable rig, will Portable Unify know where anything is when I fire it up, or will it have to 'find' (by being shown where) ...each Pluginguru library ...synth ...FX processor ...or sample is?? Is this a manual process??

I've copied bits of stuff both ways previously, but I still often find that something cool is 'on the other one', and so am trying to understand whether pretty much mirrored setups is possible and practical to maintain?

If my questions are off-base because there is a better way to achieve what I'm trying to do ...I'd be grateful to be schooled on 'how to do it right'.

Limiting to and working exclusively on a single Mac would of course get rid of the issue entirely, but that introduces its own issues ...tear-down and setup possibly being the most obvious ...my iMac screen being my best monitor in the music room is another ...not wanting to shlepp it around on the Vespa ...yuck.

Flow ...o wisdom of the wise ...(please 🙂)


   
Quote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4487
 

@robert-hunter

These are great questions. This is a complex subject, but before getting into all the nasty details, here are the three golden rules:

  1. Unify uses its known plug-ins list to locate plug-ins, so these can be located anywhere; you just have to scan them in once on each machine (in whatever format--VST/VST3/AU--you use when making your patches).
  2. For plug-ins that allow you to set up a "user folder", do so on all your machines, and make sure any resources (samples, wavetables, etc.) are located in the same relative location under the user folder on all machines.
  3. For resources like samples, the best approach is to keep them on a dedicated external disk-drive, and either move it from one machine to another, or clone it and make sure to keep the clones in sync.

As you say, a given Unify patch refers to many resources (plug-ins, samples, MIDI files, etc.), and will only load correctly if those resources are available in the places Unify looks for them.

When John and others create new libraries, they take care to ensure that the patches refer only to resources that are present under the library's folder (a sub-folder of the Libraries folder in Unify's main data folder), OR under the Unify Standard Library folder (which every user will have). In the case of a "unified" library, or a library that makes use of a specific third-party instrument plug-in, there are two additional requirements:

  1. The target plug-in must be registered in Unify's known plug-ins list. You will usually do this manually on each machine, either by running a scan, or adding plug-ins one at a time as described on this page in the Unify manual. It's important to ensure that the correct type ("format") of the plug-in (VST, VST3, AU) is available in the known plug-ins list, because the state-data saved in the patch will only re-load into the same type.
  2. Any resources (e.g. samples) required by the third-party plug-in must also be available, in disk locations where the plug-in can find them.

The second requirement is where things can get very complicated, because we can't control precisely how third-party plug-ins remember (in their state-data) where resources are located. Some plug-ins allow you to create a designated "user content" folder(s), and store resource paths relative to this folder. This allows the "user content" folder to be located at different locations on different computers, provided you put those resources into the "user content" folder.

Plug-ins which allow you to use resources located anywhere (e.g., drag/drop a sample into the plug-in GUI) can deal with this in one of three ways:

  1. Copy the entire resource into the state-data, so it will work on any machine, even if the original resource file is not present. This is the most robust approach, but may result in very large state-data blobs, and hence very large Unify patch files.
  2. Put the absolute path into the state-data. This is obviously the least robust approach, because state-data might become incomplete even for reloading on the same machine, if resource files are moved, renamed, or deleted, but yields the smallest possible state-data size.
  3. Use absolute paths, but pop up an error message if resources are not present, and allow you to locate them manually and re-save. This is the approach used by Kontakt and some other Native Instruments plug-ins.

Absolute paths, e.g. /Library/Audio/Sounds/Banks/... on the Mac, or E:\Rigid Audio\rigid grand on Windows can be really problematic, because they may be difficult or even impossible to reproduce on another machine. This is particularly problematic on Windows, where a path beginning with a drive letter like E:\ can't ever work on a machine that has only two drives designated C:\ and D:\, for example. It tends to be less of a problem on the Mac, but can still be difficult when secondary drives are involved. Often the best approach is to put all your resources on a portable/external drive, and either physically move it from one Mac to another, or clone the drive (and make sure to keep the clones identical over time).

MacOS provides the option to use user-relative paths (e.g. ~/Library/Audio/Sounds..., where the "~" is a stand-in for your own user folder). Any resources stored under your user folder can usually be made available on another Mac by simply ensuring that they are stored in the same folder structure (with all the same file/folder names) on all Macs. However, this won't help if the specific plug-in uses absolute paths, and you have no way to force it to use user-relative paths.

One last thing. Lots of companies are doing everything they can to push users into keeping their files "in the cloud", e.g. Apple with iCloud Drive, Microsoft with their abominable OneDrive, Google with Google Drive, DropBox, etc. These services can be terrific for things like documents, photos, and even videos, but can be problematic for audio files and related resources, for either (or both) of three reasons:

  1. Latency. Any files which are not automatically "mirrored" to the local machine will take much longer to access than local files. When a big sample-set has been added on one machine, but not yet mirrored to another, loading a patch for the first time on the second one might take many, many minutes.
  2. Disk-space demands. Automatic mirroring is basically an automatic version of a cloned external drive, and can be wonderful when it works, but you must ensure that each machine has sufficient available disk-space for the entire mirrored content.
  3. Cost. You will also usually have to pay by the gigabyte, for enough cloud storage for the entire mirrored content as well, and this can really add up as your content expands. Furthermore, all those gigabytes will eventually have to get downloaded to all your machines, which may cost you more with some types of Internet services.

For all these reasons, I advise against using cloud services for audio resources, and go with dedicated external drive(s) instead.


   
Nico5 reacted
ReplyQuote
(@robert-hunter)
Active Member
Joined: 1 year ago
Posts: 14
Topic starter  

Hi Shane - so much here to take in. I will take my time and work through it before asking any follow up stuff (if necessary) THANKS for this.


   
ReplyQuote
(@robert-hunter)
Active Member
Joined: 1 year ago
Posts: 14
Topic starter  

Hi Shane, so I've read and reread your post, and have these follow up observations/questions:

Using Korg and Cherry Audio as (well-loved) examples ...the soft-synths are purchased, you get your download link, the installer file comes ...you follow the steps, and ...in many, many cases, you are offered the choice of where you want to install it, but it's not a real offer. All the other drives 'can't be selected' ...you can typically only select and subsequently install them on the main/local drive. 

This is my common experience (on the Macs I have). Occasionally, a synth will let me install it onto an external drive, but not most. Other files that may be associated with them (using Kontakt for and example) ...Kontakt absolutely lets me set up my library externally, but I'm pretty sure Kontakt itself has to be on the local drive.

My point is ...I think that gets me immediately to a dead end in my theoretical quest for 'identical' setups. The two (in my case, Macs) are 'similar', but they aren't 'identically-mapped-via-installation-process' ...the same as each other.

I'll stop here, because I may be wrong, my lack of strong control of installation processes may need correcting, I may be 'mostly right' ...in that getting the 2 computers to have literally the same file structure 'ain't gonna happen' ...or some combination of the above ...may already have us at ...'it's not really practical or achievable'.

I suspect that some suggestion to wipe one computer and then literally clone the other on to it ...total complete file map and all files ...may work in a lab, but I don't even have the same OSX on these ...intel chips, M1 ...I'm probably blathering at this point.

I'll watch to see if you consider the hoped for result worthy of pursuit and practically achievable.  

Thanks, R


   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4487
 

@robert-hunter

Unify's known plug-ins list exists precisely because we can't always control where plug-ins go. Unify patches that use plug-in XYZ don't care where XYZ is installed--Unify looks up the required plug-ins in the list by name, vendor name, and format (VST/VST3/AU), and that tells it where to find them.

As I explained, compatibility issues usually involve other resources such as sample files. In most cases, you get to choose where these go, and my best suggestion is to put them all on an external drive and either move it from one system to another, or make a "clone" copy for the second machine.

Perhaps if you could give an example where you can't figure out how to a patch load correctly on your second machine, I could offer suggestions about that specific case.


   
ReplyQuote
(@robert-hunter)
Active Member
Joined: 1 year ago
Posts: 14
Topic starter  

Hi Shane ...got the 4TB SSD for portable use ...combing through the macbook Unify patches that need to be transferred to the 'the main mac' for library integration ...then copy the integrated library back on to the portable rig ...at least that's the hope.

I think I'm running into a basic problem ...I've carefully followed the instructions on the 'about .guru files' page of the online manual, or at least as close as I can. The resulting .guru file is not accepted in Unify when dragged in, and as you can see in the picture, the 'User Library.guru' file is greyed out and so not selectable using the 'Select .guru file' tool.

Not sure if it has any bearing, but when I change the .zip file to .guru ...the MacBook does not ask if I want to change the file extension ...it just accepts the change. Also...I can't 're-compress' the newly renamed .guru file. The compress tool is simply not available via right click. Does this indicate some Mac weirdness that needs solving ...then I move back onto working on Unify?

Bye for now,

R


   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4487
 

@robert-hunter

Yes, that's Mac weirdness. You need to set the Finder to show all file extensions. Without that, all you can do is change the name from "User Library.zip" (which you see as just "User Library") to "User Library.guru.zip" (which you see as "User Library.guru", but that's not correct).

Choose Finder > Settings, then click Advanced. Select "Show all filename extensions”. You may wish to change this back later.

Two further thoughts:

  1. To be honest, I'd advise that you don't bother trying to create a .guru file. The process is too error-prone. Just put the files wherever they belong manually in the Finder, then click the lightning-bolt icon in Unify to rebuild the patch database.
  2. You might consider keeping your entire Unify folder to the external drive, then setting Unify (on BOTH your systems) to look there instead of in the default location (or in your case, the "Test Unify Folder" on your desktop). Then any patch you create on either system will be available on the other without copying (provided you connect the external drive).

   
ReplyQuote
(@robert-hunter)
Active Member
Joined: 1 year ago
Posts: 14
Topic starter  

Thanks again Shane - your responses and patience is much appreciated.

Regarding your recommendations

1a) 'don't bother trying to create a .guru file'...and then... 1b) 'Just put the files wherever they belong manually in the Finder'. Do you mean 'identify patch[es] using 'show in finder' in say Unify-1, and then manually copy/paste those into Unify-2 library (being careful to create the same file-structure on both Unify's if that's what my aim is) ...then use the lightning-bolt icon to rebuild the library of whichever Unify happens to be being updated? 

2 re 'setting BOTH systems to look at the external drive' ...assuming I do this, I would (for example) have the external drive connected to the Mac running Unify 1. I know that both Macs see each other via Airplay, but they aren't hard-wired networked any other way. Am I right then that whichever one isn't directly connected to the external drive is going to be problematic ...slow, latency-issues, possible drop-outs? Some of the Unify patches are accessing pretty big sample sets.

Perhaps you are suggesting that I'm using the single external drive on one or the other, but not both at the same time ...(iMac at home, MacBook while away), but being careful to manually keep both of the Unify patch libraries up to date relative to the other via the process you've already described.

Maybe my Roland XP-80 with floppy-disk-drive-brain is unaware of some simpler digital gee-whizzery-truth imbedded in your suggestions ...and 'it will just work'. That would be cool ...but generally not my experience. (I certainly don't mean with Unify... I mean with the implied 'it's digital and just works' ethos of the day).

R.


   
ReplyQuote
(@getdunne)
Illustrious Member Admin
Joined: 5 years ago
Posts: 4487
 

@robert-hunter

I was suggesting that, rather than going to all the trouble of making a .guru file, you just copy .unify files (or entire Patches folders) to the same locations on the second machine. Given that your goal is to have identical sets of patches available on both, you needn't be too careful about it. If you copy patches that are already present, you'll only be overwriting them with identical copies.

The approach of "setting both machines to look at the same external drive" assumes you'd swap the drive to whichever machine you'd be using. If you need to use both simultaneously, this approach won't work--you'd be better off mirroring your patch/resource file structure on the two systems. I definitely do not recommend setting any machine to access patches/samples/etc. on a network drive.

An advantage of the external-drive approach is that Unify's patch database (the file Presets.db in the Libraries folder in the main data folder) would also be on the external drive, so there would never be a need to synchronize two separate copies. As I said, though, this will only work if you only use one machine at a time, and connect the external drive to it before firing up Unify.

 


   
ReplyQuote
Share: