The ability to send/receive network commands over TCP IP. The serial node set is good for controlling equipment but is distance limited. Lots of equipment has Ethernet control for automating startup and shutdown etc. Some other software packages also offer UDP multicasting too. This would be excellent for long-term installations.
Software like Watchout and Touch Designer has the option of TCP or UDP. Watchout keeps a TCP socket open for a period of time before needing to be re-established. Perhaps an optional timeout period would be useful.
Thanks for the feature request, @bLackburst. I’ve opened it for voting — (edit:) and updated the title to try to clarify what the proposed nodes would do. Â
Vuo Pro? Well that counts me out then…glad I didn’t vote on my own feature request. How do you determine this?
Perhaps I should have made that more clear when I opened it for voting. Sorry, @bLackburst. The idea behind Pro features is that they would be particularly useful to professionals in the industry, and not so essential to hobbyists. For TCP and UDP messages, a lot of the equipment that they would be used with is professional-grade and fairly expensive. Hobbyists have the alternative of using OSC (a protocol on top of UDP) and some other protocols. So that’s why this feature request is Vuo Pro.
Well it kind of dooms feature requests though. You won’t get an idea of appeal to current community because non-pro license holders won’t waste their votes on it.
Why would I vote for a typical pro feature request as a hobbyist ? Even if it was not marked as 'pro" ? Â
I think what you’re trying to say is that you wouldn’t vote for something you’re not interested in, which is good, it’s what it’s about . I’m talking about people who would find the feature useful but won’t vote because it’s been relegated to pro.
It’s not about me buying a pro license, I’d be happy to if the features were there, but they won’t get there in the first place like this. For instance, what proportion of users are pro?.. They get the same amount of votes so the weighting isn’t there, and they’d have to buy it before they can vote and wait for it to be implemented.
I honestly don’t see how a network command is any more “pro” than lots of other standard features like serial etc. It’s just another protocol.
Anyway, these kinds of conversations have kind of become systemic with vuo. The devs are smart people, I’m sure they understand their place in the market etc, they’ll decide what they think is best. Just offering a second opinion.
1 Like
Yeah sorry my comment was in bad english, edited it.
I honestly don’t see how a network command is any more “pro” than lots of other standard features like serial etc. It’s just another protocol
Yeah it’s all about the right balance to find between what is pro and what not. And as you said so yourself, I think the team is really fair regarding that.
What do you mean generally then ? That the feature requests should not inform about regular / pro implementation ? Or just in this case that TCP / UDP is standard protocol that many non pro users would use ?
The devs are smart people, I’m sure they understand their place in the market etc, they’ll decide what they think is best. Just offering a second opinion.
Yeah hope you don’t get me wrong, I just wanted to add my 2 penny.
The team is always welcome to hear comments, suggestions and questions like yours and discuss it I guess, so it’s all good ;)
@bLackburst and @Bodysoulspirit, interesting discussion, thank you.
Yeah it’s all about the right balance to find between what is pro and what not.
Yeah. We try to find a good balance, and hopefully are getting better at it over time. The criteria we use to decide if a feature is Pro or non-Pro have been evolving as we learn more about how people are using Vuo and what people like and dislike about the pricing structure.
For instance, what proportion of users are pro?.. They get the same amount of votes so the weighting isn’t there,
There’s some weighting behind the scenes, though, because we’d try to add some Pro features into a release if the top-voted features were all non-Pro.
I honestly don’t see how a network command is any more “pro” than lots of other standard features like serial etc. It’s just another protocol.
Part of Team Vuo’s thought process behind this is to try to guess whether the typical (median, average, whatever) project using the feature would be high-budget or low-budget. Like, how the cost of Vuo Pro would look relative to that budget. For the serial protocol, a lot of people would be interfacing Vuo with an Arduino or Raspberry Pi, and there’s a large community of hobbyists using those for maker/DIY stuff that is relatively low-cost to build. For general-purpose use of TCP and UDP protocols — and I’m talking about being able to send free-form data via those protocols, not using the more structured protocols that sit on top of them like OSC — that’s a less common thing to do, and many projects would involve the scenario that you brought up, @bLackburst, of interfacing with particular equipment or software packages. Although there would be exceptions, our best guess is that typical projects using this feature request would have higher budgets, and thus Vuo Pro would be more affordable than in a more maker/DIY-type project with a shoestring budget.
Anyway, I appreciate your wanting to hash this out, and maybe through discussions like this we can find ways to improve the feature requests process.
I’d upgrade to pro for this feature alone.
2 Likes
Please?
This is a pro feature 
To be frank, when you are in the position of needing this, you are also in a place where you have multiple computers/macs. If you then can’t afford the very cheap for its abilities* licensing that Vuo Pro provides - I don’t understand in what context you are using it or how you would use it without other far larger investments in other things. I’ve had Pro (or what became pro?) since I had a very low-wage part time job, and it was still affordable at that time.
*I just looked up a NDI to SDI bridge server where the SW costs $1800 for 8 channels of I/O. HW comes in extra. A composition to do the same thing takes about an hour to make if you need a GUI. 5 minutes if not.
1 Like
Definitely would like a UDP send/receive. Kind of the standard in exhibition environments.
Adding votes now.
Those of you who use UDP/TCP communication in your work, what hardware/software do you most often use it with (that isn’t already supported in Vuo with OSC)?
1 Like
I would like to connect to Notch, which has an alpha implementation of sending/receiving geometry over UDP. This is quite experimental at the moment, but still fun as Notch is really poop at the base generative stuff.
Another more important use case is getting the positional info from our Panasonic AW-UE150 PTZ cameras. They use the FreeD protocol via serial/udp (but I’m not trusting 50m of serial cable 
). More info on that here: http://docs.vizrt.com/tracking-hub-guide/1.0/description_of_the_freed_protocol.html
1 Like
My immediate need is to control projectors through their rs-232 ports using a USconverters’ wifi-rs232 device. The device is not OSC compliant. It listens to a port, when text comes in on the wifi it is passed to the rs232.
If touchOSC or vuo;s OSC, can output ascii to an arbitrary IP & port, then my problem is solved,
Now looking at this video,
https://www.youtube.com/watch?v=3cGqrWCayDc
awkward for large text strings, but may imply an easier method.