Help! "tapout~: connecting tapin~ from outside dsp chain is not supported and may not function"
I wish I were smart enough to parse this message.
I have a tapin~ connected to a tapout~ inside a sub-patcher. No problem there, I assume? The new input and fed-back input come from the outer (enclosing?) patch.
(1). What exactly does the error message mean and what arrangements of objects would cause it to occur?
This error shows up (I think) when I inadvertently run feedback straight into a [delay~], which the object doesn't seem to accommodate, unlike tapin~. But I've first sent the feedback audio into a mc.send~/receive~ pair, which—in the past—has allowed me to feed signals back into themselves, as in, e.g., a sample-and-hold partially sampling itself for controlled randomness.
2). Should this work with [delay~]?
I'm trying to build a delay effect wherein the user can switch between pitch-shifting with modulation (tapin~) and discrete cross-fading with modulation (delay~). I assume I'm not imagining something impossible?
3). Reasonable or impossible within Max/MSP?
Thanks for your wisdom.
yes, reasonable within Max/MSP, but tapin~ and tapout~ have a special connection between them...
i think i got the same error you got by doing this:
the connection between tapin~ and its associated tapout~ is a way to get the associated objects to refer to a specific area of memory in the RAM of your computer, delay~ will have its own memory, so it's likely the memory access of delay~ is confusing the memory-access connection between tapin~ and tapout~...
if you can stick to this type of patch routing, it can work better:
without seeing the patch you tried, though, i can only guess as to what you mean by this:
error shows up (I think) when I inadvertently run feedback straight into a [delay~]
edit-
a couple more screenshots to show that it is whenever you put objects that hold a named memory-space, within a feedback path that then feeds back into tapout~ as opposed to the tapin~ it is connected to:
even just a regular/default gen~ patcher(because i knew it holds its own named memory space), will confuse the feedback path as shown above...
but not if you attach it via feedback path to the properly associated tapin~:
so it's only signal objects that have a named memory space associated with them, placed within the feedback path(any form of signal-processing object which doesn't have a named memory space, such as '*', by themselves, will be fine).
hope it helps!
in opposite to poly patchers, i´ve never found any issues when doing that with normal subpatchers, but that does not mean they can not exist.
one thing is sure: it is not as completely impossible as with grab. :)