Issues with OSC Message Rate and Dropped Messages in GH via UDP Ghowl

Grasshopper
1

I’m encountering a challenge with my setup where I have two computers networked: one laptop running OSC Pilot, sending messages to a Processing application, which then forwards these messages across the network to a PC running Rhino. In Rhino, messages are received via UDP Ghowl in Grasshopper (GH).

My project involves a GH sketch that generates geometry, curves, surfaces, and allows toggling the display of these elements on and off. However, I’m facing an issue where OSC messages are dropped when they arrive faster than a certain threshold – seemingly around one message per second. Document relative complexity below, roughly one - two second maximum execution time.

March 17 red
March 17 red2400×807 276 KB

Here’s a concise breakdown of the setup and issue:

  • Setup: Laptop (OSC Pilot) → Processing → PC (Rhino with GH running UDP Ghowl).
  • Problem: When interacting rapidly with the touch interface on OSC Pilot (e.g., tapping three buttons quickly), not all messages are registered in the GH UDP module, even though they pass through Processing correctly.

Interestingly, when I isolate the UDP reception section in a new GH document, message reception is flawless, supporting a high rate of interactions. However, in the full GH document, subsequent messages sometimes don’t appear in the panel display. This is the section:

OSC UDP Section
OSC UDP Section1742×1881 441 KB

Attempts to Resolve:

  1. Distributing messages across five different ports for better management – didn’t resolve the issue.
  2. Having Processing resend messages multiple times at specified intervals – introduces latency and inconsistency.

Questions:

  • Could the execution of a GH path be monopolizing Ghowl, preventing it from reading incoming messages?
  • Are there alternative strategies or protocols I could adopt to improve data flow into GH, ensuring a reasonable update rate?

I’m open to any protocol that can interface well with Processing and GH. Thank you in advance for any insights or advice you can provide!

2

Hi! 90%, that’s not the reply you’re looking for. But as a tip or a reminder, have you tried the Bengesht plugin? :thinking:As You didn’t mention it in your post.

3

I wasn’t aware of this, will take a look, thanks.

1 Like
4

Not so much as monopolizing, but the whole GH process needs to finish before allowing new input, regardless of input method.

I can think of two scenarios:

  1. You create an intermediary message que, so that each message is only passed when gh is not busy. This is if you don’t care about latency (which i think you do)
  2. You can create checkpoints throughout the GH definitio that stop execution if there’s a new message, and restarts the process with the new message
5

Appreciate that, it explains a lot of some of the lag I have been experiencing. Will give some thoughts now to checkpoints and priorities of operations that take longer than others.

Can I assume that a given execution path that has not had updated messages will not re-execute?

The approach might be to have Processing bundle the OSC messages for a group of toggles into one OSC message instead of sending one by one.

output_trimmed_enhanced_red1

output_trimmed_enhanced_red2

6

Yes, changes are usually downstream.
I say usually because I’ve run into some unoptimized gh plugins that kept running even with no change from upstream

7

Sounds like a reasonable approach. Wouldn’t hurt to try