Option to force a 'commit' of rackspace changes

Unless I’m missing something, Gig Performer has a behavior by which if you have a rackspace open in a gig file, and you make any change, and then move to the next rackspace, those changes are retained in the racksapce you moved away from. You then save the gig file and there’s no real way, short of hoping you exported the rackspace previously, to ‘revert’ to the previous version. You may have made a change by mistake, and there are other unintended consequences.

With my previous host, the default behavior in it’s ‘rackspace’ (called a scene) was that if you moved from one scene to another without intentionally committing any changes, they were lost. There were benefits and drawbacks to this behavior, but I would like it if there was a global setting in GP that unless you intentionally committed changes to a rackspace before performing an action that would move you to another rackspace, you would simply ‘lose’ those changes. I think this might also cut down on GP file ‘bloat’ because I suspect in some cases, people are creating unintentional changes and then subsequently committing them to disk when they save the gig file.


I think such a feature would be interrupting any “flow” while performing live, although i agree that there should be an easy way to “lock” a rackspace from permanent changes.
So thinking about this, i could imagine that “locking” a rackspace for unintended saving of parameter changes, would ideally allow changes but they would be temporary lasting as long as the gigfile is open, and when the file ist to be closed, there could be a message that changes on locked rackspaces have been made, so one could decide what to do then…
-save everything except from the locked rackspaces
-override the lock and save everything
-quit without saving anything
What do you think about this?


I don’t think I worded my request correctly. I would not expect any interruption in ‘flow’. In other words, I don’t expect a ‘save changes’ dialog to present when navigating away from a rackspace when you have made changes you haven’t committed. That WOULD be rather intrusive. You navigate away without committing your changes? Too bad, so sad.

I do find your suggestion regarding ‘locking’ changes to a rackspace as a workable alternative, but I still prefer the request I made. Either one would help solve the ‘problem’.


1 Like

Ah, ok… then i missunderstood. Well, then there are two suggestions to chose… let’s wait, what the code-masters say about that. :upside_down_face:

I think that while in Rackspace(front) view, the default mode should be ‘locked’. That is to say, changes to widget values can be made, dials moved, switched turned on and off, but those changes don’t commit as permanent when navigating away from the rackspace/variation and back again, and it doesn’t involve widget creation or physical movement on the screen.
Another mode would be created for Rackspace(front) view, called Layout mode, where the actual layout, widget creation, movement etc took place.

So there would be:

  • Default Rackspace view - Changes to widget values can be made, but they don’t commit when moving away from the rackspace/variation, and you can’t move the widgets layout around or create/delete them.

  • Edit Mode - Changes to widget values only, with any changes saving to the rackspace/variation automatically.

  • Layout Mode - Widgets are created/deleted and moved around physically in the rackspace/variation.


So what happens when you’re in a show and jumping from rackspace to rackspace during a song?

The default would be the example you quoted. You could adjust the values of the widgets (adjusting volume, toggling mutes on/off, adjusting drawbars etc), but any changes you made wouldn’t be saved as you jumped from rackspace to rackspace. In default mode, when you returned to a rackspace, the values that you had originally set would be returned.

You currently have a per-widget setting where the widget can be returned to a specific value on rackspace activation (In the form of the ‘Also on rackspace activation’ checkbox). My thought is that the rackspaces are presets, hence the default should be that they return to their original values upon loading. Exceptions should occur on a widget to widget basis, in the form a ‘Return last used value’ checkbox, or something of the like.

Differentiating between Edit and Layout mode would be good so that widgets aren’t accidentally moved when adjusting values, which happens to me relatively frequently. Also, as @schamass and @xpansion have mentioned, some form of a ‘Commit’ button in Edit and Layout modes would make it so if we accidentily changed values of widgets, or messed up the layout, we could back out without those changes being saved, needing to actually press a Commit button to save the changes. I’ve had this problem relatively frequently also, where I use the scroll wheel to scroll through the panels, and if my cursor is somewhere over a dial widget, the dial changes value instead, and then I have to remember what the actual value was and reset it.

But that’s exactly what I (personally) don’t want. When I’m playing a song and jumping from one rackspace to another, when I return to a rackspace, I want things to be the way I left them unless I explicitly specify a value to which widgets should reset when the rackspace is reactivated. I

But that’s already there – you go into EDIT mode when you want to layout widgets (and you have to hold the SHIFT key down if you want to tweak them while in edit mode so you can’t change them by accident) -what am I missing?

That is what “Revert” does.

(NB, not objecting to your suggestions, just pushing on them and trying to understand how best reconcile differing needs here)

Help me to understand here. You have R.1 and R.2 that you want to bounce between in Song 1. During Song 1, you make some on-the-fly adjustments to R.1(now will call it R.1-mod), go to R.2, and want to come back to R.1-mod during Song 1? Ok. What happens when you’re also using R.1 in song 15? If you ‘want things to be the way I left them’, then it wont be R.1 you’re returning to in Song 15, but R.1-mod. That doesn’t sound like what you want and/or do, so help me understand.

The SHIFT key changes nothing with this. What am I missing?

I was having this very same discussion on the Positive Bias forum. They also default to having any changes you make to scenes automatically save, and I guess it’s a matter of perspective here, but I think if you look at the number of things that you modify and want to keep vs. things that you want to stay the same in any given rackspace, same outweighs change by quite a bit. That’s why it’s more logical for me in every instance to have the default to be not to save. Hence, a save/commit option vs. a revert option–but like I said, I guess it’s a matter of perspective as to which default is preferred,

You’re missing the fact that I misspoke :slight_smile: You actually use the scroll wheel to adust widget values when in edit mode

I would just like to chime in here and point out that in the setlist view, making modifications to a rackspace, then going to another song that uses the same rackapce WILL RESET that rackspace to the variation you originally set for that song.

In other words - the behaviour is exactly as you want and the song will sound exactly as you originally set it up. You can even override the rackspace changes for a specific song par with the override within a song part.

The exception to this, of course, is the ability to “Ignore Variations” for a specific widget in which case the changes will indeed persist between songs, but that’s an exception.

The rule in the setlist view is to NOT save and RESET the rackspace to it’s original variation used in that song part.

I understand now. As I’ve discussed in previous forum posts, I can’t use setlist view for the way I use GP, so that’s why I didn’t know.

Being in Rackspsce view all the time presents its own flow, and that may explain some of the perspective differences for feature requests.