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...
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?
@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...
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.
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.