[LOGGED] Add UDP support to Isadora

[Juriaan]

Hi there, 
UDP is a topic that has been discussed in the forum for quite a long time and let's face UDP is quite a 'dumb' protocol but is used in many applications that we find in our working field / hardware. Now a days with motion tracking / etc we see that UDP is used for his really fast send through to the other end. Not being able to use UDP in Isadora (and yes UDP is used already in the program, since OSC goes over an UDP library most likely) causes that we have to use an middelware program and can't empower fellow users with a 'simple' user plugin since Isadora doesn't speak the language :) (https://community.troikatronix...)

I propose that we add UDP to the list of supported protocols to the main core of Isadora (so let's make it a first class citizen just like TCP. Please do not make it a 'Plugin' like Art-Net / etc)

[bonemap]

@juriaan said:

add UDP to the list of supported protocols to the main core of Isadora

 Hi,

This may need a bit more elaboration about what is exactly being requested here. If the idea is a UDP protocol that attempts to support all of the Isadora data types, as in a mutable data type port, is that really workable/viable? it would be fantastic, to say the least - a very exciting development. However, what are the implications for supporting an inherently indeterminate protocol? Susceptible to packet delivery failure and dropout. Would we find it useful on top of OSC, NDI, Syphon, Spout, Net Broadcaster, TCP etc? 

I think if it was viable, to be a truely Isadora 'mutable' port that provided networking for data types over the internet including those not already supported by a networking option, would be ideal... and with the added potential of multicasting - excellent. 

Best Wishes

Russell

[mark]

@bonemap said:

This may need a bit more elaboration about what is exactly being requested here. If the idea is a UDP protocol that attempts to support all of the Isadora data types, as in a mutable data type port, is that really workable/viable?

Basically it would be done in the same way as the Send Serial and Send TCP actors... the formatting commands offered in those are robust enough to probably get the output you need. Do you agree @Juriaan ?

Best Wishes,
Mark

[Juriaan]

Yes sorry all for the confusion.. Something with little sleep ;) Being able to send a payload just like the TCP actors would be great. The formatting options that you currently offer are fine :) (Just something with witchcraft and trying to figure it out sometimes..)

Thanks !

[bonemap]

@mark said:

in the same way as the Send Serial and Send TCP actors

Ah! OK that gives an indication of what to expect. Not the most intuitive networking interface then, when compared to say OSC. And there is consideration for Send and Receive UDP actors?

Best Wishes

Russell

[Juriaan]

@bonemap

Personally I think we need to have that discussion either way. The same could be said about DMX / ArtNet. We really miss the nice 'way' of OSC in those actors as well. Same goes for Networking (TCP / UDP) actors. But personally I rather keep those discussions seperate in there own little topic to make sure that we give both the attention that it needs. For now the request that I wish to make goes about having a UDP actor just like we have a TCP actor to make sure that we as artist can keep creatings plugins / actors for our own needs / share them with the community.

[mark]

@bonemap said:

Not the most intuitive networking interface then, when compared to say OSC

OSC is a well defined protocol with a specification. That's why it's easy.

UDP is a system that allows you to send data between two points. It has no specification regarding that data sent between those points, and thus the format of the transmitted data is whatever anyone defines it to be. This necessitates an incredibly flexible way of expressing how the data is formatted.

I mean, I really don't know how to make the methods used by the Serial In Watcher, et. al., any simpler.

I reckon you all don't want to learn C programming structures, and the vagaries of commands like fread, ftell, etc. to send your data. (I include those man pages here to give you a sense of how daunting they might be for a non-programmer.)

If anyone here knows of a way to allow non-programmers to easily define the formatting of complex binary data structures simple for those who aren't programmers, please post your ideas here. I will seriously consider it.

@Juriaan 

The same could be said about DMX / ArtNet. We really miss the nice 'way' of OSC in those actors as well.

To compare OSC and DMX is like comparing apples and oranges. OSC is a standardized protocol that knows nothing about the underlying hardware or application. DMX requires recognizing a particular piece of hardware to work, e.g., the LanBox or the Enttec DMX USB Pro which receive their DMX data in absolutely different ways (the former with TCP/IP, the latter with serial data). I created an actor for the LanBox because it was the "only game in town" way back when. When the Enttec DMX USB Pro started gaining popularity, my idea was to create a set of actors that were flexible enough to address many different pieces of hardware, thus the Matrix Value Send and Matrix Value receive actors and the associated "raw" sending actors that allowed a more general approach that could be implemented in User Actors.

Now, like OSC, ArtNet is a protocol that knows nothing about the underlying hardware. But what about these could be more "nice" @Juriaan?

The problem with putting this kind of functionality in the main Isadora program is that you need to release an update for people to receive new functionality. Putting this new functionality in actors instead of the main program allows quick update cycles based on user feedback, which is a huge advantage as you've seen with the Screen Capture, NDI Watcher, OpenNI Tracker actor and others.

Best Wishes,
Mark

[Woland]

I know this discussion is ongoing, but I wanted to say that I've added this to our list of feature requests.