OSC script stops working with predictive loading

OSC
1

Eversince I turned predictive loading ON this bit of OSC script only works one way. OSC in general is working (widget advanced property “direct OSC” works), but this script that uses this “OSC_SendString(”/lbl1", txt)" does not work.

I have a “stepper script” linked to a widget in Instance 1 that for each tap, selects a preset in a plugin in instance 2. Then, after selecting that preset, the widget label’s caption is sent back to instance 1 to be displayed in a text label. It works one way (from main instance that has predictive loading ON). The selection (stepper) from instance 1 is recieved and making the proper changes in instance 2, but the label caption isn’t being sent, or perhaps I should say isn’t being received by instance 1. The text label does not work. This only happened after turning predictive loading on. Here is the script in instance 1:

Var
txt : string
lbl1 :  Widget
//  RDlbl : widget
Stepper, B5prsts : Widget
stepperValues : integer array = [46, 899, 828, 36]
index : integer = 0

Initialization
SetWidgetLabel(Stepper, "" + stepperValues[index])
End

On OSCMessageReceived(m : OSCMessage) Matching "/lbl1"
txt = OSC_GetArgAsString(m,0)
SetWidgetLabel(lbl1,txt)
End

// Called when a single widget value has changed
On WidgetValueChanged(newValue : double) from Stepper
if newValue > 0
then
index = (index + 1) % Size(stepperValues)
//SetWidgetLabel(Stepper, "" + stepperValues[index])
SetWidgetValue(Stepper, 0)
SetWidgetValue(B5prsts, stepperValues[index]*0.001)
end
End

Here is the script from instance 2:

//Organ Preset Text Label update
    var
    B51, B52, B53, B54, B55, PresUpper, PresLower, lblB : Widget
    txt : String

    On WidgetValueChanged(newValue : double) from PresUpper 
    Sleep(5)
    txt = GetWidgetLabel(PresUpper)
    OSC_SendString("/lbl1", txt)
    SetWidgetLabel(lblB,txt)
    End

Worked fine until predictive loading was turned on. Thanks!

2

In what instance did you enable predictive load?
I built 4 rackspaces in each instance
Predictive Load set to 1

OSC is working fine, so cannot reproduce the issue you have.
Are you sure OSC is enabled and the settings are correct?

Tested with 5.3.3 on Mac

3

Predictive loading is only turned on in instance 1. It’s set to three racks by default. As I said, OSC works in general, meaning via the widget advanced mapping. It’s only that script line to be sent via OSC that doesn’t get sent back from instance 2 to 1. It works perfectly without predictive loading but does not with it on.

4

I did the test and it was working also with predictive load.

5

Can you upload 2 small gigs showing the issue, so that I could check on my system?

6

I’m starting to think its memory related actually. Whenever I use a smaller gig file for the 2nd instance, it seems to work fine. My memory was around 96-98%. That’s when it doesn’t work. I didn’t even realize this at first. When I reduce it to 90 or less, seems to work fine. Let me see if this is consistent. Thanks!

7

I removed bunch of plugins, got the memory below 90% and its still not working reliably with PL ON in main instance. The receiving script lives in individual regular RS, so I’m guessing what’s happening is the RS is not (fully) loaded yet when the script if received. Does that make sense? However, even after its loaded, if I click the stepper button (which changes the preset in 2nd instance and that in turn changes the label which is sent back to Inst 1) is still doesn’t work.

I’ll try to reduce the file size and upload sample gig files soon.

8

That’s very possible

9

Nope, that’s not it. Tried putting delays in the sending instance as well as the receiving end, no bueno. Tried putting a “request” for the osc message to be sent upon rs active, didn’t work.

Sending instance is sending it, protocol sees it, Wireshark sees it, but it never gets received by the receiving instance. Will try to put a better (what I believe to be) bug report together.

10

With OSC being glitchy with PL ON, I tried sysex. Just to keep things super simple, before even getting into translating bytes into letters, I just wanted to see if sysex can be applied to labels, I made this very simple gig file set, main instance 1 and 2. 2 sending to 1. I setup loopmidi for sysex communication. I see sysex coming in via global midi monitor, but not updating the label widget. Shouldn’t this be working?

SysexCommunicationTest MAIN.gig (35.5 KB)

SysexCom Text Instance2.gig (27.5 KB)

11

Here is the OSC breaking after switching rackspaces. Turn predictive loading ON.

  1. Load the OSC…MAIN gig file. Stay on 1st RS, do not change RS.
  2. Open existing instance “TestSync”. Press buttons SendA and SendB in instance 2 and you should see the label updating fine.
  3. Now swith to another RS then back to the “MY Rackspace”
  4. Label does not update: OSC communication is broken.

OSC-comTest MAIN.gig (46.8 KB)

OSC-com Text Instance2.gig (37.9 KB)

12

What is expected to happen? What does it mean to apply sysex to labels?

13

The same thing is expected to happen in both sets of gig files I uploaded for testing. The label in instance one is supposed to update based on pressing button A or B in instance 2. In the OSC version this works all the time with predictive loading OFF. With predictive loading ON, once you switch RS and come back to the “My rackspace”, the labels do not update anymore.

Sysex was a work around attempt to see if I can have PL ON and still get string messages across. To my knowlege, the only other way to send string (text) from one instance to another is either OSC or sysex. So since OSC breaks with PL ON, I wanted to try sysex. It is showing up fine in the global midi monitor but its not making its way to the label. In my test gig file example, without even getting into decoding sysex binaries, I just wanted to see if the receiving instance can react to incoming sysex by simply displaying “sysex received”.

So basically, I am in search of a way to get string (caption of a label in instance 2) over to instance 1 with predictive loading ON? I’m on 5.2.2. Is there anything about this in 5.3.3 that might have fixed PL with OSC?

14

Unfortunately there may be quite a few things that don’t work well with predictive loading. Predictive loading was developed as a compromise to allow machines with insufficient resources to be able to at least be able to play plugins but some of the more advanced features in GP, designed and implemented before predictive loading, were never intended to be used in an only partially loaded gigfile.

it will require some significant investigation to see what can be done

15

Understood. What about sysex? Even with PL turned OFF, I can’t get the label to display any change. Is this the right way to go about it on the receiving end? I see it coming in in the global midi monitor, so there is “SysexEvent” but its not responding in the script to the “on SysexEvent” line. Is there another way to try?

var
lbl1 : Widget
lblIn : MidiInBlock

On SysexEvent(s : SysexMessage) From lblIn
SetWidgetLabel(lbl1, "SYSEX RECEIVED")
End
16

One small update: I just realized I had to uncheck the sysex blocking in the midi in block. There is hope! Tomorrow I’ll work more on it. See if that was it…

17

Seems like the sysex solution is working nicely! I got PL ON, switched and added new RS (something that always broke OSC with PL ON) and its working solid so far! I am able to get different text messages sent across instances with the text appearing perfectly! :slight_smile:

Remember to uncheck the Sysex event blocking in the virtual midi In block!

Here is what worked if anyone needs this:

Senging instance:

var
PresUpper, lblB : Widget
txt : String
lblOut : MidiOutBlock  //Loopmidi Virtual Midi Out Block
sm : SysexMessage

On WidgetValueChanged(newValue : double) from PresUpper 
txt = GetWidgetLabel(PresUpper)
SetWidgetLabel(lblB,txt)
sm = "F0 " + StringToHexString(txt) + " F7"
//This is what goes to other instance
SendSysexExternal(lblOut, sm)
End

//For when RS change occurs in other instance, it sends a 
//"request" to update the label
On OSCMessageReceived(m : OSCMessage) Matching "/req_lbl1"
sm = "F0 " + StringToHexString(GetWidgetLabel(PresUpper)) + " F7"
SendSysexExternal(lblOut, sm)
End

Receiving instance:

Var
txt : string
lbl1 :  Widget
lblIn : MidiInBlock  //Loopmidi Virtual Midi In Block
sysTxt : string
i : integer
b : integer
asciiChars : string array = [" ","!",""","#","$","%","&","'","(",")","*","+",",","-",".","/",
"0","1","2","3","4","5","6","7","8","9",":",";","<","=",">","?","@","A","B","C","D","E","F",
"G","H","I","J","K","L","M","N","O","P","Q","R","S","T","U","V","W","X","Y","Z","[","\","]",
"^","_","`","a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t",
"u","v","w","x","y","z","{","|","}","~"]

//Using OSC in this direction only (b/c it works even with 
//predictive loading ON) to update label on RS change

On Activate
OSC_SendString("/req_lbl1", "")
End

// Incoming Sysext from other instance
On SysexEvent(s : SysexMessage) From lblIn
sysTxt = ""
For i = 1; i < SM_Length(s) - 1; i = i + 1 Do
b = SM_GetValue(s, i)
if b >= 32 and b <= 126 then
sysTxt = sysTxt + asciiChars[b - 32]
end
End
SetWidgetLabel(lbl1, sysTxt)
End
18

Everything works, but I just discovered a behavior I don’t really care for… which is on every RS change, 4 identiacal sysex messages are being sent to every (inactive) RS b/c they all have the same virtual midi in block. For w/e reason, a widget value change message is being sent on the “direct OSC” message path (between the 2 widgets connected by OSC not by script, but in the advanced widget properties OSC window) even when the widget’s actual value didn’t change upon every rackspace activation. Again, the widget’s value did not change, but the OSC is still sending its value. That widget value changed message in the other instance’s widget is triggering a sysex to be sent, to reflect the proper label text I’ve been working on. IN addition, for w/e reason (unclear to me) it is being sent 4 times. So on every RS change, the same exact sysex message is sent 4 times to EVERY virtual midi block that lives in every RS. Maybe I can just ignore, but I’m worried about potential conflicts. I don’t like unnecessary messages being sent to every RS on every RS change. I’ve been trying different things to stop it, but can’t come up with a solution. Is there one? Sorry, I’m sure this sounded pretty confusing, but if you look at the “receiving instance” script above, will explain the widget value changed trigerring syses, but of course it doesn’t explain why 4 times?? Is there way to not recieve this sysex on inactive RS’s? I had tried bypassing the virutal midi in block but that doesn’t do it. Scripting goes through anyway.

19

Do you have a really simple example that we can use to reproduce this issue?

20

A simple example demonstrating this would be useful too