GetVariationName() returns unexpected results when called from On Variation() in Global Rackspace on Gigperformer Startup

My first Post here. Great community! I’ve found every thing here I’ve needed since I bought Gig Performer and started scripting in 2021. Unfortunately I’ve found an issue I can’t overcome.

How to Reproduce:

Create a new gig

Past this script into the Global Rackspace Script Editor:
On Variation(oldVariation : integer, newVariation : integer)



Save the Gig File

Quit Gigperformer

restart Gigperformer

Unexpected Results in Log Window:
GLOBAL RACKSPACE: GetVariationName() cannot be called at this time.
GLOBAL RACKSPACE: GetVariationName() cannot be called at this time.

Expected Result:

GigPerformer Version 4.8.2
OS: macOS Catalina 10.15.7

Subsequent Calls to this script function as expected if you add another variation.

On the next startup the Unexpected results appear again.

File Open and Open Recent have slightly different results:
GLOBAL RACKSPACE: GetVariationName() cannot be called at this time.
GLOBAL RACKSPACE: GetVariationName() cannot be called at this time.

I’ve had some crashes I can’t reliably reproduce. I can mitigate by only processing when newVariation > 0. This leads me to wonder if newVariation and/or Variation Names are undefined when On Variation() is triggered the first 2 times during startup.

Possibly Related:

Example File:
GetVariationName() cannot be called at this time.gig (13.1 KB)

I think it is just a so called “race condition” at loading time.
I can just guess that the global rackspace (and its embedded script) is loaded before any local rackspace.
That’s why the script receives a 0 as newVariation value - because there isn’t any valid variation at this moment. You can check that by using a Print(newVariation), which throws a 0 on loading, but will throw the selected variation name if you re-compile after loading (the script failed and is deactivated on the first run).
So, all you’d have to do is to intercept that unwanted 0-condition.

On Variation(oldVariation : integer, newVariation : integer)
If newVariation <>0 then 

Would do the trick!


Hi @LonghairDave, welcome and thank you for entering the GP Community forum. Now, that you are in, I invite you to go on participating to this forum. :wink:

Regarding your question, I have a similar explanation than @schamass. You are probably using print() for debugging purposes, but what exactly are you trying to achieve?

1 Like

Thank’s for the explanation. I didn’t consider a race condition.

In practice I think it’s the same result as newVariation <>0
Minor problem is the first variation is number 0 and would never be processed. In fact I don’t use the first variation for this reason.

Hi David-san,
I appreciate the welcome.

I am using print()to demonstrate what I think is a problem.
I’m trying to achieve documentation of the problem and hopefully a resolution at some point in the future.

My actual code is switching presets based on the variation names. I’m finding that startup crashes are more frequent as the number of variations and presets grows. I don’t want to complicate this post with my use of experimental functions and not using rackspaces in the suggested ways.

I don’t really use the scripting interface, but I do use the external API a fair bit…

Through the external API there is a callback for OnStatusChanged() and one of the statuses is GPStatus_GigFinishedLoading or something to that effect.

I used to have some unwanted behavior like you are talking about while Gigs were initially loading, but now I always wait for the GigFinishedLoading status before I let anything Rackspace/Song/Variation/Songpart related run.

I’m not sure if there’s an equivalent in the scripting interface, but that might help.

1 Like

There are callbacks for when the gig is finished loading. It’s only available in the “gig” script, but there are creative ways to pass this to the global rackspace script e.g. OSC.


Understood. Take also care that not every plugin like switching presets.

You now have two different tips; testing the 0 value of the index variation and checking if the Gig is fully loaded. Please, tell us if it helps. :wink:

1 Like

Thank you for several very good responses to my post.

3 Solutions were offered

  1. Check newVariation <>0
    I’m been using the equivalent of this for about a year. After learning about a possible race condition I’m not convinced newVariation is always a valid value. If it’s not a valid value then the comparison itself might cause a crash. I’ll need to learn more about the threads involved to trust this.

  2. Sleep(100) or similar Post Deleted by Author
    Might work. I wouldn’t want to rely on this alone as a solution.

  3. Wait for On SystemEvent Matching GigLoaded (Gig File Script Only) AKA OnStatusChanged()/GPStatus_GigFinishedLoading(from external api)

After “On SystemEvent Matching GigLoaded” I still had “GetVariationName() cannot be called at this time. “
I used SetEnvVariable(“GigLoaded”, “true”) in the gig Script
GetEnvVariable(“GigLoaded”) in the global Rackspace Script to pass a value.
There were crashes but not consistently. I was so hopeful this was the solution.

See Attached: Finish GetVariationName() race-GigLoaded.gig

No acknowledgment of what I believe is an error to be documented though.

Now I realize, in a more proper programming fashion, the need to check the validity of GetVariationName(newVariation) until a valid value is returned

While GetVariationName(newVariation) == “” Do

See Attached: Finish GetVariationName() race-Wait For Valid GetVariationName

I think I’ve overcome my own problem in this post. I’ll probably write a wrapper function for GetVariationName()

Many Thanks to All!


The comparison won’t cause a crash - even if the newVariation is not valid, it will still be an integer. Further, the GetVariationName() function checks that a rackspace is active (which is why you get that warning if you call it before everything is ready) and only tries to get a name if there is an active rackspace.

The problem is that, for technical reasons, some preset switching happens during startup, which is why you’re getting that callback multiple times. I’ll have to see if I can address that

Can you post one of these crash reports please?

Thanks for the clarification.
I haven’t been able to reproduce a crash of my example files above.

I’m posting one of my crash reports from the Gig File I regularly use with preset switching. It’s from a few days ago and before I made changes per above. I can’t verify that it’s an issue with variations or something else. Many (~135) Variations and Presets (190+). If It’s confusing this issue because it’s not focused on the issue at hand let’s just delete it from this post.

I can’t seem to find how to attach a file again:
Drop Box Link: Drop Box Link to Crash Report

Hmm, this is a crash inside the GP Script runtime library but the stacktrace doesn’t make sense, it’s referring to stuff that shouldn’t be implicated.

Can you try turning off the Scripting option “Recompile automatically” and see if that makes a difference?


I have set “Recompile automatically” off.

Not an immediate crash on startup. Crashed when I selected another song.

Dropbox Link to Crash Report