A couple of days ago I rebuilt my Surface Pro as it not running correctly. I reinstalled Gig Performer plus all the other VSTs I use. When loading up my saved GP files, I find many of the links such as volume commands, midi start commands, messages between modules etc, are not working. For instance, the midi input block would no longer start the drum vst until I replaced it. Then I had to re-set the latch function and it finally responded to midi input. I have over 200 rack spaces and many need fixing after the rebuild. Is there a quick way to restore all the modules so they work again? Did the faults occur because I perhaps installed some VSTs into different folders? More importantly, how can I prevent this happening down the track if I have to rebuild Windows again in the future?
While it’s certainly the case that you would need to rescan your plugins if VSTs are in a different location, it’s not enough to just reinstall GP and expect it to work. There are numerous settings and configuration information that GP stores in your application support folder. I’m betting you didn’t back up and restore those settings.
Numerous settings and configuration information? Could you please elaborate on that? Or is it documented somewhere? I’m just thinking ahead to the (inevitable) future disk failure. Also, I have a Win 10 machine that I’ll be reverting back to Win 7 (someday), and it would be good to know all those technical details BEFORE the reinstall. Thanks.
Back up the settings? Can you please elaborate on that David for future reference.
Ok, I’ve found a backup image I made before the rebuild. Which GP files do I need to save so that I can copy them into the new install?
Gig Performer is no different than pretty much any other modern application installed on Windows. It stores configuration and settings in a folder Gig Performer under your Applications Data folder (the location of which depends on how you’ve installed Windows but is typically C:\Users\YourUserid\Application Data\Gig Performer)
The information stored there includes the list of validated (and failed) plugins global MIDI configuration, rig manager settings and so forth.
If you’re migrating to another machine, you need to be backing up / restoring that entire Applications Data folder, otherwise most of your other applications won’t work either. This is not specific to Gig Performer.
Everything else (locations of your plugins, MIDI device names, drivers etc) need to be identical on the new machine.
By the way, there is a knowledgebase article on this topic on our website. See
https://www.gigperformer.com/moving-gig-performer-to-another-computer
I had to restore to a new Windows machine after I lost my laptop to a lightning strike surge. I did not have any issues with Gig Performer after restoring my backup. I was actually surprised that I did not encounter issues after settig up the new machine.
If you did an actual restore then your settings would have been recovered as expected.
Under Win 10 there is no “Application Data” folder, only “AppData”. If these are the same, then there is no Gig Performer folder there, only Local, LocalLow and Roaming. However, I clicked on Roaming and found a Gig Performer folder in there with a folder called Gig Performer settings. This is a different path to what is stated in the article. Anyway, I copied this from the mounted image into the same location on my normal c drive. It didn’t fix the problem. Have I found the correct setting file?
Hence the reason I said typically rather than always. However, if you have already run Gig Performer on the new machine, it will have created new setting files in the appropriate folder on the new machine. I suggest you do a search to find that folder on your new system and then replace the contents of that folder with the old settings from your old machine, again presuming that you have found the correct settings on your old machine.
Just as an experiment, I tried reinstalling the drive image I had two days ago and it reinstalled fine. And all my lost settings now work again. I looked for the settings file in appdata as explained above and checked its file size. It is 39kb which is exactly the same as the file size in the new install. It is just a single file. Is that correct? Are there then other files elsewhere in Win 10? When I did a search I found 8 different locations for Gig Performer. Seems to me that there should be more in that Gig Performer folder. I’m quite confused and now wonder if there is more to this than the article states. Was the article written with Win 10 in mind, or have things now changed? This is important as others are could be wanting to rebuild their machines in the future. I think GP could do with an app called “Configuration Save” that would allow users to use it to save the settings file to a data stick or similar thus avoiding this problem I have had. This would allow users to then copy the file more easily to a new install. Now that I have all my settings working again, I’m a bit loathe to try another rebuild in case that settings file won’t work. I’m going to hang off until I’m more sure of how to do this.
GP already has the ability to export rigs (see image below) but you have to remember to use it! You’d still have to relearn your global MIDI items but that’s not a big deal. We’ll probably add the other settings to this export at some point
This issue of backup/restore is going to apply to pretty much every program on the computer that can be configured. It’s even worse if there’s stuff in the registry. The KB article we wrote is quite old but as it notes, users should routinely backup their entire machine in which case restoring Gig Performer and its settings would have been a non-issue. If someone wants to rebuild their machine, then it is their responsibility to back things up properly so that data can be restored. There are so many combinations of things that can go wrong when one tries to do this manually that no manufacturer can really provide explicit support for this.
My last VST hosting program carried out the settings saving automatically. If I wanted to rebuild the computer at any stage I could. Then it was simply a matter of installing the hosting program and when the song file was loaded, there was nothing else to do and the program just worked.
In Gig Performer, we explicitly chose to separate the hardware configuration from the gigfile. That allows you to give your gigfile to someone else (or to get a gigfile from someone else) and make it easily work with a completely different hardware configuration and that will work cross-platform as well.
If you export your rig as well (which I mentioned earlier) then you can import it on another machine if you want to use the same configuration.
I like that concept very much.
This days I installed a totally new machine and with the use of rig manager it was very easy to get all running.
This is somewhat strange and the only way this should happen is if the MIDI device you used initially is not longer available or changed its name. If you used an OMNI block - this should not have happened at all (please confirm).
After reinstalling windows and all its drivers it is quite possible that even if you connected the same MIDI device to it - the driver reports a device with slightly different name. There is absolutely nothing that GP or any other application can do automatically in this case. It needs your input to identify the device.
The Rig Manager is your best friend. We created it to allow aliasing of your midi device names so that GP itself does not care what physical device you connect to your computer.
Finally … if your driver changed the name of your MIDI device - all you had to do is select “Change MIDI Input Device” after you right click on your MIDI In block, then select the device you want. That option would have asked you if you want to change the midi device in the entire gig and if you answer yes - it would have updated everything in one go.
btw… the title of this post is somewhat confusing… When someone says “broken links…” these days - it usually means broken web links on a web page 
Please consider changing the title to something like “Windows machine rebuild - missing MIDI device”
Hi djogon,
Thank you for your input. I couldn’t use Omni blocks all the time as they were causing a certain VST to transpose. Regarding changing the device in the entire gig - I did initially try that but the following rack spaces did not seem to respond. I haven’t mentioned this, but all the midi commands are sent wirelessly from my iPad using RTPmidi. These are the ones that GP is no longer responding to. With a large number of rack spaces (over 200) it’s just plain tiresome to go back and fix each one. It takes a long time. Regarding the rig manager - are you saying that when I have things fixed and running properly, then I can import a RM file to a new build and this problem I have won’t happen again? Where can I read up on how to use the rig manager?
In the user manual (downloadable from https://www.gigperformer.com/support.htm)
Check the RTPmidi device name that Gig Performer is seeing. It’s possible that after you rebuilt, the device name is different than it was before. If so, you can quickly change all your RTP MidiIn blocks in all rackspaces in one go. See the image below - just right-click on one of the blocks, and select a new MIDI Input Device. You will then be prompted to change all similar devices in every rackspace. Click Yes to that and you’re done.
