@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 ?

OSC is not used by the screen but by the Bela board which interprets it and communicates to the OLED by the u8g2 Arduino library throw the I2C protocol.

The graphics for each OSC message types are defined here https://github.com/giuliomoro/O2O/blob/main/main.cpp so you can add/modify to your need.

You can also drive the OLED directly from the RPi with the same library, see https://github.com/ribasco/u8g2-rpi-demo.

$ uname -a
Linux _censored_ 6.12.20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.20-1 (2025-03-23) x86_64 GNU/Linux
$ pd -version
…
Pd-0.55.2 ("") compiled for Debian (0.55.2+ds-1) on 2024/11/17 at 16:07:58 UTC

The text doesn't overlap when zoomed.

You have a sample in the start subpatch of the seq-help.pd

Can this help? https://forum.digirig.net/t/solution-how-to-force-sound-card-order-on-rpi/1488

Hi,
no you can't use parameters on subpatches (they inherit of the parent patch ones). You should use abstraction for that.

It works well!
I'm using a canvas to set the enlarged size and the switch move to the right dynamically.

expandable.pd