I think different. For myself, nothing in life is standard.
This forum and community is a made up of a few dozen technical experts that create software/hardware/technologies that make it easier for the larger majority to create large artistic light displays without the need to become experts themselves. They don't need to have memorized PIC registers but they can use a Renard dimmer board to control lights. They don't need to understand the OSI networking model but they can stream large amounts of data from a Raspberry Pi to a pixel controller. They can do this with the free or reasonable priced technology created for this purpose. They people who created this technology didn't do it to make a profit. If they did they'd be working for Light-o-Rama. They did it because they like enabling other people.
But the technical experts that created this technology don't want to spend the rest of their free time providing tech support. There is a way to reduce the complexity of support for the community, it's through standardization. That's the (literal) reason the standard dimmer hardware, the Renard SS dimmer, was created. SS stands for "Standardized Series". It's been the same design for years. Sure, we could make improvements. We could have integrated WiFi onboard, we could have higher density outputs, we could have a kitchen sink by now. But all those improvements would only make it harder to support people who want to use it. It would make it harder for us to identify problems people might have through this forum. By keeping it the same design, end users have better chances of success, we aren't stuck writing new revision of a user manual every change, and we are able to support users and identify issues much quicker.
Now some people, like yourself and even I sometimes, like designing new technologies just because we like to swing the hammer we know and love. They don't fill a need by the community and don't offer anything new. And that's fine, and it's even fine to share. I have my own version of Sporadic's ESPixelStick, and I even share it online. But anyone that asks me about it or wants to buy one from me, I send to to Sporadic's group buys instead. Because it's better for the community that his design be the standard for that tool.
Yes, this sub forum is to discus output modules for Vixen. And it's awesome your are sharing your new TCP method. But the potential outcome of your wording is what causes concern.
My goal was to create this, release it, and see if it would be useful on a Raspberry Pi or the Beaglebone Black type of platform, wired or wireless.
TCP is connection-oriented so it will be slower than UDP but the data will arrive at the destination, guaranteed and in the proper order. That is not the case with UDP.
A few dozen people who are not tech experts may read this. They may incorrectly infer that TCP is superior to the UDP based protocol the community uses and believe they will be ahead of the game by using your output module. They may also infer incorrectly that there is no other way to stream to a "a Raspberry Pi or the Beaglebone Black type of platform". When they run into issues using it and you aren't around to support them, the Vixen Developers on this forum will now have to spend time working with them to get the issues resolved, probably by educating them not to use you module. Time for them they might not have had to spend had these users simply used the 'standard' output modules.
Better wording, one they would still allow you to share your project without the potential risk stated above, would have been something along the lines of
I created an output module for Vixen using TCP. I wanted to try a design that used a connection based approaching instead of streaming UDP packets. I'm posting it here for anyone interested in trying it out. If you don't know the difference between stream and packet based protocols, I suggest you stick with the standard Vixen outputs.
Now for anyone that wants to be educated, because there are people that lurk the forums just to learn things, the protocol 'standard' for this community to stream light data is called sACN or e1.31. It's the same thing, different names. The
wiki goes pretty far in depth explaining it. Yes, it's UDP based and in most applications UDP is frowned upon because data order and reception integrity is considered most important. We don't want web pages loading out of order or missing parts. But in our applications, like with streaming video and VOIP, latency is more important than data order and reception integrity. Data order is still somewhat important, which is why sACN has it's own method to detect out of order packets and drop them, but latency is still most important. This is why 'we' use UDP to stream blinky lights data. It's why there hasn't been a TCP output module for Vixen until now.
If you don't want to worry about universes or weird channel limits (mine doesn't have that) I invite you to try my output module. Again, I have no weird channel limits or universes (whatever that is).
Again, wording is key. I invite you to spend some more time learning about sACN, why it has universes and where the the 512 channel limit comes from. You might be more cautious about trying to turn people away from it if you do.
