Send/receive VS connections

I’m wondering if there any differences between using R and S nodes instead of wire conexions??..In terms of ressources, etc.For exemple sometimes you need to connect the node via 2 or more IOboxes when the patch is complicated…so is there any difference between a wire passing through multiple IOboxes until it reaches the destination or using send?

I was wandering the same and did some tests before.


CPU requirement of any node depends of the output spread size i.e. number of slices.

So it doesn’t matter if for example GetSlice is taking 100 slices from 200 size spread or 20.000 size spread. Output size is the same and CPU load is almost the same.

S and R nodes don’t follow this rule and they take more or less the same CPU attention no matter the spread size.

I tend to use them very much in development faze and bypass them in final patch.

IOBoxes take some CPU attention only when displayed on screen. Number of displayed slices also matters.

So basicaly, you can have 100 of IOBoxes interconnected in your subpatch, and if the subpatch is not displayed in its window - IOBoxes that are not named (to become subpatch pins) are more or less sleeping.

This is just my observation and not official information, of course.

‘This is just my observation and not official information, of course’ don’t be shy…Professional as always…
Well received 5/5 Majortom!

only practical issues:
the visual control over the dataflow may be better with hardlinks.
especially with patches you receive from another user.

then there was that little bug that you sometimes have to set the sendstring once again after reloading the patch.

using S nodes with the same sendstring is not possible (for years on my wishlist) so beware of using S-nodes in modules you need in more than one instances.

i like S&R-nodes very much for communicating modules!

Hi there!
Nothing to do with S and R node but even still a perf issue.I’ve noticed that docking(click+alt+drag) subpatches and modules, which is good for fast and clear prototyping, eats more ressources than hiding all of them inside the root patch…so my advice for displaying patches(ofc if u’re lookin’ for better perfs) would be showing only the root rather than docking…


sometimes i wondered…

docking is evil?

hope that west reads this. rico’s has about 50 docked patches i think.

right, docking only windows-like “hides” the patches, but they are still in memory which makes them popup in no time though when you click them. so for sparing resources you should still vvvv-like hide patches (alt+3)

How cool it would be to have an option to “replace” all the S/R nodes to wires, like to activate a “live mode” for better performance. I think this would only work in root level, not with subpatches…

should be possible to patch via PatchAlias/GetPatch/SetPatch.

well, in root patch…

i just had the problem that a pc which is supposed to play a full hd video with 50fps and to do some more itchy things simultaneous, receiving XML scene descriptions (about 14,000 characters) via TCP more than occassionally dropped scenes while other pc’s received them.

seems that in this case IOBox (String) has performance needs you only notice in high-performance-critical situations like these.
after using S (String) and R (String) for the only reason to avoid the use of IOBox (String) the problem was gone.

would be interesting to know if a “Show String” config-pin (orthogonal to “Show Value”, “Show Slider” of IOBox (Value) ) would help here.

and also if an IOBox (Value) is faster if both “Show Value”, “Show Slider” are disabled.

please provide some of your deep knowledge…