Hi, I’m brand new to Vuo and hope to use it to process some incoming video from Syphon sources and send results over OSC. A simple demo patch (that determines the overall brightness) sort of works, but I’m struggling to get the OSC side to work properly. It currently sends duplicate messages (three typically) and doesn’t send them exactly when a new frame comes in from Syphon. So I suppose the problem is ‘Send OSC Messages’ is receiving multiple triggers as the new frame is being processed?
My real patches send many more values over OSC so the duplicates add up to a huge number per second, so much so the receiving App (VDMX) can’t handle it, and I’m pretty sure some are arriving out of order.
Thanks for any pointers on how to get one OSC bundle sent per received Syphon frame!
Adrian
(I’m using the Vuo 2 beta but the problem occurs in version 1 also, so I’m sure it’s user error.)
I had some success chopping down repeats by using ‘Hold Values’ on a ‘Fire Periodically’ timer but I’m still seeing each OSC message twice. I was hoping ‘Allow Changes’ would trap these but strangely it does not.
i tested and got into the same trouble. I simplified the composition, stripping out Syphon nodes. This shows that probably the issue is tied to OSC input or output nodes.
Let’s wait for Vuo team for ideas, possibly that’s a bug.
regards
michele
(edit: I try to upload a video here, but it doesn’t show neither in preview nor when the post is online)
As a workaround, you could build an image filter vuo composition, outputting the values you need. Loaded in VDMX as a filter, you can feed it with a Syphon source from VDMX itself and have the data you need directly as output parameters, without OSC. Stripping all that OSC and Syphon handling that could even give better performances.
This actually started out as a plugin for VDMX but I ran into performance issues there too (VDMX frame rate dropped) and the App route looked to fix that . However, I never tried throttling the plugin with ‘Fire Periodically’. The other issue is I believe I need ‘Improve Downscaling Quality’ which is Vuo 2 only, and VDMX doesn’t support those plugins yet. I’m curious, so will definitely give it a try.
I may have cracked it. Perhaps the duplicates were caused by the App running at a super high frame-rate, or Syphon couldn’t provide new fames fast enough. Anyway, the attached simple composition works as expected. I’d still welcome any insights, though. I’m definitely a beginner at this.
(I tried throttling a plugin with ‘Fire Periodically’ but only the simplest Compositions didn’t impact VDMX frame rate.)
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…
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 :-)
Jood job, @Adrian. I confirm that my previous posted patch too, oscsend.vuo, recevies two osc messages with wifi enabled (as shown in the post before), but just one disabilng wifi.
Here is after a few moments with wifi enabled (please note “Count” debug boxes):
I’d call it a bug, or anyway let’s wait fro Vuo Team opinion, as surely it’s a behaviour one wouldn’t expect. Possibly an option to send or receive just on a specific network or bus?
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.
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. :-)
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.
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 :-)
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?
With Specify OSC Output, Vuo sends to the specified port on all devices on the network.
With Specify OSC IP Output, Vuo sends to the specified port only on the device(s) at the specified IP address.
Macs have at least 2 or 3 network interfaces (local loopback, WiFi, wired network, and possibly a VPN).
VDMX receives OSC messages through all network interfaces.
[@cremaschi] So, if you use “Specify OSC IP Output” with 127.0.0.1 as IP, duplicate OSC isuue solves. :-)
[@MartinusMagneson] Can’t you also disable the offending network (wifi) from receiving OSC messages in VDMX?
Yep, either of those should solve the problem.
[@dr.drainaway] 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.
That should only be an issue if VDMX is running on a different computer. If it’s all on one computer, 127.0.0.1 is always your localhost address regardless of DHCP.
