Should we move OSC handling and Routines to different threads?

[loopier]

I've been pushing routines quite a bit, and have noticed that they affect the overall efficiency. When using routines with very short intervals, it affects the overall application framerate.

Same applies to receiveing lots of OSC messages at short intervals (I have tried that with SC). They appear to stack in a queue that some times can take quite long to process completely, leading to awkward behaviour.

[loopier]

I've been told that the issue might be solved with putting the code currently placed in OscReceiver::_physics_process() inside a while loop to get all the messages in the queue. As it is currently implemented it might be taking only 1 message per frame.

Current code:

func _physics_process(_delta):
    if socketUdp.get_available_packet_count() > 0:
        var msg := parseOsc(socketUdp.get_packet())
        var sender := "%s/%d" % [socketUdp.get_packet_ip(), socketUdp.get_packet_port()]
        Log.verbose("OSC message received from %s: %s %s" % [sender, msg.addr, msg.args])
        osc_msg_received.emit(msg.addr, msg.args, sender)

For something like:

func _physics_process(_delta):
    while socketUdp.get_available_packet_count() > 0:
        var msg := parseOsc(socketUdp.get_packet())
        var sender := "%s/%d" % [socketUdp.get_packet_ip(), socketUdp.get_packet_port()]
        Log.verbose("OSC message received from %s: %s %s" % [sender, msg.addr, msg.args])
        osc_msg_received.emit(msg.addr, msg.args, sender)

[totalgee]

Yes, the OSC processing should handle all messages in the queue before returning. I've also seen this lag issue in C++ programs, too, when only one message was handled per update.

[loopier]

Resolved in dcc3176eebe6c2f174d173f8ef864ff35d26fb5f.