That category is typically not available until the forum system decides that somebody has sufficiently participated in the community. We set it up this way because we had too many people suggesting features that were already implemented but users hadn’t spent enough time to discover existing mechanisms.
We have manually upped your trust level so you should be able to see that category now.
That said, your suggestion is both interesting and vaguely of concern, requiring some serious thinking. Reverting an entire rackspace to a previous version essentially requires recreating the entire rackspace and there are several technical reasons as well as usability reasons why doing that on the fly is potentially very dangerous.
Thanks for the information and thanks for you support, dhj 
I see what you mean. To make the things properly, it would simply need to take account of the last midi note OFF on the previous rackspace before reverting to avoid any sound glitch (especially if midi patch persist function is used). And putting perhaps an additionnal delay offset of few seconds before reverting (offset that could be set manually), very useful in case there’s some reverb or delay in the previous rackspace and you wouldn’t like your reverb or delay to be faded out too quickly. But at the price of impossibility of getting back to the previous rackspace instantaneously. But it would not matter. 99,99% of the time, we are changing rackspace to stay at least a certain amount of time, certainly more than 3 seconds !
Apart from that, I don’t see any other technical problem.
Is the problem reverting back to a particular rackspace during a set?
[Because if you just don’t save the gig file, when you reopen it, all rackspaces will be in their original (saved) version. But, I guess you know this….]
Please, read at least carefully the title of the topic before answering : the key word is “automatic”! Everything is explained from A to Z in my first post! No, it’s not possible to reopen an entire gig file, I’ll repeat it again : I have 26 instances running at the same time with hundreds of rackspaces, this would interrupt both my playing and potentially break and crash OSC communication with my master instance. And I won’t have a computer in my keyboard rig to do so, and no time to make it when playing. Sorry, but inapropriate!
I’ve just posted my suggestion in the Feature Requests section, explaining it as clearly as I could. I tried to broaden the scope beyond my own specific use case, because I’m convinced this feature would benefit a lot of improvising keyboardists and real-time sound designers:
https://community.gigperformer.com/t/automatic-revert-rackspace-to-last-saved-version-function/26599
That’s an extremely unusual/rare outlier example - I’m impressed that all works for you.
Question: in terms of reverting (automatic or otherwise) — what exactly will have changed? Are you just talking about the state of the actual plugins in a rackspace (and widgets in a rackspace) or might you have actually changed/removed/inserted plugins or changed the wiring connections?
(Emphasis mine)
Nothing happens to rackspaces that aren’t active in GP. Even the manual ‘Revert rackspace to last saved version’ only applies to the active rackspace. Wanting a rackspace changed and loaded in the background while you’re playing in a different rackspace is not desirable at all. That’s the kind of thing that invites all sorts of audio glitches and potential crashes.
Now, even if you wanted an automatic ‘Revert rackspace to last saved version’ to occur as you switched to a rackspace, that would mean all sound would cut out while the rackspace was loading. I’m not sure how that would be desirable either. There would be no Patch Persist or Output fading of effects. This is the behavior of the current manual ‘Revert rackspace to last saved version’ option.
I tried an experiment with 3 different plugins in a rackspace and using the current ‘Revert rackspace to last saved version’ option. Depending on which plugins I used(I interchanged a few), it took anywhere from 1 to 5 seconds of loading time before any sound was produced after loading. I don’t see how it would be desirable for live performance. I wouldn’t want that kind of loading activity happening in the background while I was playing in a different rackspace either. So, either way, I fail to see how having an automatic ‘Revert rackspace to last saved version’ option would be beneficial to live performance.
I get the issue you’re facing: You’ve made 26 instances, 100’s of rackspaces, and 15,000 lines of code and now you’re facing an impasse and want a feature to help resolve it. The point being made by myself and others is, what you want already exists within GP - however, it requires(and always required) a different architecture than what you’ve made. Getting stuck within your own designs and then saying its ‘basic and primordial’ for GP to bail you out with an option — that’s not really a recipe for success.
I know I’ve had to deconstruct and reconstruct my own setup many times over the years I’ve been using GP. My own learning curve coupled with endless ambition = lots of time spent doing and re-doing things. It’s frustrating and time consuming. One thing I have learned now is, before I start jumping headlong into new paradigms, I ask myself, ‘Is what I want to do with the way(s) I want to do it possible with what I have and know?’. If the answer is no to any of that, then research first, get new tools, adjust what I want to do or how I want to do it etc. until the answer is yes. Then I am ok with investing the time and work to fully move in a direction.
Changing rackspace means another plugin synth loaded, or another patch from the same synth, but perhaps with other plugin effects. There’s no rule.
I think @dhj wanted to ask if you only tweak existing plugins and you want to restore the state of this plugins or if you exchange plugins.
I’m not talking about “revert rackspace to last saved version” function adapted. It would be a new function.
If you’re using the function “predictive loading”, there will be some predictive loading in the background and it works without any interruption, so I don’t see why loading back only parameters could make problems. A simpler and lighter way would be to simply recall all PARAMETERS changed to their original state, rather than reloading the whole rackspace. That depends of the method chosed to operate.
I don’t totally agree with what you said. I have made some big mistakes on GP before, and had to reconstruct several times a lot of things, and I accepted it. It’s a part of the learning curve, indeed.
But at this point, it’s different. I have a feeling that something new in the software could offer more to people - and obviously solve my problem easily.
Just read the post I made on “feature requests”, I’m shortly talking about the set list / song workaround. In such case, it’s very unpractical to transform rackspaces into individual songs. Because if I have let’s say 1000 rackspaces, and I just want to modify some of them, it means I will have to modify each time the song too. And my script is sending or or receiving informations from remote instances to/from rackspaces, so everything is for the moment not compatible. I may change the scripts, I can do it, but I have the feeling that’s not the right way to make the things working properly. I’m 50 years old, 35 years in sound engineering, and my experience tells me it’s always better to try as possible to treat a problem where it is, rather than fixing it with workarounds after. It’s just like saying “the microphone position is not ideal, but never mind, we will fix it at the mix stage”. The result will be only a fix, but certainly not ideal sonically, you see.
I was aware from the beggining that I would knock with this problem, but after deeply studying every software possible, I came to the conclusion that GP was the best and only option, even if not exactly ideal. I thought that I would have to cope with the “not recalled plugins” anyway, and accept the limitation temporarily, but I always thought this software could be enhanced in the future, and that it would help many keyboardists to feel at home by having a possibility of recalling previous rackspaces in the background, exactly like on any synth memory, on which every setting change is volatile until you’ve decided to save the configuration into your patch memory.
To be honnest, when I began to study GP architecture at the very beginning, I was very suprised this function was not already implemented, as it always appeared to me as a very basic and standard function, that you can find on any traditionnal synth with patch memories on the market, from the eighties with the memoryMoog in US and Juno 106 in Japan, to nowadays ! This operating mode is validly working for about 50 years, and is appreciated by billions of synth users, so why not implementing it in GP ?
Indeed, it means some adaptation, because it must ensure a kind of sound continuity when chosing new rackspace, but it may be possible technically.
At worst, if it’s not possible to get sound continuity, I prefer to get the previous rackspace’s sound being brutally interrupted, than having no other option.
But as GP works, when changing rackspace, there’s always this very clever automatic crossfade, that made me though it would be possible to adapt the thing, by using a delay. When previous rackspace’s sound is totally faded, then it’s possible to reload all parameters or reload entire rackspace in the background. It’s certainly technically feasible.
OK, I see what you mean. The answer is : No, I won’t exchange architecture in the rackspace in real time. It’s only about tweaking parameters into already loaded plugins in a given rackspace, and yes, only restoring the state of those plugins. The only need is to recall buttons, sliders, potentiometers positions to their initial state. Knowing on some synths there are hundreds.
This would mean restore the state of plugins.
You know that some (poor coded) plugins do not like that?
So the risk you face a crash would be high.
I use only professional plugins. The best of both worlds would be to have choice between simply reseting the states of plugins (at the price of some potential problems if using cheap plugins), or reloading the whole rackspace, at the price of - perhaps - some crackling but only if the computer processor is too weak. Nowadays we have extremely powerful processors at relatively low cost, so those slowing problems are progressively going to be something of the past, thanks to those 16 or 32 cores. And when using high-end plugins for keyboardists (virtual instruments, etc), you’ve always got to be coherent and have a good PC with lots of ram and efficient processor. Mine is Ryzen 9 7850X with 96 Gb of memory, and SSD for system (where plugins are situated). 26 instances running at the same time with 64 samples of latency, and perhaps could I even get lower latency if I changed my soundcard (old but good Emu 1820M + VB Audio Matrix Coconut for mixing all virtual ASIO clients). By the way, I highly recommend Matrix Coconut for multiples instances when the soundcard is still not multiclient. This software can sync all instances ouputs to the master clock of the soundboard (kernel driver), so no additionnal latency (at the opposite of GP relayer) and it proved (at least for me) to be stable as rock. By the way I contacted its creator, Vincent Burel, to enhance the number of virtual clients with less outputs (it will spare a lot of CPU cycles), and he agreed to add a special driver section with 32 stereo virtual ASIO clients to 16 stereo outputs matrix for the next version of the plugin. I’ll post something about it here when the new driver will be implemented. Vincent already made a great job with Matrix Coconut, and this software deserves to be better known (for people who don’t have multiclient ASIO drivers). Quite CPU consuming if allowing all the virtual drivers, but stable. And the new version will be far more adequate for Gig Performer. But that’s another story…