equivalent of poly~ for gen (multiplying gen subpatches)

It's actually not so simple, because when you copy a gen subpatch, you have to connect all the params with setparams to each one. Also, it does not do multithreading. Unless you are really serious, you probably want to stick with poly!

Thanks for your answer, Ernest! Sure, I wouldn't expect this to do multi-tasking, neither dynamic voice allocation.
Ideally, such a hypothetical multigen would generate the code in the subpatcher n times, and somehow expose params with indices or settable as a list, and make the current instance number accessible as a variable inside each instance.

I did read up on gen~ now, and find the lack of arguments for subpatchers and their substitution (#1) and generation and setting of the label for send/receive a real hindrance for this kind of genericity.

As of Max 7.3.1, you *can* add arguments to subpatchers (and abstractions) in gen~:

Oh, and this also works on the gen~ itself:

Another way of repeating sections is to define them as functions in genexpr and then make multiple calls to them.

(But note: this won't work if placed within a for loop, for complicated reasons)

A while back I shared something using gendsp based on a single definition / multiple instantiation. It is not the easiest or most intuitive approach, but actually I use it quite regularly.

https://cycling74.com/forums/granular-in-gen/

Thanks Graham, that's totally awesome and perfectly on time! I must have missed it in the doc or release notes.
And, yes, the codebox eases that kind of reuse a bit. The dream now would be to be able to address in/out vars as an array like so

for (i = 0; i < numoutlets; i += 1)
  out[i] = subprocess(i, ...);

or what if outlets would be mirrored as a Data array?:

 
  out.poke(i, subprocess(i, ...));

Yes, Data is the way to go for this (and yes, I wish it too).

The dream of using a for loop to do this is unfortunately not likely to come true.

The main problem is that subprocess() can be stateful, by having History objects or other stateful operators such as phasor(), cycle(), etc, which require memory allocation up front to support each iteration distinctly. (Otherwise, all your filters and oscillators etc. will be the same one). The generic form of a for() or while() loop is unpredictable how many iterations are involved, and thus how much memory needs to be allocated. We don't want to allocate memory in the audio loop, especially if suddenly many hundreds of iterations are invoked. Only in the specific case of a constant, as in "for(i=0; i

BTW My own approach to solving this kind of problem is to use another language generate repetitive genexpr code.