I’ve just started using multiple instances, and am using Touch In/Out DATs to send data back and forth between the two instances of Touch.
Sometimes, when I start the instances up, I find that at least one of the Touch In/Out pairs has stopped working, and it resumes working immediately when I change them to a different port.
Is there something I’m inadvertently doing which is causing the ports to stay in use on close? I did a search but found nothing in the last year or so, so I thought I’d ask again, in case there are best practices for version 2021.
What I think is happening is Windows is somehow keeping a lock on those ports. I notice this myself for Websocket ports, but only during my development phase, when I start/stop processes really often and fast after eachother.
I’ve had to build perform window buttons to cycle through ports for the few times per week that the Touch In/Out OPs just aren’t connecting on open of multiple .toe instances.
Since I’m working on a permanent installation, and developing for it daily, I wish there was a more elegant way to ensure the instances stay connected, such as using a string or something instead, the way that Siphon/Spout or NDI works, as those seem to be quite reliable.
I’ve had similar problems with OSC communications in TDAbleton. The best fix I’ve found is to reboot. It does seem to be an issue with ports closing properly in some instances, especially if Touch crashes.