So here is the scenario:
Let’s say Im at Racspace 1. I go into let’s say options then general. When I exit the options Gig Performer switches to Rackspace 8 every time, even though that was not the active Rackspace.
This also happens when exiting Tuner.
I can not figure out why this happens. Any suggestions?
Can you upload a small gig showing the issue?
1 Like
Here it is. My main rig where this happens.
KW GIG.gig (1.3 MB)
1 Like
OK, I can reproduce.
Now checking what is going on…
i also see this happening…
var
CLEANK, EOBK, RYTME1K, RYTME2K, SOLOK, CLEAN2K, EOB2K, RYTME22K, SOLO2K : widget
RS_selectors : widget array = [CLEANK, EOBK, RYTME1K, RYTME2K, SOLOK, CLEAN2K, EOB2K, RYTME22K, SOLO2K]
On WidgetValueChanged (sWidget : widget, sIndex : integer, sVal : double) from CLEANK, EOBK, RYTME1K, RYTME2K, SOLOK, CLEAN2K, EOB2K, RYTME22K, SOLO2K
SwitchToRackspaceByName(GetWidgetLabel (sWidget), 0)
End
This is the global rackspace script, and it switches the rackspace
Yeah I use that script to be able to press the widgets in global Rackspace to change to different backspaces. The script is messing it up to always default to RYTME22K widget?
When the script is a little bit changed this can be seen int the Script Logger
var
CLEANK, EOBK, RYTME1K, RYTME2K, SOLOK, CLEAN2K, EOB2K, RYTME22K, SOLO2K : widget
RS_selectors : widget array = [CLEANK, EOBK, RYTME1K, RYTME2K, SOLOK, CLEAN2K, EOB2K, RYTME22K, SOLO2K]
On WidgetValueChanged (sWidget : widget, sIndex : integer, sVal : double) from CLEANK, EOBK, RYTME1K, RYTME2K, SOLOK, CLEAN2K, EOB2K, RYTME22K, SOLO2K
Print(GetWidgetLabel (sWidget))
SwitchToRackspaceByName(GetWidgetLabel (sWidget), 0)
End
So the callback is executed when the options dialog is closed.
Yeah and also when the tuner closes.
I got help with the script and not too familiar with scripting myself.
I can’t tell for sure what exactly is going on in your rackspace - it sure is caused by the On WidgetValueChanged() callback of the script, but i don’t know why this is triggered, nor why it always stops at rackspace #8 
Maybe @dhj has an idea about what’s happening here and why?
Anyway:
I took the chance to implement the radio button addition and with the new script under the hood, everything works as expected (also using the tuner and not losing the actual rackspace).
I decided to use numbered handles/names for the widgets, so it will be much easier to see at a glance if the number and the sequence of the widgets and arrays is correct!
I also removed the assignment of the widgets to the “System Actions” Plugin - as far as i can tell you shouldn’t additionally use those connections to the SelectPartOrVarXYZ parameter, since this will aready be done by the script! But to be honest, removing those assignments in your origin gig file didn’t have any impact on the faulty behaviour of the script.
Well, just have a try if this one better suits your needs:
KW GIG(radio).gig (1.3 MB)
1 Like
Thanks, seems to work great now.
However changing with my midi foot controller does change the Rackspace, but the radio buttons do not follow.
I do not longer have the return to Rackspace 8 default when turning off tuner etc.
Would be nice if there was a feature that lets say illuminates a red widget in global panel when Rackspace is either changed within gig performer using the mouse, from OSC when using touch or with PC message from my midi controller.
Like: If Rackspace X is active (either with mouse click, OSC or mid controller button) then turn on X widget
Yeah, i tried to implement this last evening, but i didn’t succeed… in most cases the script ran into an infinite loop which caused GP to freeze, or the whole script did other weird things.
This kind of stuff has to be thought through very carefully, because one event causes the other and vice versa (activating a rackspace will light a button, the lit button will activate the rackspace again, which will try light the button and so on)… it’s not easy to differentiate the “real” cause of a change and react to the one but ignore the other.
Even if the code looks like the sequence of events might happen the right way, you cannot count on it, since everything can happen at the same time (well… almost) and will be handled with diffrent priorities…
3 Likes
thanks guys, problems seems to be solved 
1 Like