Communicating between patchers without using send and receive

let me say it like this, you always need send/send~/forward as soon as you have 2 patcher windows.

in certain situations it might be enough to use [v] instead, but to send data, the send object is unavoidable.

use udpsend and udprecieve for messages.
eg
udpsend 127.0.0.1 8010 (127.0.0.1 Always declares the I.P address as the host computer, 8010 is the port to send to
this then go's to
udprecieve 8010 (don't write the I.P Address as it won't work)
I use this to control Jitter from ableton live and the timing is pretty rock solid. :)

Thanks for the responses. Have either of you gents ever experienced “phantom receives” when sending messages between devices? This was happening to me a while back and I couldn't figure it out. Occasionally messages would appear at the [r] without being sent from the [s] (I set up [print]s at each to monitor them), sometimes at very odd times, when nothing was actually going on in the patcher. Here's a screen shot of one time it happened. At the top of the Max window you can see two messages that were sent, each with the Rcommands event preceded by a Scommand as expected, but at the bottom you can see a Rcommands with no Scommand. Not asking for anyone to diagnose my patcher, just wondering if you've ever had the same experience.

i think what you saw was that a disconnected connection from or to a s/r object was not yet represented in the actual patcher code.
such thing can happen from time to time, with any kind of object, though i mostly see it with audio in and out.

@andro
Using udpsend and udpreceive, is there any way to programatically check which ports are already in use when setting up the connection, so as to avoid interfering with other processes?

No, port usage is secretly managed by the OS.

In my experience there is no advantage of OSC over send/receive. Both methods have basically the same timing behaviour, ie. variable latency in the range of Live's audio buffer size.

What about using live.remote~ to send messages (to a number box in another device, say), are there any advantages as far as timing or latency there?

According to my tests the latency of live.remote~ is about twice as much as send/receive.
So it looks like the implementation uses 2 audio buffers.

Well, well. That's good to know....