So I am seriously misunderstanding something. I thought when you “saved to gig file” it actually up dated the gig file with this new rack and saved the new gig file. I just spent the last three days building new rack spaces and then updating each one as I went along. When I closed down my laptop today I did not “save changes” as there were some misc things I did that I did not want saved and thought all the new rack spaces were already saved. But when I restarted I had lost all my work.
I am sorry you lost so much work, that is frustrating.
So as worded here, the Gig File would need to first be saved for this feature to work. It only saves the selected rackspace.
BlockquoteUpdate (save) Rackspace to Gig File - saves the selected rackspace to the currently open .gig file; make sure to save a gig first for this feature to work. Note: this option saves only the currently selected rackspace, and changes made to all other rackspaces will not be saved; if you want to save/update all rackspaces, click on File → Save instead.
Frankly, I’ve never used this feature. I just CTRL-S Save the Gig file. I am not sure in what circumstance this feature is a benefit, perhaps if you have a massive gig file or made changes to numerous rackspaces that you didn’t want to keep, just one of the rackspaces?
Please note that if you have the Lyrics/Chords window open and use the CTRL-S keyboard command, the gig file will not save, the Windows system will squak at you instead. I don’t know if this is the same on a Mac.
My habit is to always save the gig and I also iterate the gig file so I have “Gig_01” and Gig_02" and so on…
On the Mac, when you press Cmd-S with the Song Lyrics/Chord window open, the “File” item in the menu bar briefly flashes. No dialogue box appears. The gig is saved properly whether Gig Performer or the Lyrics/Chord window has focus.
In other words, it works correctly on the Mac.
Yes pretty frustrating! And indeed the gig file was saved first, so I’m still pretty confused.
As I said I thought the point of this feature was so that you were able to save just the particular rack, as noted in your quoted section from the manual There are circumstances where I have made changes to a rack that I want to save, but there may have been inadvertent other changes made prior to other other racks that I don’t want saved. If I CTRL-S, I would be saving those other changes I don’t want to save.
The way I read that section of the manual, it should have worked in the way I expected. I should not have had to double save the changes I made. I may be misunderstanding something but that is a pretty consequential feature to be written that ambiguously if so.
Openeing a gig file and then modifying a rackspace, then selecting “Update (save) rackspace to gig file” will indeed update the underlying gig file without you having to save it. The feature was designed to work that way precisely so you can save changes to your current rackspace without having to save the changes you may have made in others.
This feature has been working as designed for a long time.
You cannot ADD new rackspaces this way though. The rackspace must exist and be saved to the gig file first. You can’t add a new rackspace, then select to update it in the gig file because it is NOT in the gig file yet.
2 Likes
My personal approach has become to save/export my rackspaces separately so i always have not only a “backup” but also something like a template for similar rackspaces…
3 Likes
Same here. And this takes a few seconds to do, so why do without? 
Yes, indeed I have been using the feature for many years. But it is this I was not fully undertanding…
I am sure there is no else as intellectually challenged as me, but to possibly save someone else the same devastating fate, may I humbly suggest a few changes… The very title “Update (Save) To Gig File…” can lead one to actually believe they are indeed saving the rackspace, not just only able to update an already existing rackspace. Perhaps take “(Save)” out of that or maybe there is a way for this option to greyed out when it is a new unsaved rackspace.
This should clearly be changed to… updates the selected rackspace to the currently open .gig file. The rack space must have already been created and saved for this feature to work.
I understand the rackspace is indeed being saved with this feature, but the the word saved is ambiguous in this conterx because you can’t save a new rack space, as you say… you can only update… a previously saved rackpace
Great advice that I will heed, thank you.
1 Like
^ this is what I would suggest as well.
2 Likes
I will fully admit to not being in the greatest mood after spending a week redoing a ton of rather tedious work, but I came back here thinking there would be some acknowledgment of the situation… sort of a let’s not let this happen to a single other user. Maybe even for the manual to have been corrected.
I know time is short and there are many important issues and perhaps it is way harder to change the text of the online manual than I would understand. But the fact is I followed the manual exactly and lost a weeks worth of work. I did indeed make sure to save a gig first before “saving” the selected rackspace to the currently open .gig file.
Update (save) Rackspace to Gig File - saves the selected rackspace to the currently open .gig file; make sure to save a gig first for this feature to work.
Many people may fully understand that in practice you can’t actually save a selected rack space to the currently open .gig file. That you can only update an already saved rack space. But there may be a few of us computer illiterates who rely on the manual for our understanding of GP. And the manual in this instance is at the very least ambiguous on what is a very consequential matter.
I hope that regardless of any response to me, this is being taken seriously and being addressed… and no one else experiences the same misunderstanding.
Yes, this part is expanded and will be available when the next GP release arises.
2 Likes