I guess this is a case of:
"Make OSC Output" = Broadcast - This will make Vuo spit out OSC data to all connected interfaces and IP ranges they are set to (usually a terrible idea, but useful in some limited cases).
"Specify OSC IP Output"= Unicast - This will make Vuo spit out OSC data to a specific IP (most likely connected via a specific interface within the specified range).
Can't you also disable the offending network (wifi) from receiving OSC messages in VDMX?
IIUC: If you happen to be on a network where you can't specify a fixed IP address, then the DHCP server could change that IP from session to session and you could end up with a conflict. The other Vuo nodes I listed should help in that case but I must admit my tests don't work all the time. For some reason the output ports are not always added in my client app (VDMX). It would be nice if the Vuo team could help us with some reference compositions showing how to do OSC sending robustly for all network setups, including none :-)
It looks as though a combination of 'Specify OSC Output' 'Get OSC Output Values' and 'Specify OSC IP Output' will handle varying IP addresses. It would be nice if there was an example Composition for sending OSC; the two included are for receiving.
Dear, I investigated more and i found that bug is not in Vuo code, but in us not reading documentation. :-)
"Make OSC Output" documentation says:
"Connect this node to Send OSC Messages to dynamically choose an OSC port to broadcast on. Unlike the Specify OSC IP Output node, this node sends to all devices on the network. "
So, if you use "Specify OSC IP Output" with 127.0.0.1 as IP, duplicate OSC isuue solves. :-)
If it is a bug it's been there since 1.2.8. But I agree if this is intentional it really should be more obvious how to avoid the duplicates. You may be on to something with multiple OSC channels (something like an Auto/Omni being added) but the tests do specify particular ports throughout.
I just tried the test composition on a brand new machine - with default network settings - and and saw the same behavior; with WiFi enabled incoming OSC messages are repeated. If I disable WiFi before starting the App, I don't see the duplicates (either in OSCulator or VDMX). Not really sure what to try next, other than run without a network obviously :-)
I spoke too soon. The cause of the repeated OSC messages is network related, and I had my network disabled during my last tests. I think there is some sort of loop. With my wired adapter connected I get two repeats, and with WiFi on also I get two or three more. Nothing appears to be out of place with network settings, so I'm not sure where the problem is...