Frustration got me to throw together a few abstractions today to make easier to deal with [trigger], [pack], and [unpack], it allows you to add or delete inlets anywhere, not just at the end.

But as I am getting ready to upload them I am finding myself stuck on the final details, mainly how to deal with removed outlets/inlets. Should I just delete the connection to that outlet/inlet or should I shift all subsequent connections too accommodate the decreased number or add a shift operator like < or > to specify which direction you shift the cables? I sort of think just let simple logic win, connection stays connected to outlet/inlet # even if you delete it, if you delete outlet 3 the connections too outlet three will now be connected the old outlet 4 since it is now #3 and the old connections to #4 will be connected as well to the new #3, let the user decide after the fact since shift-click cable swapping and deleting is easy enough and adding in shift operators could just confuse things since stacking them could get confusing quickly?

I also made abstractions for [route] and [select], as of now they just keep the right inlet connected instead of shifting that connection to the left by how ever many new outlets are added. I would like to add the ability to insert and delete outlets to these since it can help to keep patches neater without a whole lot of cable swapping but I can not think of a reasonable way to signify removing or adding an outlet since anything could be a valid argument for [route] and [select]. Open to suggestions here, perhaps just stick with the caps convention of the other objects and accept that it will not work for all situations?

What is the consensus? Is there one?

Also, has no one ever made these? They were simple enough and seem obvious, but I can not find such a thing. I really feel like I must be reinventing the wheel.

@oid Sounds like fun....
As all 3 objects can contain different functions...... [t b a f] [pack s f] I think you have to make the connections good or they will no longer work as expected.
But maybe I am not understanding your project.
@LiamG posted this in the distant past...... connector.zip although I cannot find his thread.
And also this interesting solution for a dynamic [pack] https://forum.pdpatchrepo.info/topic/9763/dynamic-pack
David.

@whale-av said:

As all 3 objects can contain different functions.

I knew I was forgetting something obvious. Deleting the connection with the inlet/outlet is the only sane thing here since letting the connection stay will often cause it to be connected to the wrong type, and this is also expected behavior. Thanks for pointing me back in the direction of reality.

@oid said:

Frustration got me to throw together a few abstractions today to make easier to deal with [trigger], [pack], and [unpack], it allows you to add or delete inlets anywhere, not just at the end.

This ranks very very high on my list of annoyances with Pd: that inserting or deleting from program logic in [t] destroys connections, making it error prone to replace them.

I'd even suggest logging this as a feature request to include in vanilla [t] and bypass the abstraction.

hjh

@ddw_music said:

I'd even suggest logging this as a feature request to include in vanilla [t] and bypass the abstraction.

I was going to do that as soon as I finish them up since it gives them an actual example of how they work and will not fall victim to my inability to communicate with programmers. They should be finished up and uploaded tonight, just need to give them a once over with fresh eyes to make sure I did not miss anything obvious.

@ddw_music Seems there is an undocumented bit of intelligent patching here that at least works for [trigger], ctrl-t on a [trigger] allows you to expand fanned out connections, remove unused connections and insert an inlet at the start. A gif from umlaeute to demonstrate.

I requested this use of ctrl-t to be expanded too work with [pack] and [unpack] if my suggested solution is not implemented—which I suspect is unlikely—but we might get ctrl-t and even if we do not my abstractions are there and seem to working quite well now minus one minor bug which I noticed today and will fix tonight.