Every time the user switches to a new rackspace or rackspace variation or songpart snapshot, my global rackspace script needs to read the values of certain widgets in the new local rackspace and perform a bunch of work based on those values. I’ve written a function “newRackspace()” which performs these tasks.
I’m implementing the “On Rackspace” and “On Variation” callbacks, and I’ve observed the following:
In Panels mode, if I switch between variations within a single rackspace, then only the “On Variation” callback is called. If I switch from one rackspace to another, then only the “On Rackspace” callback is called. In Setlist mode, if I switch between songpart snapshots that both use a single rackspace, then only the “On Variation” callback is called. However, if I switch between songparts that use different rackspaces, then both the “On Variation” and “On Rackspace” callbacks are called in quick succession.
In order for me to read the values of widgets in the local rackspace, I am using BindExternalWidget, which requires me to provide the name of the current local rackspace in question. The “On Rackspace” callback provides me with the index of the rackspace, from which I can determine its name, but the “On Variation” callback does not.
I’m calling my newRackspace() routine from both callbacks, and a problem occurs when I change between songparts that use different rackspaces, because it means that newRackspace() gets called twice in that situation, and in the first call, it’s reading widget values from the wrong rackspace (since the “On Varation” callback gets called first, and it doesn’t yet know the name of the new rackspace.)
There is a function to get a rackspace GetRackspaceNameAtIndex(index : int). If you use that together with GetCurrentRackspaceIndex() you get the name of the active rackspace.
This is not the same as GetRackspaceName(). The latter returns the name of the rackspace the calling script belongs to. (In your case always GLOBAL RACKSPACE).
Exactly what I do. I do this all the time and I implemented almost the same in both On Rackspace and On Variation, I don’t care which one is triggered until it works as expected and it does
Well, ok……stop trying to use Gig Performer like that !
You’re basically breaking the way local rackspaces are intended to interact with the global rackspace, even more so when local rackspaces are under the control of song parts that can change rackspace widget values. Rackspace widgets mapped to global widgets will set global widget values and maybe you should just be detecting and responding to those events after they occur.
There are no guarantees that operations will occur in the order you expect them. For example, depending on what is going on, your global script might capture local widget values before the song part gets around to changing them, or worse. some of them before and some after. The order in which these events occur is not guaranteed and could change with different versions of GP and also depending on the order that other callbacks are triggered.
What exactly are you trying to accomplish from a musical perspective?
Basically my goal is to build my dream VST host within the global rackspace. Once I get everything implemented and debugged I’ll share it with the community.
In this case what I’m doing is basically trying to replicate the functionality of global parameters (but without the 128-parameter limit). When the user switches variations, the global rackspace reads widget values from the local rackspace, and when the user modifies those widgets in the global rackspace, it writes the new values into the local rackspace for storage.
But if you have a good use case, why don’t you explain it here and request more parameters? I think it could be much better and efficient than dealing with GPScript to reproduce what already exists. I also use the mechanism you describe, but not to reproduce things which already exist…
!
