Recall On Activate not always working

It seems that you like the option proposed in GP for managing the widgets values, but you are not comfortable with the way do it.

So, what would you propose to make things easier ?

@David-san… did you read number 2 above? You described very clearly how Recall On Load is meant to work. In your scenario you have to 1: go to rack with cut off filter widget. 2: Go into edit mode. 3: Select widget. 4: Check “Recall On Load.” 5: Move widget to the correct value. 6: Hit Save button next to Recall On Load. 7: Save the gig file.

Do you not agree that you actually only need to do steps 1, 5 and 7? There is no benefit to having Recall On Load in that scenario, unless you just like to do extra work for the same exact result.

What might make more sense in your scenario is if Recall On Load was used on the Chorus for your Rhodes (in your example). When you then exit GP without saving, you of course preserve all your original settings, including for the cut-off filter… but the new setting for your Rhodes will be “recalled on load.”

@David-san I sure hope I didn’t write anything that could be taken the wrong way. I sure appreciate your help and support!

I am just totally confused. I absolutely understand and appreciate giving users different ways of working. But as far as I can tell, that really isn’t valid for Recall On Load (and maybe Ignore Variations, hahaha). If using Recall On Load requires you to move the widget to the proper value anyway, then Recall On Load and the other steps required to use it are completely superfluous.

My talk with you made me think there could be another approach which would better fit the Fitts’s law, but I still have to think about it… The action sequence you described is even more complicated, because when you edit the widget properties, you cannot change its value without going out of the edit mode.:confused:
Wheter you need “Recall on load”, “Also recall on activate” or nothing, really depends on how you want to work. In my scenario, each time I active my synth rackspage I want the cut-off frequency to be reseted. So the right option has to be “Also recall on activate”. If I only want the cut-off frequency to be reseted when I switch to the rackspace for the first time after loading, I have two options “Recall on load” or nothing. The difference is that with “Recall on load” the recall value is protected against me. Even If I change the cut-off filter value and save it inadvertently, it will be recalled properly. It is up to you to decide if you want to “protect” your recall values or not. If not, by default, without doing or choosing anything, your recall value is the last saved value (and unfortunately depending on when you save your gig file, not necessarily the “correct value” of your step 5). I know how I work and I’m not sure I’m rigorous enough to be able to work without the “Recall on load” option. But I agree, things could be easier…

Don’t worry, I like to be confronted with the opinions of others. And nothing is inappropriate in the confrontation of ideas. I am talking with you more then I help you :wink:

If I remember well your concern at the beginning of the topic, you had values not beeing recalled properly. Now it seems that you are convinced not to use the Recall option anymore ?

So that is now a slightly different scenario.

In your first example (as well as @pianopaul), you would be going back to a widget that was moved, and you don’t want that value saved along with another widget whose new value you do want to be saved . In that case Recall On Load is superfluous… just extra needless steps, that also require you to do the obvious thing of just setting the widget value to what you do want saved.

Well, yes you can by moving the physical controller it is assigned to. But more importantly, as I mentioned. You don’t have to go in to edit mode at all anyway (just steps 1, 5, 7)… go to widget, move to proper value, save the gig file with your new setting for chorus on your Rhodes. One way or another for this scenario you have to reset that cut-off filter to its original value… whether using Recall On Load or not.

Now this new scenario seems to be that AHEAD OF TIME you have decided that certain widgets you will never want to save with a new value whenever you save a gig file and so you use Recall On Load on them. So there are other widgets that you are ok with possibly inadvertently changing??? Not sure that makes any sense. Wouldn’t you basically be enabling this for all your widgets? Is that how you use it? And then you uncheck it for a widget (chorus) you want to save with a new setting?

You noticed ? I wanted my example to be more consistent. But I wanted to illustrate is that there is a need for every option regarding the way you work.
If you go to the widget, modify the value and save the gig file, your value will be recalled properly without having enabled “Recall on load”, I agree. BUT, if you are playing with the synth, go to the widget, modify the value and don’t save anything because you were only playing, then things can happen… If later in my rehearsal I change and save anything else I will save the current state of all previously changed Widget. If you don’t accept this you can use “Recall on load”.

Definitely yes, that’s my way of working. And even regarding the chorus widget of my scenario I use “Recall on load”. So I think it doesn’t make sense for me to use both “Recal on load” AND nothing at the same time. I personnaly make use of “Recal on load” everywhere, but I would like that other users be able to go on using nothing if they want to.


I forgot to point out that there are some Widget operations available, but it is probably not enough…

And yes, my original post is that when changing racks the stored values are not consistently recalled. I’ve submitted a support ticket but no progress yet.

And then the thread went far away from that… Recall On Load not at all connected with that issue :slight_smile:

But anyway, thanks so much for finally getting me to the point of understanding how Recall On Load works for you. If in ADVANCE for your scenarios, you are enabling it for all widgets, that does make sense… but you wouldn’t actually need to uncheck it for a new setting, as I wrote, right? Just hit “save” in the widget edit window, with new value

ok makes perfect sense. And I’m sure there are other valid ways to use it, but at least you have eased my mind that there is at least one valid way! I do have to think on it a little more…as it does seem maybe a little over complicated… no one wants to save random changes right?

Anyway, thanks very much for all that. It was driving me nuts. But man, THAT MANUAL NEEDS A SERIOUS REWRITE FOR THIS SECTION!!!

Yes, using the above illustrated widget operations, anytime I can follow the steps “Enable recall on load/activate for all widgets”, change the widget values, “Update existing recall values only” and save the gig file. But if I want to change only one widget value, it is unfortunately more complicated…

Exactly, I don’t uncheck anything, I only decide if I need the “Also recall value on activate” option.

Feel free to propose something to the manual author :wink:

ok… I think maybe it is possibly the language difference. All the examples I was given for this are seemingly present tense to me… if you are in this situation, you can use Recall On Load to avoid problems. But in fact it is… if you are in this situation, IF YOU ALREADY used Recall On Load, it won’t be a problem.

If you move widget for cutoff filter… and then want to change and keep a new setting for your chorus widget, using Recall On Load at that point would not really be helpful to preserve cutoff filter original value. It would have to have already been enabled for filter cutoff.

I’m not sure how you could predict any specific widgets that might get moved purposely or accidentally, so this only a seems to make sense on a global basis… “Enable recall on load/activate for all widgets” I’m still uncertain how it would be used just for select widgets.

I’m also not sure why anyone would not want this enabled for their widgets. It just seems to me the default is you want your initial widget values to stay the same (gig to gig, not necessarily rack to rack) with an easy way to edit when you do want to make changes.

If and when I can figure that out I will indeed give a rewrite a try. Although it does seem to be just me that it confuses. But if I can save someone else at some point this confusion that would be worthwhile outcome.

@David-san I also wonder why you write this…

Don’t you just go to edit for that widget and hit save in that window? Or is that what you mean by more complicated?

Yes it is what I meant with “more complicated”, for a small widget adjustment, I have to go to the edit mode, change it, save it, and go out of the edit mode. I would dream of a right clic on the widget to access an “update widget” option.

I don’t know what I could tell to you to be even more clear. I think you understand well the different widget options. Now you have to decide how you want to work with them. The question is not to decide wheter the use of this or that makes sense, the question is can you find the right widget option to do what YOU want to do.

If you rigorously prepare a gig file for a gig that follows a linear chronological rackspace sequence, then you doesn’t need any recall option if you don’t want to use them. Simply set your widgets in every rackspace exactly like you want to find them when entering the rackspace and save the gig file.

But if, like me, you are not sure to be that rigorous, you also have the possibility to define and securely save an initial value for your widgets, which will be recalled when loading the gig file and this whenever you saved your gig file after having made changes to the values of the widgets.

If your music performance doesn’t follows a linear chronological rackspace sequence (e.g. when jamming) and you use several time the same instrument and want to start always with the same widget settings (B3 with slow leslie, Rhodes with fast chorus, or whatever), then the only way to go is to use the “Also recall on activate”.

Well, take the time to define what your own use of this widget options should be.

1 Like

Yes you are absolutely right, the important thing is that in fact GP does in fact do what I need. I most definitely do not work in any sort of linear sequential way and was concerned about that but it is fine.

In terms of Recall On Load, I was just concerned that I was missing something. I think I am pretty clear on it at this point , but there are still things that to me are backward and more complicated then need be. Yes I appreciate the versatility and accommodation for different ways of working. but the default for this feature seems to favor someone who plays a gig and moves their widgets all around and actually wants to save the gig file with all those random new values. It’s hard to make sense of that.

Seems to me the default should be Recall On Load or basically widget settings are always retained unless overridden, which works fine for every working method you mentioned. And then exactly like you say… a right click on the widget with option to save/update widget to the gig file… just like save/update rack file to gig file. Along with the more global Update Existing Recall Values… you’re all set, right?

Of course, you do need Recall On Activate and although I definitely use that, maybe more people don’t? But regardless two legitimate different ways of working.

Oh, is this more than one year old discussion with no conclusion? I just tried every possible combination of very confusing options to make my variations of rackspaces going to their initial state every time I select them. It seems like pretty straight forward need to me, but there is no way to achieve this. Maybe someone found THE solution - so please, let me know about it because it is very dissapointing right now.

For my understanding:
What do you want to achive?

Meaning I need variations to hold one initial state, which will be set every time on their activation.

So you want that the widget values in all variations are set to an initial value (could be different for each variation) when you reactivate the variation?

If this is the desired behaviour => use Set Lists

1 Like