On 11 Dec 2013, at 01:44, James Harkins <jamshark70@xxxxxxxxx> wrote:
It may be "rare" to have multiple responders for the same message path, but I don't think you can predict that either. A reasonable OOP design for the above case would be an object that handles incoming traffic from one controller (one IP address), each adding its own OSCFunc. In that case, you would have a FunctionList being evaluated thousands of times a second. (You could optimize that by one OSC receiver object that forwards messages to other objects based on the integer representation of the IP address.)
I completely agree about the principle, but again in cases where that really matters, you could use a custom dispatcher which filters first by IP address.
The *most* important thing is that it should work. Then we can think about as fast as possible, prioritising common cases where reasonable, perhaps trading that off against other considerations such as simplicity, maintainability, flexibility, etc.
Bear in mind that OSCFunc/def already provide considerable speed improvements over the old responders. IIRC 10-20 times faster in my initial tests, and an order of magnitude higher with large numbers of responders. So FWIW even in those (yes, pretty rare) cases where a FunctionList would be used, it's still probably faster than with the TouchOSC ensembles of yore.