When trying to open Gig Performer it freezes at the Global Rackspace load. 10 times in a row.
When did that start happening or has it alway been happening? Is there a dialog showing what specific plugin is loading? Do you have wifi connected, or do you have wifi turned on but you don’t actually have an internet connection?
When this has happened to me it was because GP could not access the samples on my external drive.
So, if you have an external drive, first thing make sure the cables are properly connected. If so, make next step is trying a different USB cable.
Thanks for the suggestion. Definitely a possibility although the drive was on the desktop.
It is most probably not GP itself which causes the freeze, but rather the gig file that is obviously loaded automatically (GP is set to load the last used gig file).
Hold the shift key while GP starts up and use the temporary startup options dialog to change that behaviour:
Then you can start with a blank canvas and try to rule out which rackspace or plugin causes the freeze… load each rackspace separately and see if it works, or when it stops working.
Again, it’s hard to diagnose without understanding what might have changed.
For example, assuming no hardware issues, one thing I have seen reported more than once is where a loading plugin (which happens on the main thread) blocks everything because it’s trying to connect to the internet (possibly to validate the license) and has not checked first to see that there is an actual internet connection or implemented a timeout if there’s no response.
Possible ways this can happen:
Wifi is turned on but not connected to the net
There’s a static IP address configured for wifi or ethernet but no connection
Internet connection but the remote server for the plugin is down
1 Like
From this suggestion - does it make sense to take each rackspace and give it its own gig file for backup purposes? In the event a large gig file filled with songs has a major issue
I don’t understand that idea… i tend to say, the answer is just “no”.
I also think you discussed this (or a very similar issue) about a year ago:
So to have a “granular” backup, i would
- export all the songs from the setlist to have the whole “collection” of a song and its corresponding rackspaces and variations.
and - export all the rackspaces separately to have them separated from any songs, just if you’d need that.
Both, the song files and the rackspace files can be imported into a loaded gig file - be it by using the menues or drag&drop.
So there are various ways to keep a backup of the separate components one needs in a gig file, but to store them each in another gig file, seems to be not very useful.
1 Like
Thanks - the question came up from someone recently suggesting on the boards that it’s a good idea. That’s why I asked now.
As an aside I find it amusing that the tone continues to be “did u read the manual” it’s something a programmer would say
I have been using GP for over a year and it’s been great - and the forums are helpful - but the idea that everything can be answered in the manual - why even have forums or videos etc.
I’m getting on a plane in a few hours - I’m pretty sure the captain didnt get his experience and all his answers from reading the manual.
There are multiple approaches people have because of its versatility and the dicussions and perspectives are helpful.
I think the question if someone has read the manual is a legitimate question.
The developers have written down the design patterns and how to use them.
Also many terms are explained.
You know using homonyms is the most easiest way for misunderstandings.
Here an example:
In German we say “Knopf” for a Button.
Somtimes in the forum the word KNOB is used, but it should be BUTTON.
Total different widgets.
When you read the manual you have a clear understanding about terms.
And this is only 1 aspect of many which are clearly documented in the manual.
Sure, clever ways of using the possibilities of GP you learn by doing.
But when your are not informed about the design pattern you could get lost.
3 Likes
Yeah, you can only get experience by trying and doing things, when being trained, but the basics to even get a glimpse of how that plane works, what all the instruments are for, what the international rules for flight traffic are… this all is somewhere written in manuals!
And every captain is expected to have read them before he might think of entering a plane or gaining any experience.
I’m pretty sure you wouldn’t even think once (rather than twice) to enter that plane if it was obvious that the captain just read across a summary, created by Chat-GPT and maybe had watched a few YouTube-Videos about flying a plane.
The answer is of course I’ve read the manual - there are best practices that people have learned from experience.
There are many ways to achieve the same outcome and the manual covers them. Best practices from experience are most important.
Volume control - endless topics on getting the right mix - very little help from the manual.
I wonder how many of the users here ever read the manual on word or excel … and when there is a question - the answer isn’t - it’s in the manual.
I’m sure we could debate this all day - my point is for every person that is manual centric - there are hundreds that learn and do better by training and experience. This is a bubble of technically oriented people - and it’s why it’s not a mainstream option for most musicians. But it could be…
And if I was on the plane and I saw the pilot get out the manual while flying - I think that would be the last time I fly that airline …
You have to read the correct manual 
This is an interesting issue — and I’ll give you my two or three cents - my personal views on this.
Many people in this community provide amazing support and do it for free and it is my view that they should be “protected”. What do I mean by that?
First reason
Well, it means they shouldn’t have to have their valuable time wasted by having to address issues for which answers already exist, either in the documentation, in videos, in this community, or indeed in some cases in other communities. That means that the person asking a question should at least have some basic knowledge of how GP works already, which can be achieved by
- exploring the product and clicking on the different menus to see what’s in there
- looking at the (really comprehensive) documentation that has grown significantly
- at least a little experimentation to become comfortable with basic operation and understand the basic concepts and available functionality.
(This is true for any application, or even any appliance you install in your home, or how to work with a new car, etc.)
So, if someone has a question where they’re not sure why a button is not responding to a message (say), someone might suggest opening the global MIDI monitor and showing us the contents.
If the response to that is, “what is the global MIDI monitor”, then they may get an RTFM. As one of our great supporters has commented numerous times, “Please help us to help you.”
Second reason
To some extent, this is more of a pet peeve and it’s not restricted to our community - this is something I run into when I am providing help to others in OTHER communities that are not related to GP. (e.g., OS help, C++ help, various other areas where I might have some expertise)
If someone asks a “how do I…” question and it becomes clear that they have not bothered to do a document search or a google search, or viewed any videos, etc., in at least an attempt to find an answer, the message I “hear” is
“My (the user) time is more important than your (community support person) time so you (community support person) should do my work for me”
I find that “message” somewhat abusive, smells a bit like entitlement, etc.
On the other hand, if it’s clear that the user at least tried to find the answer by him/herself before reaching out, then users here will often spend a significant amount of time to help them. The hope then is that the user being helped will later become somebody willing to answer questions as they become more comfortable themselves. That is, to me, what a community is all about.
5 Likes
David - very fair points and a great perspective.
Maybe the tone of “you asked this a year ago” raised my eyebrow. (As if things don’t change and others have found better practices along the way)
Personally my questions have been less and less for the reasons you have mentioned (having experience , reading the manual, experimenting) AS WELL as the attitudes given.
I think the entitled part is often projected on to a lot of users who simply are looking for a better understanding of real time use. EVERYONEs time is valuable - yours, mine theirs. What may be clear to the experts (and those who provide answers are just that) may not click for the average user. Sometimes a link to a few videos and discusssions that hone in on the specific topic is all it would take.
And yes - RTFM - nothing wrong with that perspective at all - but there are thousands of users that stay off the forums because they dont appreciate the underlying attitude given - its no ones obligation to answer question that they feel are redundant or could have been found elsewhere. Mine included. I suppose i would be annoyed if a question came in that has been answered before or could be found with a little bit of effort. Point taken.
Getting back to the problem at hand - based on DHJs suggestion - I updated and synced up all of Arturias VSTs and that did the trick. The crash was happening based on a few VSTs from Arturia as read in the first few lines of the crash report. What can i tell you - it’s very disconcerting to open up GP without doing anything for weeks to all of a sudden having your main gig file crash. If it was a gig I would have been in full panic mode. It’s why I was exploring the idea of smaller and perhaps separate gig files. But it sounds like it comes down to making sure the gig is ready days in advance as a good practice.
1 Like
Agreed but there is no magic. SOMETHING had to have changed.