Unexpected OSC Behavior When Switching Rackspaces

OSC
1

Environment:

  • Application: Gig Performer
  • OSC Monitor: TouchOSC Protokol
  • Setup: 2 Rackspaces, each containing one widget (knob, label)

Steps to Reproduce:

  1. Open GP (new empty gig).
  2. In the first Rackspace:
  • Add a knob.
  • Set its OSC/GPScriptHandle to "KNOB".
  1. Create a second Rackspace.
  2. In the second Rackspace:
  • Add a label.
  • Set its OSC/GPScriptHandle to "LABEL".
  • Leave the “Enable OSC” option unchecked (OFF).
  1. Start an OSC monitor (e.g., Protokol).
  2. Switch from Rackspace 1 to Rackspace 2.

Observed Result (Step 6):

Even though “Enable OSC” for the label is OFF, the following message is sent:

15:57:52.845 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:53050) ADDRESS(/ClearAll)
15:57:52.845 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:53051) ADDRESS(/RackspaceName) STRING(Rackspace_1 : Default)
15:57:52.845 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:53052) ADDRESS(/RackspaceIndex) INT32(1)
15:57:52.845 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:53053) ADDRESS(/CurrentGlobalTranspose) INT32(0)
15:57:52.845 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:53054) ADDRESS(/CurrentBPM) FLOAT(120)
-> 15:57:52.845 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:53055) ADDRESS(/LABEL) STRING(New Label)

Expected Result:

No OSC message should be sent for the label since the “Enable OSC” setting is disabled.

  1. Go back to the first Rackspace and enable “Enable OSC” for the knob.
  2. Switch from Rackspace 2 back to Rackspace 1.

Observed Result (Step 8):

The following messages are received:

-> 15:56:57.957 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:49950) ADDRESS(/KNOB/SetValue) FLOAT(0)
-> 15:56:57.957 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:49950) ADDRESS(/KNOBName) STRING()
15:56:57.957 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:49951) ADDRESS(/ClearAll)
15:56:57.957 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:49952) ADDRESS(/RackspaceName) STRING(Rackspace : Default)
15:56:57.957 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:49953) ADDRESS(/RackspaceIndex) INT32(0)
15:56:57.957 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:49954) ADDRESS(/CurrentGlobalTranspose) INT32(0)
15:56:57.958 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:49955) ADDRESS(/CurrentBPM) FLOAT(120)
-> 15:56:57.958 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:49956) ADDRESS(/KNOB/SetValue) FLOAT(0)
-> 15:56:57.958 | RECEIVE    | ENDPOINT([::ffff:192.168.42.179]:49956) ADDRESS(/KNOBName) STRING()

Expected Result:

Each OSC message (per widget) should be sent once upon Rackspace switch. Duplicate messages may indicate unintended behavior.

Questions:

  1. Why is /LABEL sent even though “Enable OSC” is off?
  2. Why are /KNOB/SetValue and /KNOBName sent twice during the switch back?

Can someone please try to reproduce this? Am I doing something wrong?

(Using GP5.1.1; Win10Pro)

2

This is what I got switching from Rackspace 1 to Rackspace 2 and then back to Rackspace 1

000013
000013672×404 41 KB

I didn’t get any messages from /KNOB. Did you have KNOB with OSC enabled? I did not, as you didn’t specifically mention to do so.

3

Why
ADDRESS(/LABEL) STRING(New Label)
when the OSC for the label is disabled?

And yes, make the OSC enabled for the KNOB. Then I have twice:
ADDRESS(/KNOB/SetValue) FLOAT(0)
ADDRESS(/KNOBName) STRING()

4

OK, with OSC enabled on KNOB I get this result:

000014
000014684×455 63.1 KB

So I see these twice also:
ADDRESS(/KNOB/SetValue) FLOAT(0)
ADDRESS(/KNOBName) STRING()

It looks like the first one is received as a state before the actual switch occurs and the second one is received as a state after the switch.
I don’t know why LABEL would have any messages.

5

Hmm… OK. Thanks! So it’s not my settings.
My problem is that I’m obviously synchronizing too many widgets via OSC. Touch OSC sometimes doesn’t update all of them when changing rackspaces, even though all the events are sent out.
Then I saw that many events are duplicates, and some are unnecessary—but that’s just how GP is, and I can’t prevent it.

6

One of them is part of a bundle

It doesn’t have a message - it has an argument which is the default caption “New Label”) when created.

That sounds like a bug - please report it

Yeah, they’re coming from different places — and it may depend on what’s going on. Also, bits of this are for legacy compatibility. We put quite a few items inside bundles as those guarantee that everything (or nothing if the packet is dropped) gets seen but didn’t want to risk breaking stuff for people who weren’t handling bundles.

7

What do you mean by bundle? These two events?
ADDRESS(/KNOB/SetValue) FLOAT(0)
ADDRESS(/KNOBName) STRING()

Just to be on the safe side:
These two events (=Bundle?!) each occur twice during a Rackspace change. (see my first post)

8

The OSC format has a concept of ‘bundles’. It’s only a small wrap around some normal OSC messages.

9

Thanks a lot for your explanation! I’m still not entirely sure how that relates to the two OSC messages being sent twice during a rackspace switch – meaning both at the beginning and at the end.
Could you maybe clarify that a bit more?

10

As long as the values are correct, I’m not sure what is the actual concern. I suspect though that this particular duplication because the info is sent out when the rackspace is activated and then again when the variation is activated. Would have to look at the code to see exactly what’s going on.

11

Hm… Wireshark tells me both are part of a bundle, so that doesn’t explain it.

Pcap file:
to bundle or not to bundle.zip (551 Bytes)

If message were sent ‘stand-alone’ and bundled, it would make sense, but as this seems not to be the case, it could be a bug.

12

I’m using TouchOSC to keep more than 100 widgets in sync, and generally, this works quite well. However, I’ve noticed that when switching rackspaces, some values occasionally fail to update on TouchOSC.

My suspicion is that TouchOSC can’t keep up when too many OSC events are sent at once.

I’ve already excluded some non-essential widgets from sending OSC, which has improved reliability — but not completely.

If a) OSC messages from labels where OSC is not enabled were omitted, and b) the duplicate messages from knob widgets were avoided, that would eliminate more than half of the OSC events. I believe this would make synchronization with TouchOSC significantly more reliable.

13

They you should report that to Hexler — they should be able to buffer all incoming messages separately from processing them and a few hundred UDP messages should be a big nothing.

That sounds like a bug - if you haven’t given a label an OSC handle, it shouldn’t be sending anything out - please report that through our ticket system.

14

Are you running it on a different computer or on an iPad/Android tablet? If so, there’s also always the risk that some UDP packets will be dropped - the UDP protocol does not guarantee delivery.