Dr. Spankenstein

When handling OSC messages I'm stuck creating many 

 objects to filter the incoming messages. This soon gets a bit messy as indicated by this patch.

I'm working with the assumption that the messages can only handled with a switch case like scenario as they need to be explicitly known beforehand. However, if anyone has any suggestions for a more elegant and flexible method when filtering a large number of incoming OSC messages it would be most welcome.

When handling OSC messages I'm stuck creating many route objects to filter the incoming messages.  This soon gets a bit messy as indicated by this patch.

I'm working with the assumption that the messages can only handled with a switch case like scenario as they need to be explicitly known beforehand.  However, if anyone has any suggestions for a more elegant and flexible method when filtering a large number of incoming OSC messages it would be most welcome.


handling-osc-messages-is-there-a-better-approach-than-explicit-route-objects

CNMAT's [OSC-route] might help. Plenty of references to it on this site...

By being based on route it pretty much uses the same method for filtering. I think I'm looking for something that doesn't exist so I shall end my search and just use route.

https://cycling74.com/forums/osc-stream-processing-in-max

See also:
https://cycling74.com/forums/osc-stream-processing-in-max


I read through the paper (briefly). There's some nice ideas but not the one I am after. It's not a problem, I can work around it.

I read through the paper (briefly).  There's some nice ideas but not the one I am after.  It's not a problem, I can work around it.


Handling OSC messages - Is there a better approach than explicit route objects?