@oid my bad, I wasn't clear enough.
I've done what I mind:

makeExpandable.pd

I've an issue with comments which remain visible when the gop is shrunk.

I'd like to put this whole logic in an abstraction so I'll can reuse it but I don't find how to sendcanvas
to the parent patch

@oid +1000 !

Is it possible to detect when the mouse is in/out of the gop to switch the size accordingly?

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.

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.

@oid "Process stack" is my own term to describe how orders arrive at the processor. I'm thinking at low level, below the C one.
Let's consider this tree and translate it in pseudo-assembly or pseudo-forth:

: BANG
push bang to stack

: MESSAGE_One
pop stack if bang push "One"

: MESSAGE_Two
pop stack if bang push "Two"

: PRINT
pop stack, send to console


: RUN
BANG MESSAGE_One PRINT BANG MESSAGE_Two PRINT

RUN

Trigger is unused at run time, it's only used at "flatten" time to put the methods in the right order. the :RUN content is the process stack I talk about.

However audio tree is flatten to create a DSP chain but maybe the control tree is not…

@ddw_music said:

@oid said:

Edit2: I guess wires are also gotos then.

I realized a bit later what the difference is -- In Pd, wires are procedure calls, not gotos.

In my mind wires (and hidden wires [s] [r] [v]) are variables and boxes are procedures…
You share data throw wires as you transmit them with variables or stacks or registers. The order you link the boxes give you the order the data stack is filled.
By the way, it's also the order the process stack is filled because the full tree is flatten before it computes.

I'm sorry I don't read the full thread, English is not my natural language and it's a bit technical…
Nevertheless I'd like to note that even in written languages the return to caller process at low level is coded by giving the called method an address to store the result in and then the caller can read it.

Pseudo assembly code

MAIN:
give me address to store N bytes
push this address to the return register
call the method
METHOD:
do stuff
get the address from the return register
write N bytes at this address
:END 
read N bytes at the address
do stuff with this result

The full code is unfoldable as a control flow.
The N bytes can be a pointer to an address the method allocates so the return data size can be set by the method.

The easiest way to simulate this in puredata is to create a memory address as [value] do for float. The caller can then give the address to the method with an argument or a message.
As data structures are pointer-accessible they can certainly help to create such a feature.

https://forum.pdpatchrepo.info/topic/4994/dc-offset-filter ?