I played a bit with OSC In CHOP, feeding TD with Max flow of OSC.
At each value received, I test it against a match case etc. no pb.
It works fine.
Each time it matches, boom, I’m changing the color of something, I change the seed of a noise TOP, and just display it. Easy and very newbie prototype thing.
I’m also counting the match case, in order to see if I miss some messages and it seems to workd very well.
When I come to high OSC rate of messages from Max, I fill that some messages are dropped.
I understand ideas of sampling, queueing etc but would you have best practices in TD for this kind of (quite usual) situation ?
Of course, I use the counter in order to avoid the screen refresh issue in case some flashes (very short ones) would miss the screen redraw or something like that.
Should I play with the queue ? Or should I do some kind of quantization somewhere in order to be sure EACH message requiring a flash would match the redraw ?
The Problem ist that OSC is based on the UDP-Protocol
This image shows it relatively nice:
So the issue is, the Server is just splurting out the osc-message to the clients and thats it. If or in what order the arrive is of no interrest to the server any more.
TCP/IP on the other hand makes sure that every package arrives and that in the right order, but this is aquired by returning a message to the server and making sure that the package arrived, which makes it much slower then UDP.
You can use queue or a lag/filterCHOP to minimize flickering but you will introduce latency and inaccuracy to the values. So kinda of a tough call.
I have almost always resorted to OSC in DATs instead of CHOPs if I am needing specific one-time or “bangs” from max. I find that an OSC In DAT scoped to a particular address range paired with a proper callback is the best way to reliably respond to every message.
I only use the CHOP for continuously streaming realtime sensor data. Even slider control I typically use the DAT if the slider only sends when moved. The DAT is also more useful for seeing every message and debugging an integration. It’s nice because you can use as many DATs and CHOPs listening to the same port as you want so you can use the different OPs for different purposes. In a decent local network its actually quite hard to drop UDP packets I’ve found, you have to be pushing some serious data to start doing that. If you are then you may want the source to send redundantly with a timestamp or message ID so you can check against that and verify if you’ve already responded to a given message if it is important that only a single reaction occurs to a one-time control/command message. The DAT will also run its callbacks agnostic of framerate of TouchDesigner which can be good or bad depending on your data rate.
I know OSC CHOP has gotten a lot of robustifying in recent years, so it may be able to handle your needs, but the DAT is the most reliable for catching everything still since their is an abstraction layer in the CHOP to get the signals into usable TouchDesigner channels.
Actually, count counts every messages (I use a click sound at each message sent). Of course, if I increase the rate, I can’t count…
But even with chop, it seems to be OK,
I’ll test with OSC In DAT + callback.
Actually, all my midi flow coming from my sequencers will come there, as some OSC things.
So this won’t really be continuous, but at some point, rate will be not so small.
I’m thinking about MIDI CC too.
Don’t know which one will be the most appropriate.
