|
tom tlalim wrote: would it be hard to write a primitive OSCreposnder that behaves like dumpOSCActually, all the info we have been getting points to the fact that none ot the other clients mentioned can receive messages from SCserver, since their sending ports are either random, or are never the same as their receiving ports. This means that SCServer is _not_ independent of SClang. If it doesn't slow SCserver down, I would suggest that it gets a mechanism for being told which addresses and ports to respond to (for exampl like when I send ("/notify",1 ), it could be changed to ("/notify",1, port number ). With other reponders, such as the "c_getn" "c_setn" pair, it will be more awkward, since you can't add an argument here without breaking people's code. Perhaps you could "regsiter" for getting messages, as with "/notify", even for bus-polling (or only if you need to change th receiving port). If you could determin th port and address in messages themselves, then you could get SC server to respond to a differen client than the one who sent the message. That would be very useful. Otherwise, the only way out is t use SClang as a relay. That brings us back to programming strategies. jostM |