Forums MaxMSP

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


ygreq

ygreq
Jul 9, 2011 at 6:19pm

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

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 (http://cycling74.com/forums/topic.php?id=24190) but it talks about M4L.

Thank you so much!
ygreq

#57940

Chris Muir

Chris Muir
Jul 9, 2011 at 7:08pm

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. –
#207907

MIB

MIB
Jul 9, 2011 at 7:10pm

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 ;)

#207908

ygreq

ygreq
Jul 9, 2011 at 7:15pm

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!!

#207909

ygreq

ygreq
Jul 9, 2011 at 7:16pm

Thank you both!!!

#207910

tom@swirly.com

tom@swirly.com
Jul 9, 2011 at 7:59pm

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…

#207911

ygreq

ygreq
Jul 9, 2011 at 8:48pm

Thank you for the explanation, Tom!

Wonderful to know this besides the actual tests!

#207912

bkshepard

bkshepard
Jul 9, 2011 at 9:30pm

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?

#207913

MIB

MIB
Jul 9, 2011 at 10:08pm

@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…

#207914

Chris Muir

Chris Muir
Jul 9, 2011 at 10:48pm

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)

#207915

bkshepard

bkshepard
Jul 9, 2011 at 11:35pm

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.

#207916

Jadie Rage

Jadie Rage
Dec 10, 2011 at 6:20am

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

– Pasted Max Patch, click to expand. –
#207917

You must be logged in to reply to this topic.

Forums MaxMSP