OSC port stops working after a while

OSC
21

Gotcha! OK, I"ll avoid a 2 way between 2 widgets.

Intersting observation… Protokol is showing OSC activity as long as only the main instance is open. As soon as I open the second instance, Protokol shows NO activity, but the communication is working between the GP widgets/instances. I close the second instance, Protokol shows activity again. I open second instance, immediately protokol shows no activity, but the widgets work.

What does that mean? Is that normal behavior?

22

Is the list of shown OSC messages increasing?

23

That is because you need to setup protokol as a man-in-the-middle. If GP and protokol are both listening on the same port, only one of them will receive the messages (unless you use the broadcast address while sending: Jam Performer - #9 by Frank1119, but that would complicate things, so better leave that for now, until you sorted out the matter at hand)

Yep. The simplest way to explain this is by comparing it with a family with two children and both have exactly the same name and they live in the same house: if something is received by mail for who is it intended? No way to tell.

2 Likes
24

When only the main instance is open, yes.

25

Thank you for that excellent explanation! So apparently GP is the bully child b/c it just grabs the mail! But I think we like it like that! LOL

26

“Ooops I did it again!” :wink:

Well, I was able to reproduce that pop up message. Similar steps. Open GP with shift key to turn off open last gig, hit “open file” then cancel. Got this:

image
image801×257 34.9 KB

But not EVERY time… However, twice in the last hour…

27

Just lucky (although I suspect GP to open the listening port usable for receiving broadcasts).

28

I can reproduce that, but there’s a little more to it:

  1. Start the GP instance
  2. Open the general options dialog
  3. Turn off ‘Reload the last gig on startup’
  4. Switch on ‘Open template dialog at startup’
  5. Switch on ‘Reload the last gig on startup’
  6. Close the Options Dialog
  7. Close GP.

Now the sequence leads to the ‘desired’ error message:

  1. Open GP with the shift-key pressed
  2. Turn off ‘Load last gig file’
  3. Click OK
  4. The ‘New Gig’ template dialog appears
  5. Click ‘Open File’
  6. Click ‘Cancel’
  7. Now the error appears.

I’ll create a bug report for this.

Edit: I created the bug report, but I say let’s leave this alone: It is probably not the root cause of your issues.

1 Like
29

GP opens the listener the desirable way: The listening socket is bound to 0.0.0.0, so the problem with networks being available or not does not apply. No reason to investigate this path any further imo.

1 Like
30

Thanks for doing all that! I agree, its probably not the cause of my issue. My hunch is it might have to do with the two-way communication causing a loop. Lets see how it does after I eliminate that.

31

The simplest way is to have the slave instance sending on a different port, not in use by any GP instance (or any other program. You can use netstat -ano | find "*:*" in a terminal/command box to reveal all listening UDP ports, including the program ID).

Sending them out on a port where no one is listening will cause up all messages ending up in the bit-bucket doing no damage.

1 Like
32

Its been pretty solid. I have to conclude (at least at this point) that it was the loops that caused it. Not sure if there is a built in protection that turns the port off, but the same ports have been staying solid since I only have a one-way from main to second instance between widgets.

33

Fingers crossed :crossed_fingers: