send from tapin~?
use of send and receive objects to link from tapin to tapout objects
From time to time over two decades I have used the send object (not send~) to connect one tapin~ object to multiple tapout~ objects in multiple sub patches. This seemed to most efficient use of memory, rather than duplicating a tapin~ with identical contents in every sub patch. But I was always told this is "wrong", even though it has always worked right up to current rev. 9.1.4. Claude says "Cycling 74 developers have been aware of this usage pattern in the community for a long time. If it were going to break catastrophically it likely would have by now across major version transitions. That said, "stable in practice" is not the same as "guaranteed."" -- and suggests I ask the forum if this implementation is "stable or deprecated". Advice?
some random thoughts.
1. if you try various combinations using that from inside poly~ (i.e. across levels), or script-deleting and script-creating certain connection around that, you will find some situations where it stops working.
it is not so untypical for echo effects that they require upsampling and it not untypical for max users that they develop habits and forget about them.
2. it is completly "right" to connect multiple tapouts to a single tapin. i just don t see why you would use 10 s/r pairs instead of 10 connections? it is more work and less effective.
3. the most CPU effective way to read multiple taps from the same tapin is to use multiple arguments to the same tapout. so this this is first thing one should do. (of course i am aware that it is limited to 10 and not a contradiction to require parallel instances in addition.)
4. under circumstances it is also more CPU effective to put multiple parallel instances of tapout into a poly~ (for example because you could turn off the processing for currently unused ones.) note my comment about the use of s/r in conjunction with poly~ though...
Many thanks. Your option 2 triggered a "duh!" moment: in the current instance hard wiring to several sub patches is but a minor irritation (and admission of defeat). This is why I've taught Neanderthal hardware hacking rather than Max/MSP, despite too many years of coding experience .
i see, the "across levels" problem is surely a good excuse since it would not work otherwise.
of course one can always question and change that design when neccessary.