Was curious if anybody had come up with a solution for quickly attaching many nodes of the same abstraction type to a single inlet on another node. I've been trying to find out if PD has any way to read information on the currently selected nodes but it doesn't seem there is a way.

Usually it isn't too big of a deal but I'm not running into instances where I have 50+ nodes that I need to connect to the same cold inlet for storing values in a sequencer. Doing these by hand for the smaller portions was tedious but not really a major issue. Now though it is becoming both time consuming as well as the high quantity of connections creating more room for manual error (and with the giant wire nest it becomes next to impossible to actually see what's going on).

I was looking at the format of the connections in a text editor and

Any suggestions or existing solutions I am unaware of would be greatly appreciated. Cheers

EDIT: So I see how things are created, essentially just order of creation. With VIM was easy to connect these objects but still somewhat tedious. Is there any way to query objects as to what that ID is? If not, and it's essentially just line count within the canvas it exists within, maybe I'll rig up a simple PD object that will fetch and output this ID. I feel like if you were able to readily fetch this ID, then something like dynamically connecting objects would be exponentially easier. I have a severe disdain for tedious repetitive tasks and will follow up if I can come up with a decent tool for doing this. It's too bad there isn't at least a basic unique ID per object as that would make this monumentally more simple.

The basic unique ID of a window is $0 ..... but using it is only really useful within an abstraction. Communicating using $0 is not easy outside that abstraction. $1 $2 etc. are better for that as the value is known and will not change when reloading the patch as with $0.

https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4

But I made too many assumptions about your post.
Sends and receives for nodes could be switched on and off with spigots controlled from your master patch I suppose.
The use of $ arguments still stands though.
Any object (not message box) can use the arguments of the abstraction so e.g. [send data$1], [delay $2]... etc.
or......

Will send tagged data to the receiving node, tagged with the $1 Id of the sending node for your central storage system.

For getting the unique ID of a window (and any sub-patches within).....

The same can be done for $1 $2 etc., but also you will see the arguments that they have been given in their window name.

When you are creating a lot of abstractions (of the same abstraction?... 50+!!) you should consider using [clone].
It is not straightforward on first contact, but once you get your head around the concept it saves a lot of time building a patch.

The unique ID of objects (creation number) is really only required for dynamic patching...... but that is another subject.
David.

I'm reading about clone but does this sound like something that clone could potentially simplify?

Thank you for the reference, I'll have to experiment with that a bit tomorrow so see what its capabilities/limitations are. Much appreciated as always!

EDIT: I included an image of what I've been doing so far. The [control-guts] abstraction is created in an editor I threw together, along with its associated GUI object which is initialized according to the values passed in from my editor. Obviously, all use cases don't match (for instance, on this drum machine the trigger/probability sliders for each step will be used differently than the toggles which set the last step). Between this and manually editing the textfiles with VIM, I've been able to get pretty decent efficiency, but being I'm new to PureData I wonder if there is a way to handle such things more efficiently.

EDIT: Ah yeah I'm aware of the $0 adding the parent patch. That was my intention, so it can communicate with the parent patches $0 send/receive events

Although this seems to limit you to custom abstractions. I was wondering if PD actually keeps track of the currently selected objects when in edit mode, that somehow we might be able to peek behind the curtain at. I'm assuming that PD must have this information stored somewhere/somehow, it's more a matter of if it's made accessible somehow.

hjh

Doesn't help so much with [select] but definitely does with patching many controls into a float's cold inlet and such

Do you happen to know if PD has any sort of event handling capabilities that allow you to send messages to currently selected objects?

Here is a quicky showing how to work this with iemguts, also needs [list-drip] from list-abs or the @ingox improved one from the abstractions forum. Select one of the [selectsend] objects and control click the bang, or select both. If you edit the patch you have to send a bang to [s refresh] to update the abstractions index, but that can be automated easily enough and it is a bit rough around the edges overall, just meant to show the concept. The iemguts help files should help you refine it to suit your needs.

sendselect.pd
sendselect-help.pd

Edit: It seems I completely missed the point.

Just back home and admiring the giant spirograph screenshot you posted above.
As [select 0 1 2 3 etc.] is receiving numbers you can simply do away with it and send those numbers to all the [control] abstractions...... [send whatever]
You will move the [select] function into the abstraction itself.

Create your abstractions as for example [control-guts DrumSeq#_ClapProb_hsl1 $0 arg] where "arg" is 0 to 15 for the 16 abstractions.
Then, in the abstraction, instead of the inlet (or alongside) put.....

Then each abstraction produces the bang on the left outlet of [sel $2] only when it receives its number.
My "cold inlet" in the screenshot is just to show that you will connect the left outlet of [select $2] to the same place as your current inlet.
David.
Ps..... now might be a good time to change the data to 1-16 so that $2 can match the "hsl" number (1-16) and so avoid later confusion..... a [+1] before [send whatever] will suffice.
Of course "whatever" is also just for demo purposes.