Stephane Morisse

Was working on the max tutorial about remote messaging this morning and wondered if anyone knows if the latency induced by send and receive also affects the other techniques (forward, message box, value...) ?

send-and-receive-latency-with-other-remote-messaging-techniques

I know that plugsend~ has very little latency, which is also stable.

that being said plugsend~receive~ isn't supported and might cause some issues.

I know that plugsend~ has very little latency, which is also stable.
that being said plugsend~receive~ isn't supported and might cause some issues.


As I understand it, using ';' or 'forward' are just variants of send/receive inducing the same latency.

But 'value' is different. I guess that storing and retrieving a value basically happens without latency.

However in contrast to send/receive, the receiver must actively bang the object to read its value.

And I don't know exactly how much "safety distance" is necessary between write and read.

But 'value' is different. I guess that storing and retrieving a value basically happens without latency.
However in contrast to send/receive, the receiver must actively bang the object to read its value.
And I don't know exactly how much "safety distance" is necessary between write and read.


so by using forward I will introduce the same unpredictable latency

so by using forward I will introduce the same unpredictable latency
as in send?


To Broc : I imagined the same thing about ';'and 'forward'. I don't know how to design a protocol to measure latency but I sure would like to know if that is also the case with 'value'. Maybe we could have a word about this from Cycling or Ableton ?

we definitely need some clarification on this.

forward seems to behave differently then send.

while send resulted in an un-stable latency, forward seems to be fairly stable. (even though the values are being forwarded from an audio track to a midi track, so I assume they're on different threads)

forward and value might be those sought after objects to

(stuff like audio to midi and multi-channel outputs.)

we definitely need some clarification on this.
forward seems to behave differently then send.
while send resulted in an un-stable latency, forward seems to be fairly stable. (even though the values are being forwarded from an audio track to a midi track, so I assume they're on different threads)
forward and value might be those sought after objects to
expend the "connectablity" of live.
(stuff like audio to midi and multi-channel outputs.)


Just send a bang to [cpuclock] at relevant points, print the result and look at the time difference.

Regarding latency measurement:
Just send a bang to [cpuclock] at relevant points, print the result and look at the time difference.


send and receive latency with other remote messaging techniques ?