Forums > MaxMSP

Which method is faster? Patch cords or send/receive pair?

Jul 09 2011 | 6:19 pm

This is bugging me for years now. I am guessing it is the same thing, but I would like to know an opinion of somebody who is more advised than the rest of us. Maybe somebody working at Cycle74? :D

I found this thread ( but it talks about M4L.

Thank you so much!

Jul 09 2011 | 7:08 pm

It looks like roughly one micro-secend per message. Probably not enough to worry about, except in pathological cases.

-- Pasted Max Patch, click to expand. --

Jul 09 2011 | 7:10 pm

test it for yourself with the patch below. for me it’s about twice as slow… 0.55 for patchcord, 1.1 for s/r pair

-- Pasted Max Patch, click to expand. --

Chris beat me to it ;)

Jul 09 2011 | 7:15 pm

OOh! Nice test!

It’s almost half the time in my case with your test! I guess I am a pathological case! :P

3.846177 vs 6.235269

I am banging/changing 8 [scale] objects at a time besides other stuff so I need faaast!

Thank you so much!!

Jul 09 2011 | 7:16 pm

Thank you both!!!

Jul 09 2011 | 7:59 pm

You’d naturally expect patch cables to be cheaper than send/receive pairs! (In fact, I’m a little surprised the difference isn’t more pronounced).

If you wanted to write code to represent "a patch cord" it would simply be "a subroutine call". In a send/receive it’s "a name look up and then a subroutine call". More, the name lookup is not obvious because of the different levels and places that a receive could be…

Jul 09 2011 | 8:48 pm

Thank you for the explanation, Tom!

Wonderful to know this besides the actual tests!

Jul 09 2011 | 9:30 pm

Thanks for the examples. I have a question MIB. I’m a bit puzzled by the fact that the [t i] objects aren’t hooked up to anything related to the timing. Does merely having them connected to the [uzi] cause [uzi] to run a different speeds?

Jul 09 2011 | 10:08 pm

@bkshepard I didn’t want a UI object slow down things since, I hope, nobody would connect an uzi to a number object in a real-life situation… I also just realized that I hooked up the wrong outlet of uzi to the [t i]. It should of course be the right outlet. Not entirely sure what you mean by "aren’t hooked up to anything related to the timing"
The timer starts when you hit the bang, uzi does its things as fast as it can, when done the timer is stopped. depending what you hook up to the uzi it will take longer or shorter…

Jul 09 2011 | 10:48 pm

Uzi does all of its work in one scheduler frame. It just needed to be hooked up to anything, for this example. It should just be the same on both tests (patchcord & send/receive)

Jul 09 2011 | 11:35 pm

Thanks MIB and Chris both! That answers my question. Sorry for the confusion in my question, I was referring to the fact that the uzi was connected to both the timer as well as to the [t i] object, but the [t i] was not subsequently hooked up to anything else.

Dec 10 2011 | 6:20 am

For comparison, I added a pvar version which is slightly slower than s/r.

-- Pasted Max Patch, click to expand. --

Mar 30 2014 | 12:50 pm

This threads been idle for a while, but I was surprised by Jadie’s finding about pvar. I think the test in that patch is not ideal because there is an unnecessary intermediate [numbox]. With pvar you can go directly to the final numbox, and when you do that the pvar result is slightly faster than the s/r result.

I got curious and tried a few other options with the following results. Results ordered from fastest to slowest.

cable – 3.1
cable (with intermediate ‘thru’ object) – 3.4
pvar – 4.5
send / receive – 5.0
pattrforward (with no extraneous cables) – 7.9
pattrforward – 8.2
pattr (bound, with no extraneous cables) – 17.5
pattr (bound) – 19.7

…and yet I use bound pattr’s a lot out of convenience because I rarely need data throughput to be so fast.

— Pasted Max Patch, click to expand. —
Mar 31 2014 | 5:20 am

pvar and s/r have in common that both are attaching a name to the data sent.

whereas pvar creates a namespace, i think s/r is doing something very very similar to what [prepend] and [route] are doing to a message.

Mar 31 2014 | 5:38 am


  1. max5vsmax6


Mar 31 2014 | 10:17 am


this is why i use max 4.

would love to make you jealous with my efficiency, but i dont have [cputimer]. :D

Mar 31 2014 | 12:32 pm

bah ! just need a [gen] for control-rate data and voilà…

Viewing 17 posts - 1 through 17 (of 17 total)

Forums > MaxMSP