Filtering duplicate OSC messages before sending
Aug 01 2014 | 7:13 pm
I'm sending OSC from an audio app (Live in this case) to a visuals app. The control parameters changes at high rate for the audio modulation. The visuals app doesn't care. It needs the updated value only at say 25fps.
So I have my messages streaming into OpenSoundControl and bang it every 40ms. But between two bangs, the object might have received 30 or more of the same messages with different values, and sends all of them when the bang hits. So where I needed it to only to send the most recent value, I'm wasting bandwidth, and possibly cpu cycles on the receiving side where the messages are processed. For one messages this might not be such a big deal, but I imagine it becomes quite a mess when trying to do this with lots of parameters.
This seems like a really common problem, but I can't find any solution to it. The OpenSoundControl doesn't seem to have such a filter built in. A solution I can imagine is having a message buffer in front of OpenSoundControl which only stores one value for each unique OSC message string. Then bang that object to output and reset its state just before banging OpenSoundControl.
Does such an object exist, or is there a different solution? This seems like such a common problem.
- Aug 02 2014 | 3:39 amPerhaps [speedlim] could be of use...
- Aug 02 2014 | 4:49 amWhy not store the most recent value for each parameter, but only send it out as an OSC message at the slower rate?
- Aug 02 2014 | 8:37 am@spectro: No I don't think so, that would introduce time shifts as the speedlim is not synced with the osc output clock.@christopher: That is similar to how I've solved it for now. I was looking for a more generic and flexible approach where I don't have to explicitly sample every value I'd want to send. But maybe I'm making this bigger than I should. I have several M4L devices outputting OSC, so to have all devices combine their messages into a single bundle I've created one device which acts as the global OSC bus, and it sends out a bang just before closing its bundle. This bang is then used by all other devices to output their most recent value if changed. For what I'm doing now this is actually fine.
- Aug 03 2014 | 9:39 pmThis seems like a good use for the change object? Why not try and filter the duplicates before they become OSC messages in Live? Otherwise you'll have to parse the messages data and check for change.Also what Christopher said. I don't have Max here to open his example, but I'm guessing it could be using something like zl.reg to regulate the speed of its list output to something reasonable, if you're sampling every say, 25ms it seems like good practice anyway.
- Aug 03 2014 | 11:06 pmYes I know about change and zl.reg and I'm using a similar construction. I was looking for a way to send any of my control signals out to osc without having to throttle each source explicitly. Not having to worry about the osc framerate and synchronization in multiple places, but only at the final output stage.Say you want to send the same signal out to two applications, one doing audio and one doing video. Both would be processing at completely different time resolutions / framerates. Now you have to resample every source twice at different rates with a second zl.reg/bang/change construction everywhere. It would be more convenient and flexible to solve the throttling at the output stage of your data, in a single place.Anyway if I think it's relevant later I'll write an external for it.
- Aug 04 2014 | 12:13 amAh k I see what you mean.Yes some objects to offer filter OSC messages in Max would be very useful!Perhaps send a message to CNMAT? Their external could really do with some tools like this.
