Script works in individual rackspaces, but crashes when I paste it in Gig Script

I’ve played around with it for a while but can’t get this script to work in my master Gig Script. GP just quits immediately with no error or log (that I see.) Runs fine in the individual rackspaces. Any help would be appreciated! :slight_smile:

Also can’t figure out why placing the OSC-sending portion of this in a function above On OSCMessageReceived makes the script do nothing.

Initialization
    SwitchToSetlistView()
End

var mUpdate : OSCMessage

On OSCMessageReceived(m : OSCMessage) Matching "/GigPerformer/Child"
    var songIndex : Int = OSC_GetArgAsInteger(m, 0)
    var songPartIndex : Int = OSC_GetArgAsInteger(m, 1)
    if SwitchToSongByIndex(songIndex, songPartIndex) then end
    
    OSC_SetAddress(mUpdate, "/GigPerformer/Parent")
    OSC_AppendStringArg(mUpdate, GetCurrentSongName())
    OSC_AppendStringArg(mUpdate, GetCurrentSongPartName())
    OSC_SendSpecific(mUpdate, "192.168.1.69", 54345)
    OSC_ClearArgs(mUpdate)
End

Wanna tell us what this script is supposed to do?

Sorry, it just receives a message like (1, 2) and goes to song 1, part two. When it receives the message, it sends back a message with the name of the current song and song part. It’s working, just not in the Gig Script.

Did you try it in the global rackspace rather than as a GigScript?

Who is SENDING the /GigPerformer/Child message?

What version of GP are you running and on what OS?

What machine is 192.168.1.69?

That’s indeed the first thing to do. But I would be curious to understand why would GP silently crash and quit because of this GPScript… :thinking:

Me too

Tried in Global Rackspace and it crashes the exact same way.

Who is SENDING the /GigPerformer/Child message?

Another instance of GP on the same computer.

What version of GP are you running and on what OS?

4.8.2 on macOS 13.6.1

What machine is 192.168.1.69?

There is just one machine, just chose the IP that GP lists in OSC Settings.

How is the GPScript running in the other instance? Could it be that you created an OSC loop? If you remove one of the GPScript from one instance does it still crashes?

I should have specified, my mistake. Can’t believe I left that out. The child instance quits the moment it receives an OSC Message from the other instance.

Here’s the relevant code from the other instance:

Update Function

This takes the values stored in widgets and sends OSC. Labels are just showing the current value.

Function update()
    var songScaled : Int = ScaleRange(GetWidgetValue(songIndex_1), 0, 100)
    var songPartScaled : Int = ScaleRange(GetWidgetValue(songPartIndex_1), 0, 100)
    var m : OSCMessage

    OSC_SetAddress(m, "/GigPerformer/Child")
    OSC_AppendIntArg(m, songScaled)
    OSC_AppendIntArg(m, songPartScaled)
    OSC_SendSpecific(m, "192.168.1.69", 54344)

    SetWidgetLabel(songIndexLabel_1, songScaled +1)  
    SetWidgetLabel(songPartIndexLabel_1, songPartScaled +1)
End

Child OSC message to widget labels

And this just takes the message from the child and applies it to a couple widgets.

On OSCMessageReceived(m : OSCMessage) Matching "/GigPerformer/Parent"
    var songName : String = OSC_GetArgAsString(m, 0)
    var songPartName : String = OSC_GetArgAsString(m, 1)
    
    SetWidgetLabel(songLabel_1, songName)
    SetWidgetLabel(songPartLabel_1, songPartName)
End

Everything else is local to the parent instance.

update() is called on rackspace or variation change, and also when any of the local widgets change the values.

I might be barking completely up the wrong tree, but I think you’d better declare mUpdate in the scope of the function and do not clear mUpdate (or do it before adding any args/address). Some functions are handled asynchronous, and maybe you clear the message before GP can send it.

I think it could be nice I you could provide us with the simplest possible version of your gig files for the two instances you use.

1 Like

As the « child » instance crashes when he receives the OSC messages, this would mean that, in the « child » instance the OSC callback crashes when it tries to read non existing integers. This is indeed something we could try to reproduce.

I missed that, but I agree: the child maybe crashes because of an empty message (no address, no arguments, etc.)

I wrote my own OCS library for c# some years ago. I can easily make it send an empty message and see whether the recipient crashes (but it will have to wait until tomorrow).

Try using SendOSCMessage