Not perse an issue
A select module nr of outputs is defined by the nr of arguments , it's a pity we can't change the argument of select modules as long as it respects the nr of outputs
Screenshot shows 4 single select modules , when unpacking a list we can change the argument of each select module individually
When the select module has 1> argument we can't do that anymore

@gentleclockdivider @seb-harmonik-ar made a patch that you might find useful...... https://forum.pdpatchrepo.info/topic/7997/changing-the-creation-arguments-of-sel
David.

@gentleclockdivider We can do this as an abstraction with dynamic patching, this is one of those areas where it is a little awkward but nothing too terrible. You can send a list longer than the creation arguments to the cold inlet and it will still remove those numbers, you just will not get an outlet with a bang for any numbers which extend beyond the creation list's arguments. Could be done simpler if we moved the outlets outside of the abstractions and just gave it two outlets, but it is not so bad. I suspect this can be simplified, feel like I am over-complicating things but am failing to see how. Requires iemguts which I have no idea if works with plugdata but I am only using [initbang] from iemguts and there could be another [initbang] in some other lib which plugdata supports. There is a limit to the number of outlets you can get before you will have an issue with the rightmost outlet no longer being rightmost, should be high enough for most uses though. I got lazy here and just place the [r] and [outlet] manually so the created outlets for the bangs could end up further right in the abstraction. Perhaps I will fix that later.
sels.pd

Sort of patch which really makes me wish we had some sort of math expansion in messages.

@whale-av Seems to be one of those old forum posts where the attachment links do not work, did they work for you or did you just link the thread? Can't seem to find this one anywhere else, curious as to he went about the task, guessing he tailored it to OPs needs to keep things simple which is generally a better solution unless you do it often enough that you actually require a generic solution.

@oid Strange...... they work for me.....
Here they are again..... here.zip
David.

wow 9 years.. pd-extended days. It was specific to the case but it could be easily generalized by using a different argument to [gate].
I sometimes used to do dynamic patching w/ [initbang] for multiple outlets but often it's just as easy to write an external..
These days I'd probably use [drip] and [demultiplex] from zexy instead of [list-drip] and [gate]

@oid If you don't need to dynamically create inlets or outlets I think you can just use [loadbang], no?

@seb-harmonik.ar For fixed number of i/o it seems like just sticking cascaded [select]s in an abstraction would make more sense, or am I missing something?