Hey all

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.

@whale-av I'll take a look into clone. That might help me out. I basically have a bunch of control objects that all use the same abstraction for sending/receiving to a central patch storage DB. I create these instances through dynamic patching as well as the slider objects themselves. Basically just did this so I didn't need to individually create each slider for say, a 64 step sequencer. Obviously the downside to this is you wind up with lots of objects very quickly and a need to connect them in a variety of ways.

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.

@lo94 [clone] might not work for you if you want to see the sliders, as you cannot see all the instances at once....
When you dynamically create your 50+ instances of the abstraction you can add $1 using a counter to pack the value for each, and place them neatly on the patch.....
e.g. below.
Beware........ adding $0 as the first argument for the abstraction adds the $0 value of the mother patch as $1 for the abstraction, not the unique ID of the created abstraction.
David.

creates.....

@whale-av Ah okay. This seems useful. I will likely try to see if I can rig something up to make dynamic patching easier in the coming weeks. Do you happen to know if PD has any sort of event handling capabilities that allow you to send messages to currently selected objects? If so, I can't imagine rigging something up would be tremendously complicated

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

@lo94 I think send the message to all, and use a [spigot] so that only selected items actually receive the message.
You can use another global message to turn off previously selected items (or not) when you select a new one like this......
solo_select.zip
David.

@whale-av Ahh okay, this is a clever solution. I hadn't thought of using spigot in regards to a global receiver like that. Definitely need to implement this in some of my abstractions.

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.

[select 0 1 2 3 ...] for drum machine sequencing always reminds me of Jed code ... there's really got to be a better way.

hjh

@ddw_music I'm sure there is haha. I just started PD about a week ago and am definitely more of a traditional programmer. I'm much less adept when it comes to visual programming. Even when I do use visual programming in something like Unity/Unreal it winds up being more of a triggering state machine than anything else.

@lo94 looking at all those connections I thought I would mention the built in intelligent patching.
where you can select all the nodes you want to connect, proceed to connect the first wire but hold the mouse button down, then tap the the shift key.. voila! all connected.
one to many, many to many, many to one

@Balwyn .... thank... you... so... much lol
I had no idea this was a thing

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

@lo94 said:

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.

@lo94 just noticed that where I have put $2 below it should be $3 as you have two arguments already

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.