@jamcultur Oh! I didn't know one could change an application's priority, thanks.

@ddw_music But couldn't it also be that Pd didn't empty the queue fast enough, either due to Pd being busy doing something else, or Pd not getting enough CPU cycles?

@ddw_music I tested with multiple Pd processes on Windows and got the same behavior, but my point was: if this is a Pd behavior and there's nothing about running as a plugin that forces one to rewrite the networking facilities, then what can the plugdata team do about it?

@jamcultur I always turn off all networking when running a show or use a subnet that no one else can access. Maybe note the time when it happens again and then look at the Windows logs to see if anything unusual happened at that time (search "event viewer")

@jamcultur Do you have MIDI Real-time messages flooding in? Does your patch ever get really busy doing something so that it can't dequeue incoming MIDI events in time? Are you generating bursts of dense MIDI for output? Are there other applications or services running on your computer that steal CPU cycles from Pd? (If you're on a Mac, QLab has a great sheet explaining how to turn off all the things that might interfere with your show)

Maybe try increasing the delay time in audio settings?

OMG, I'm gonna poke my eyes out. I just updated REAPER from 7.79 to 7.80 and the TCP closing issue changed. The connections still close more slowly than expected, but they at least close now.

@ddw_music Both--multiple patches in the same Pd instance, or multiple Pd instances on one machine. Not sure why your single process requirement is necessary since some DAWs sandbox plugins. But I'm way out on a limb.

I'm sad to report that I couldn't get [netsend] to receive responses from [iemnet/tcpserver], I tried all the different ways of responding, including broadcast, so that means this can't be a solution for plugins due to plugdata's limitation on externals. But using [iemnet/tcpclient] totally solves the standalone problem, which was really more of a test case than a problem, and it confirms that it's possible to have private exchanges with clients when there are multiple clients connected to a single port. Additionally, I tested my original [netsend/receive] patches with Audacity+plugdata, and everything worked! So now I think the REAPER problem may be specific to REAPER.

instanceIDService3.zip

@ddw_music Why is this a plugdata issue? Does it work in Pd? I'm asking because it would be good to know if plugdata had to rewrite Pd's networking stuff in order to run as a plugin.

@FFW If there was a way to get your first step to execute reliably (e.g. not dependent upon REAPER's timing), then I would just return an ordinal ID instead of a dynamic port number and my problem would be solved. But yes, if one could solve that first step, then the rest could be a solution to the lack of private connections in [netsend/receive].

I wonder if there's an external that implements a more robust TCP/IP solution, assuming I'm right about [netreceive]'s shortcomings? That would even work with plugdata plugins because the instanceIDService could run in Pd.

Edit: Bingo! iemnet/tcpserver has per client actions. I'll test today and report back.