Effcient programming with OSC protocol?
I have a program sending commands via OSC to a max/msp patch.
I need to make a decision about how I structure max to work with the software sending OSC but I am not sure if one of the methods is a big "no-no" (e.g. overly processor intensive)
Option 1:
The host program sending OSC commands sends commands out on 30 different ports. Different sections of the max patch listen to the different ports.
Option 2:
The large amount of commands are all sent on one port only but the max patch routes them to the different sections. (e.g. use CNMAT's OSC_Route object)
In option 1 I am not sure if it is a bad idea to use more than one port as this would be the ideal solution for the particular problem I am working on. Any overhead I should be considering?
thanks!
Hi Daniel,
I think using different ports would increase the chance of error quite
dramatically.
What I do is simply prepend a number to the OSC-string, and then use
regular route->send objects, and go from there.
Andreas.
Danjel van Tijn skrev:
> I have a program sending commands via OSC to a max/msp patch.
>
> I need to make a decision about how I structure max to work with the software sending OSC but I am not sure if one of the methods is a big "no-no" (e.g. overly processor intensive)
>
> Option 1:
> The host program sending OSC commands sends commands out on 30 different ports. Different sections of the max patch listen to the different ports.
>
> Option 2:
> The large amount of commands are all sent on one port only but the max patch routes them to the different sections. (e.g. use CNMAT's OSC_Route object)
>
>
> In option 1 I am not sure if it is a bad idea to use more than one port as this would be the ideal solution for the particular problem I am working on. Any overhead I should be considering?
>
>
> thanks!
>
>
>
>
>
> .
>
>
So in my case I am using a program called VDMX to send data.
So if I structure each OSC message like this
/VDMX/1/command1/ data
/VDMX/2/command2/ data
/VDMX/2/command3/ data
I can just use the /1/ or /2/ and OSC-Route instead of listening to lot's of different ports.
thanks for the tip!