Hi,
I have an abstraction which insert inlets at creation but the connection is lost when I close/reload the main patch. How can I fix this?

fc_controler.pd

Note:

• The inlet/outlet creation is done by parsing the args: each arg before the | character creates an inlet and each arg after | creates an outlet. E.g. fc_controler f f | p r f has 2 inlets and 3 outlets.
• This abstraction is a part of my FCPD project, fc_process is a part of a client/server abstraction which communicates with FreeCAD but it doesn't interfere with the problem. You can replace it by whatever you want.

@FFW Loadbangs happen after the patch is fully loaded, so after all connections have been made/attempted to be made between all the objects/abstractions in the patch, so those dynamically created iolets don't exist yet and the connections fail. Replacing the [loadbang] with [iemguts/initbang] will cause the iolets to be created when the abstraction is loaded but before it has been connected to the other objects in the patch so you connections to those iolets will not fail.

@FFW You can dynamically re-create the connections, but of course you need to know the object numbers of the objects in the main patch that you want to connect to the inlet/outlet.
I have had to do this building patchable input /output cords in a matrix..... matrix~.zip
Everything inside [matrix~] is created according to its arguments and then the test patch connects to the abstraction.
The test (matrix-test~.pd) works in extended.... but strangely the object numbers have changed when opened in vanilla. Inside [matrix~] everything creates correctly in both versions.
It should create this....... which demonstrates the principle...

It is best to recreate your main patch with the objects you will want to connect being the first objects created... and then copy back the rest of the patch and connect those objects.
Then if you modify the patch later you will not change those object numbers and break the dynamic cord creation.
David.

@whale-av said:

but strangely

You are experiencing the same issue as @FFW and using [initbang] for the iolet creation will solve it. I believe your method will only work with extended but it might also work with very old versions of vanilla.

@oid I can correct the object numbers in the test patch for vanilla and then it loads correctly, so I don't think it is the same problem. [matrix~] also creates correctly with the [loadbang] in vanilla, but with object numbers wrong...... and I can correct that.
I will try with [initbang] instead when I get time... thank you for the idea..... but I am not convinced for now that object numbers are wrong because of [loadbang] and the ordering will be changed again when I try.... so a lot of work.
If [loadbang] in later vanilla is sorted after all other objects regardless of its creation order then that would explain the change of object numbers..... but that would be in the "breaks old patches" category... and unusual especially for a foundational object. But only for dynamic patching, and we were warned that it is unsupported.

So I will first check whether moving [loadbang] to the end of the object list solves the problem.... an easier fix.

You are correct that this patch worked correctly in older vanilla...... it was built to create a replacement for [matrix~] during the 32/64 changeover while the external was unavailable, and worked at the time.
David.

@whale-av What object numbers are wrong for you? They are all correct for me, only thing wrong that I see is an outlet number, it tries to connect the [print] to the non-existent outlet 2. All you need to do to fix it is change the [loadbang] into an [initbang] and then remove the [delay] and [pipe]s, the [delay] causes the iolets to be created after the initialization phase and after the load phase as well most likely. Same issue, just with a few extra quirks thrown in.
matrix~.pd
I also replaced the [metro 1]s with [until]s, we no longer need all those tricks. The [print] still does not connect, I am not sure what that is supposed to connect to, guessing there is an outlet #2 being created somewhere in the patch that I did not see? Guessing this also makes it not work with extended.

Thank you @oid it now works as expected. I remembered this early-bang object existed but I couldn't find it 🙄.

@whale-av I don't know where the object can be used, it an object aim to be used by a hypothetical end-user to create GUI or puredata logic to control 3D model.