Yesterday I created an abstract which has a variable number of outlets, just like the common "trigger" or "unpack" objects. I dynamically patched this by sending a [obj x y outlet( message to the pd file. This works, however I soon discovered that all connections made from those outlets on the parent patch are broken when the parent is saved and re-loaded. This makes sense because the outlets are created via loadbang, but in order for loadbang to work, all connections must be set already. In my patch, the outlets are re-created every time the parent is opened, but only after the connection commands are sent. This poses a big problem for my abstraction, since I'd like to be able to save it and depend on the connections coming back just like any other object.

I assume normal objects such as [trigger] are coded rather than patched, which would allow for outlets to be set variably. Without resorting to coding, can anyone think of any way to solve this problem of broken outlets?

But why create your [outlet]s after the connection commands have been fired? All you need to do is create any objects you need first, and then connect them.
I also use this variable inlets outlets thing in abstractions, and the only hassle (which can be quite a hassle) is when you patch your abstraction, to keep track of the objects' indexes.

Can you post your abstraction, or part of it?

Sure thing--here's the patch.

trigger happy.zip

Open up the help file and you'll see that the connections from the [th] object are broken. You can add them in again and the object will work, but if you save the patch and re-open it, they are gone again. This is because the outlets are created by a loadbang message, which only fires after the parent patch is open and all connections are set.

I think you need [initbang] which is included in extended, but I can't find which library it belongs to. I wanted to use it in vanilla, but didn't find the binary, so I tried some other solution (for a problem, not similar to yours).
[initbang] fires before the connections are made, or something like this... plus, it's local to each abstraction instance.

Initbang is great! For me it comes up immediately, without having to load a special library.

But now I have a new problem: initbang doesn't seem to work with [iembuts/canvasargs]. It seems that the canvasargs object hasn't properly loaded by the time initbang fires. I can load canvas arguments the old fashioned way, using [any $1], etc., but then the total number of creation arguments will be limited. Is anyone aware of another way to load creation arguments?

Hello Liam,
I am trying to follow you, but having trouble as I cannot see what you are doing. I think I might understand.
You are trying to make connections between abstractions that you have placed on a canvas, and the number of abstractions is variable..

If instead you create 2 canvases on that new canvas......... [pd canvas_outlet_objects] and [pd canvas_inlet_objects] then you can connect these two larger objects by their inlet and outlet numbers.

That way it is much easier to keep track of objects (for the connection addressing) as there are only two (0 and 1) and their inlets and outlets correspond to the order in which the abstractions were added..

Of course you can have more ...... [pd canvas_outlet_object2] etc. and you can "nest" more canvases.

The picture is large, but I am very bad at explaining myself. The "input_patch" and "insert_patch" are populated by "pins" which are themselves abstractions. The pins are created and placed on their canvases depending upon the number of objects that were created within the canvases "pd soundcard_inputs" etc.........

The abstractions contained within [pd soundcard_inputs] and the other objects on that canvas are all complex, built with many other creation arguments, and using [send] and [receive] messaging to talk to other created abstractions. For example, the objects within [pd_mixer_inputs] receive audio from simple objects within [pd input_inserts]as well. In other words, the objects within [pd mixer_inputs] have 2 inlets, and they appear at [pd mixer_inputs] and [pd input_inserts] respectively, and are linked automatically at creation.

Obviously the created objects need either an inlet or an outlet
I had a similar problem (timing issues) to you.... so the pins are activated by a message once the "pin patch" is populated.

David.

This isn't quite what I'm trying to do. (You're right, it is remarkably hard to describe these things!)

All I need to do is create an abstraction which has a variable number of outlets. The number of outlets is defined by the number of creation arguments, just like a [trigger], which can be as big as you want it.

My original patch looked something like this:

This worked for creating the outlets, but fails when you save and re-open the patch (this is what my post was originally about). Replacing [loadbang] with [initbang] should solve the problem of broken inlets, as Alexandros identified, but it doesn't in this case, because it doesn't work with the [canvasargs] object. Try this construction:

and when you load, you will get nothing, presumably because [initbang] fires before [canvasargs] is fully initialized.

So I am wondering if there is any other way to access the creation arguments.

I could of course do this:

But then the total number of outlets will be limited by the number of [any] objects I create. I could just make fifty of them and probably be safe, but this doesn't seem very elegant. So I am wondering if there is another alternative.

Thanks for working on this!

for saving, [closebang] might be helpful...