Great, thanks for the update Jaymie! I am mostly worried it will negatively impact a possible port to a Windows version in the future though. I'm guessing that ARM will take precedence here - but will it ease an eventual port, or will it make the whole process more difficult (I realize this might be too early to know now)?
Keying with a good keyer is probably the simplest option to get a good result. A different approach is to use a still of the background, and mix it with the live input using a difference blend mode and play around with feathering/blurring. Adding (blurred) edge detection on top of the base image to define edges can also be something to look at. An expanded possibility is to also use the difference method, but sending it through desaturation and posterize it, then blur to get an alpha mask. This will be increasingly computationally expensive, so delays might have to be taken into consideration. Delays and order of operations should be its own topic though.
By the looks of the provided image, the lighting doesn't seem to be ideal for this type of shot. For something like this, I would have used side lighting either with fresnels with barndoors, or spot lights with knifes to cut out any spill on the backround. To make the hair contrast the background, I would also place a light of the floor behind the subject (uplight) that gives a contour around the subject, and also should light up any stray strands of hairs to make it look natural - or at least there. Side lights can be a bit hard/harsh though, especially when using different colors, so adding a front light in the front center at a steep angle could help transitioning/blending that effect.
As you'll want to have an as high contrast as possible to the background, the pendulums will combat that. If they are essential for the look, you could try a difference blend between a still of those and the background as well - I have never tried anything like that myself, but it probably won't hurt to try it. If that is no dice, maybe blocking the light travelling backwards with aluminium foil could be a solution.
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?