Managing GP with Dropbox
Introduction
There is no mystery to the backing up of files, it can be achieved manually, via some tool, or simple command lines. The one and only rule is “Back it up”. If you decide not to, one day, the few seconds saved will certainly lead to disaster.
When gigging with hardware I always had two setups that I could share the patches across, so this involved buying much more kit than needed. For my Classic Rock covers I limited myself to just one board, So I had a K2500X (88 note) in my home studio and a K2500 (76 note) for my live rig. For the Prog Covers band, this was extended with a Korg Triton (76 note) for the studio and a Korg Triton (61 note) for my live rig. So patches could be moved from one rig to the other. The transfer was always painful, but I had a way of working. Everything was stored on a SCSI ZIP drive (even the Korg files). From that drive I could create floppy discs from either Kurzweil machine, for use in either the Korg or Kurzweil. A number of ZIP discs would be rotated as the backup mechanism. I called on the backups many times over the years.
When moving to a computer based system I started by taking even more kit to a gig, as I was unconvinced that the computers would be reliable enough to see me through a gig. So I ran a hybrid with a view to fall back to the hardware should the need arise. Over the years confidence grew and the computer only setup is as reliable as, if not more, as my hardware setup ever was. Now in one of the UK’s top Marillion tribute bands, just two controllers and a Macbook Pro see me through a gig. But the need to backup and transfer files became more important as I can no longer wing things with a few basic sounds.
So why did Dropbox become my way of working? Coming from a programming background, I have an ingrained need to keep files associated with a project in some form of order, automatically back up my work, transfer to a new platform and importantly revert changes should things go wrong. Essentially these requirements can be treated as separate elements. I will describe the workings of each part as I use it, this is not the only way and there are many other policies that would work, but I find this is simple and works for me.
I cannot say this loud enough at this point USE RIG MANAGER!! If you are not using Rig Manager, stop what you are doing and learn how to use it and incorporate it into your workflow. Rig Manager was my single biggest reason for moving from Mainstage to Gig Performer. The second reason was cross platform support. Rig Manager is important to make transferring gig files to other machines as easy as possible.
As I work across Mac and Windows I will always use VST3 (or VST) plugins. If you are just Mac then the AU format can be used. I only select plugins that support both platforms. You must also keep all the plugins at the same version across the machines (this was discovered the hard way).
Backup and Transfer via Dropbox
Other cloud storage solutions are available, and should work in a similar way. I have tested using Google Drive and this works just as well as Dropbox for backup and transfer.
The main requirement was to simplify the transfer of files, from the studio machine used to build the gig file, to the live machine used to perform. There is an additional requirement here in that any tweaks made and saved in rehearsal or at a gig may want to be brought back to the studio setup without losing the original. One of the great advantages of Gig Performer is that everything you need is contained in a single gig file, this makes the transfer very easy.
Dropbox App
Install the Dropbox app on all the machines you intend to use with Gig Performer, many of you may already have Dropbox installed. At this point you should have an idea of how you intend to connect your machines. For me it was a Mac Pro G5 Studio machine (Master), a Macbook Pro i7 Live machine (Slave), a Macbook Pro i5 Backup machine (Slave) and a Windows 10 i5 Support machine (Master).
With the application installed, log into your cloud storage account on each machine. A local folder will be created by Dropbox (usually called dropbox). Within this folder, files can be automatically synchronised to the cloud storage and the connected machines. Do not synchronise the whole of dropbox, only select folders that are to be synchronised on the GP machines. My studio machine has many more folders backed up than my live machines, as each music project gets its own folder so that backups are automatic.
Within the Dropbox folder create the root folder for your Gig Performer sharing [dropbox folder]/gp on just one of the machines using Explorer (Win) or Files (Mac) applications. Make sure that all the connected machines automatically get this new folder added. Next create a folder for the gig files, something along the lines of [dropbox folder]/gp/gigfiles. If you are using only MACs or only Windows machines in your setup, it would be possible to add a plugin directory into Dropbox [dropbox folder]/vst3 and include this directory in the plugin scan paths within GP. These structures will automatically be created on all the machines when connected to the network. If you want to synchronise the distribution of the plugins and use both MAC and Windows machines, create a [dropbox folder]/win/vst3 folder and a [dropbox folder]/mac/vst3, this should be scanned accordingly and ideally shared accordingly.
Synchronising Your First Gig File
This example has been selected as it does not rely on any plugins other than those delivered with Gig Performer. The aim is to show how the file synchronisation works across machines, and to show that the changes to a file, transfers to all machines. Also notice that the gig file is created on a Windows machine and transferred to a Mac.
To follow this example, open Gig Performer on the master machine. From the top menu select File / New / New gig from template, then select GP Cool Stuff / System Actions Plugin Example then click the New gig from selection button in the lower right.
Once loaded select File / SaveAs… The file should be saved to the [dropbox folder]/gp/gigfile folder, using a suitable name eg. test-master.gig.
Windows 10 test-master.gig
On a network connected machine open Gig performer and from the menu select File / Open… and select the test-master.gig file from the [dropbox folder]/gp/gigfile folder. This will load a synchronised copy of the test-master.gig gig file from the local drive.
Macbook Pro i5 test-master.gig
Now make a change on the master machine, here the background colour has been changed to red. On the menu click the File / Save option this will overwrite the test-master.gig file.
Window 10 Red Rackspace
On the synchronised slave machine select File / Open Recent and reload the same file. The changes made on the master machine will now be available on the slave machine.
Macbook Pro i5 Red Rackspace
The reverse is also true, that changes saved on the slave machine will be synchronised with the master machine. All changes are now synchronised across machines and also available via a web interface as the files are also stored in the cloud.
Dropbox Version History
A simple archiving scheme is already implemented in Dropbox, allowing previous versions of any synchronised file to be recovered. The changed files can be viewed in chronological order. The changes made in the short example above can be viewed in the Dropbox archive.
The archive is accessed from From the Dropbox Web interface, or the Dropbox application, the change archive is shown under Version history in the menu. Comments can also be added to a file from the web interface.
Filelist from Dropbox Web Interface
Or it can be accessed by right clicking on the file in Windows Explorer and selecting the Version history option. The same option is available on the Mac from the Finder application by using the ctrl + click on the filename.
This will open the same file archive list in a web page that opens from the Dropbox web archive interface (see below).
Files in this list can be recovered by clicking the Restore button. However this will only work for up to 30 days on the basic version of Dropbox, this can be extended if required, with “payfor” options.
Archive File List from Dropbox Web Interface
For correcting mistakes and recovering recent versions or recovering overwritten files the 30 day archive works well and will provide a robust backup process. Versions may also be downloaded while leaving the current head version in place.
The backup/synchronisation method can be extended to include Gig Performer scripts, songs, rackspaces etc. these can all be kept in separate folders such as [dropbox folder]/gp/rackspace or [dropbox folder]/gp/scripts etc… by simply exporting the various elements to these synchronised folders they will be copied to the connected machines. These files are not normally saved or loaded unless explicitly actioned within GP.
Rig Manager
The importance of the Rig Manager in this process cannot be understated.
While backup/sharing files across computers is mainly intended to allow a computer replacement should a problem occur, for me there is the requirement that the keyboards on my Live rig are different to the keyboards in the studio. So the gig file that is synchronised must be capable of working with different keyboards without change. This is the reason for Device Aliases. By the use of aliases each machine can use a separate rigsetup file, these may also be backed/shared up across machines if saved in [dropbox folder]/gp/rigs, the file from the master can be used when creating new rigsetup files with new keyboards and then saved with all keyboard variants.
Note the use of (Keybed 88) alias in the MIDI In block.
Setlist Gig Files
For those with very large gig files, that like to export a setlist as a specific gig file for live work, this can be done on any of the connected machines by saving the setlist as a gigfile using the Create Gig From Setlist… option. The new gigfile should be saved to the synchronised [dropbox folder]/gp/gigfile folder and the resulting gigfile will be copied to all connected machines.
Create a gigfile from a setlist
Tips for an easier life!
- Use Rig Manager
- Use Aliases in Rig Manager
- Use only aliases in the GP wiring view
- Do not synchronise the whole of Dropdox to every machine, only the gig performer root folder
- Be very careful with absolute file paths across machines always use relative paths and symlinks, some media files may need to be copied manually, especially across OS’s.
- If synchronising VST’s make sure you are not scanning MAC VST’s on your windows machines
- Pause dropbox synchronisation and WiFi when playing live ( Windows machine precautions)
- Synchronise all GP folders across machines
- Make copies of any old versions of gig files that you wish to keep beyond 30 days under a new name, these may be saved in dropbox without any issue and can be called up from any machine
- Do not allow automatic updates to any machine, updates should be planned and considered, as things like version number changes in VST’s can catch you out.
Author Notes:
Having used this mechanism for well over a year now, I have zero issues with this process. Initially I would run up the gig file on each machine and check every variation of every patch. Once all the VST versions became aligned across the machines. I had zero problems.
So, if I have not changed any VSTs or updated any applications on any of the connected machines, I no longer check that Gig Performer functions as expected, other than the file has successfully transferred from where I prepared the setlists. This makes the process super simple and my laptops are ready to go to the gig within minutes.
I personally do not change the default file locations from Gig Performer to a shared folder, preferring the saving of a file to be explicitly placed in a synchronised folder. I use the Load Recent option when starting a GP session and never use the load last gig option, preferring to know what has been loaded rather than assuming.