Gig Performer Crash 4.8.2

Gig Performer 4.8.2 crashed while I was using it. Windows 10 Pro
Would anyone be able to help find the cause of the crash?

It’s best that you upload these files as attachments (could be zipped), rather than pasting it directly into the post.

2 Likes

4091c08a-f357-4011-908b-b452fc8f473d.zip (33.2 KB)

OK - this is weird — by any chance are you doing anything with the tuner view? According to the dump file, the crash seems to be happening there but it’s unclear why.

Yes, I have it scripted that the tuner is active when the volume pedal is at 0, and deactivated when above 0.
Some of the script is Global and some is in the rackspace script. The tuner was not on at the time it
crashed, I was playing guitar when it crashed.

Just out of the blue, it crashed?
Can you reproduce?

1 Like

I had tuned my guitar with the tuner, then gassed the volume pedal, and played guitar for a few minutes.
Then it crashed. I have been attempting to reproduce the issue and will continue to try to crash it.
I plan to work on this over the weekend, shouldn’t be to difficult…tune guitar, jam for a while etc.
Will keep you posted! Thanks David :slight_smile:

It might be helpful to share your script, to see how you are enabling/disabling the tuner. If the script is constantly sending commands then it could cause unexpected behaviour.

1 Like

image


Some things I don’t understand here.

  • You have widgets in both global and local rackspace called VOLUME?
  • I’m not seeing the purpose of the global rackspace script. It’s calling the check on tuner mode and toggling for every single change to the VOLUME widget.
  • You have widgets in both global and local rackspace called VOLUME?
    Yes, becuase they are affecting the same Volume control pedal.

Once the tuner mode is engaged, pressing the Volume control pedal will not unengage it unless
the unengage script is running in the Global Rackspace, which superceeds the Tuner mode.

Are both of those volume widgets mapped to your expression pedal?

1 Like

Ok so the if statement should be on the outside I guess, so it only checks if the Tuner mode is engaged?

Yes, that is correct.

I think something like a global volume and tuner toggle should be just managed within the global rackspace. Assuming you want this as a consistent control for the entire gig file.

The timers are also useful for wah, because you’re constantly rocking the pedal and it avoids an unnecessary deactivation. But I wouldn’t have thought it necessary for volume, unless you are doing swells.

I have a timer set to activate Wah with expression pedal #2. Expression Pedal #1 is for Volume and
also toggles the Tuner Mode when at 0 for a certain amount of time. What happened was I scripted
both in the script rackspace, but then had to move the ToggleTunerOff to the Global rackspace script
to get it to work, and was just lazy and left the ToggleTunerOn in the script Rackspace. I will move it
as you recommend.

Certain hardware units like Fractal Fm3 will toggle the tuner when the Volume Expression is down,
and I had wanted to emulate this with Gig Performer. What a great software program!

1 Like

Scripting is an amazing tool in GP. But I think you’ll benefit from simplifying. Particularly if you have two widgets mapped to the same pedal, and both with code that toggles the tuner - it’s more likely to hit some edge case / race condition, which could cause a crash.

Indeed I did notice from the stacktrace that the crash was being triggered by a timer callback.

I wonder if we have a nasty race condition going on.

I have timer conditions set up for WAH, VOLUME (toggle tuner) and also recently added a third
timer callback for resetting/refreshing the Widget values for Helix Native. But that only activates
on a patch change…is a race condition a way of saying the timer callback is triggered while it is
already triggered?

That’s one possibility — once you’re using GP Script, there are fewer guarantees since we can’t stop you from creating race conditions without extending the language in ways beyond its intent. If you can reproduce the problem, then we may be able to address that specific race condition but until we know what’s going on, it’s hard to fix! The tuner subsystem itself may need to be protected from reentrant calls, if that is in fact what is happening.

1 Like