Not being flexible there were a fixed amount of effects pre-programmed and they could be changed manually by interrupting a loop.The system was based on WS2812B addressable LEDs running on a loop and powered by an Arduino Mega, the effect could be changed by pressing a button on the control console. Ossia uses websockets instead of http for OSCQuery? or how that comes to the the json in itself is fairly simple but can be nested to arbitrary depths.In 2018 I made the first version of this low budget club lighting system for a New Years Eve Party in Ramallah Palestine with my collective The UNION, more about the story and the collective at the end of this article. Implementing OSCQuery HTTP server seems to be pretty straightforward with C# too, is there anything more convoluted required to communicate with ossia/score to their full extent? NET reflection and interfaces for manual serialization. I’m actually playing with the idea of a CLR object OSC (de)serializer using. Please correct me if I’m wrong because Ossia seems to be an interesting stuff for me. However in C# there’s already a very handy OSC interpreter inside VVVV.Utils, a helper library for vvvv plugin development and the only real advantage of Ossia in this situation would be handling the object hierarchy and the OSCQuery server afaiu. NET which is fine but then it might make more sense to create Ossia bindings for C#. It’s true you can write a vvvv plugin in C++ but only with the C++/CLI variant for. Parsing JSON data in vvvv is actually surprisingly easy (read: devvvvs created a node which deals with deserializing json strings into usable objects (in this very case converting it to XML dom and using linq XElement in vvvv)) and actually a lot of things like that has been taken care of for vvvv so ain’t so bad but I hear you ) In addition, being based on WebSockets, the discovery protocol can be used to work directly through a web browser which isn’t possible with raw OSC you always have to have an additional translating process that converts WS messages from the browser into OSC hi! thanks for the insight, yeah message size limitation-wise tcp makes much more sense. Well actually a previous protocol we used was just that ( ) but we ran into a lot of limitations, the biggest being that since OSC is most of the time sent through UDP, you have a hard limit on how many bytes you can put in a single message - in some braindead routers, this limit being sometime as low as 800 bytes - hence the protocol has to chunk the discovery in a lot of small messages which makes the whole stuff an order of magnitude slower than just sending a single JSON message over TCP. From past experience it’s a few days of work to get the first objects to say “hi”, and an additional year to sort out all the additional edge cases “ah I thought OSCQuery is a reflection method implemented inside OSC (which tbh would make more sense, why introduce another socket)” I think that the better way overall would be to have a proper integration of ossia in vvvv like we do in Max, Pd and other languages, which can be relatively easy to do if there’s a proper C++ plug-in API - seems like there’s one. Parsing JSON data from an HTTP request in a dataflow environment is not something that I’d wish on my enemies :)
0 Comments
Leave a Reply. |