Feedback between gen subpatches

Eric Sheffield's icon

Hello.
I'm trying to create a modular delay network setup using gen subpatches with feedback loops between the various modules.
Obviously, like the regular Max tapin~ and tapout~ objects, a minimum of a single sample delay is required for feedback.
I've noticed that, even if the necessary delays are present within the gen subpatches, Max won't allow feedback connections between the ins and outs of the subpatches unless an additional external delay (e.g. the history object) is used.
The first example I've included works just fine. What I was hoping to do is essentially the same thing but without the history object, mostly just because that would simplify the modular nature of the subpatches. The delays inside the subpatches should make the history object redundant i.e. if I create the exact same setup outside of the subpatches (like in the second example), it works just fine without the extra history object.
Is there any way to do this the cleaner/simpler way as in the first example?

P.S. I also tried this with send and receive objects inside the gen subpatches to no avail.

Max Patch
Copy patch and select New From Clipboard in Max.

Max Patch
Copy patch and select New From Clipboard in Max.

Roman Thilenius's icon

the rules for making feedback loops on msp level do not change when the parts are made of gen subpatchers.

Eric Sheffield's icon

But feedback loops can be accomplished using subpatches in regular MSP land without delay type objects outside the subpatches?

Max Patch
Copy patch and select New From Clipboard in Max.

Eric Sheffield's icon

Thanks all for the replies.
Although I’m fairly new to gen, I’ve been using Max for a long time and understand that tapin~/tapout~ are a unique case.
My plan is to stay within a single instance of gen~ as MC Wrappin suggested. What I’m confused by is that I can make a feedback loop between two delays in gen~ without a problem (the second example I posted), but as soon as I put those delays inside two gen sub patches within gen~, they can no longer be connected to each other (unless there is an additional history object between the subpatches, as in the first example I posted) .
This same behavior between pairs of tapin~/tapout~ in sub patches within a Max patch still works fine i.e. putting tapin~/tapout~ into subpatches does not break the ability to create feedback loops.

Roman Thilenius's icon


actually tapout just inserts the one-vector-delay automatically since a few years. but it is still there. :)

i think in max 6 there was some weird bug with it (or its delay time arguments) but nowadays it just works out of the box.


but as soon as I put those delays inside two gen sub patches within gen~

confusing stuff like that it why i still hesitate to use it.

testcase's icon

for this to work, gen would need to 'know' that you have a delay in the gen subpatch and I don't think it does that kind of analysis. If you tried to do this in a codebox you could see the problem. If you had a function delay1 and another delay2 you would not be able to write to the delay lines in the the functions so you would need a history object. Anyway, I would suggest you need to organize this differently.

Eric Sheffield's icon

Thanks again to everyone for the responses. I can certainly work around this, just wanted to make sure there wasn't something I was doing wrong or that I could change to make it work the way I wanted.