OSC reception broken after an important OSC traffic

Issue encountered

GP script OSC reception callbacks as well as regular OSC enabled widgets don’t react anymore to incoming OSC messages (until GP is stopped and restarted). Sometimes « Unrecognized GP Script runtime error » messages appear in a GP Script log window. When the latter happens, each time an OSC callback should be called, a new « Unrecognized… » message is displayed.

Conditions of occurrence

At a time, in a situation where a GP script contains many OSC reception callbacks supposed to react to some specific OSC messages, while an important OSC traffic containing these messages is received.
=> time : after 5sec to 5min
=> OSC traffic: approximatively 3kBytes sent in 620uSec (corresponding to 120 OSC messages packed in 8 OSC bundles, see example here )

Expected behavior

Even if some OSC messages are lost because GP is unable to deal with a too important incoming traffic, it should go on to react to incoming OSC message.

Observed behavior

Everything else seems to work properly, but until GP is stopped and restarted, the OSC reception won’t work anymore.

Way to reproduce

  • generate somehow an important incoming OSC traffic (a second instance of GP won’t be able to produce it)
  • use GP script OSC reception callbacks and/or OSC enabled widgets reacting to the incoming OSC messages
    (- optionally monitor the OSC messages using an external monitoring tool => ref. to another post)
  • wait until there is no more reaction to incoming OSC messages

Way to reproduce with an RME audio interface

My own way to reproduce the issue is to use and RME audio interface and its software mixer TotalMix FX with “OSC control” and “send peak level” enabled.

  • Options->Enable OSC Control: checked
  • Options->settings->OSC Tab … « Send Peak Level Data »: checked
  • Check the TotalMix and GP OSC adresses
  • use the following gig file which monitors if the OSC reception is still alive: OSC_RECEPTION_TEST_5.gig (29.3 KB)
  • push the test button and adjust the slider to the right

Even if nothing happen from the TotalMix side, it sends at least a few meter messages, such that if the TotalMix and GP adresses are set properly, the reception LED flashes. Then to generate a larger incoming traffic using TotalMix, the idea is to change the current controlled bus (/1/busInput, /1/busPlayback, /1/busOutput) which produces an important OSC traffic.

Additional hints

  • issue reproduced with GP 3.5 and older versions on a 2.7GHz Core i7 laptop running Windows 8 and a 3GHz Core i7 NUC PC running Windows 7
  • issue reproduced with GP 3.5 on a Macbook (macOS Mojave v. 10.14.6, Core i5 2,8GHz, 16Gb RAM), but it also crashed GP almost always simultaneously. A few times it only crashed when restarting GP after an OSC broke.
  • if we consider an OSC buffer overflow, would it kill the GP OSC reception?
  • having OSC bundles in GP Script could perhaps allow me to come closer to the OSC traffic generated with RME TotalMix FX using a second GP instance for this’s

This is very useful. I’m hoping to get my hands on an RME interface soon and I’ll look at this issue more closely

From my side, I asked my PhD student if we could do the test using his Macbook. We will do so next week.

I just tested OSC_RECEPTION_TEST_5.gig on the Macbook (macOS Mojave v. 10.14.6, Core i5 2,8GHz, 16Gb RAM) of my PhD student plugged to my RME UCX.

The OSC reception broke in a similar way, but interesting, it also crashed GP almost always simultaneously. A few times it only crashed when restarting GP after an OSC broke.

I authorized GP to send a crash report.

Thanks - that’s very helpful