@FredIR Good advice from everybody......
I put this on the forum a while ago..... https://forum.pdpatchrepo.info/topic/13320/welcome-to-the-forum
It is quite essential reading for anyone starting with Pd.
It is certain that your messages are arriving in the wrong order, and as @alexandros says, we can have no idea where the error could be because we cannot know in which order you connected the objects (we can, by reading the text version of the patch, but it would take a while to then rebuild it with triggers so as to make it readable, and our heads would be spinning)....

So $f1 arrived before $f2 or $f3 and by adding a bang to your order of operations after they have arrived you get the correct answer, but you are lucky that the object banging that bang received its data late enough for the solution to work.
David.

@SpaceUnit Welcome to the Forum...!
[gemhead] should be connected to the top left inlet of [rectangle 3 1].... and not the outlet (at the bottom).
Right-click and select help for any object in Pd to see how it is used.
David

@jameslo https://puredata.info/docs/developer/PdFileFormat
It's a slightly flippant reply I know......
Maybe the reason is in the "remarks" for the #X coords entry but it needs further investigation.
I don't think it should be the last line....... there should be a "restore".
David.

@60hz If the OSC messages are coherent (on a curve or a straight line) then you will get a good result with devoted sound generators, but if they are jittery (too much noise) then they will be less useful for sound generation.... or anything else for that matter.
Yes..... if you are wanting to swop out generators based on the data then you will need to keep them all all running and pan between their outputs or you will have clicks.
You could use [switch~] to turn their dsp processing on and off, and fade their output in and out with [line] and [* ~] before activating [switch~]....... and that will save you loads of cpu.
There are ways to smooth the data if needs be.
David.

@60hz Can you not do that with [route Arene Musee dog cat ... etc.] and send the output... the list of floats where you wish from each outlet of route.

I don't know why you need to keep track of the symbol id's, but they could be added back to the float lists once they drop out of the route...... using [list prepend Arene] etc.
Then you can re-filter the data as you wish.

Is this position data from fiducial markers?
David.

@60hz What format is your list and how do want the output to vary?
A variation based on what parameters?
David.

@60hz That's why I thought [route dummy] as you can change the symbol "dummy" to anything that arrives. You would have to [spigot] that once it has its value until your voice stealing logic allows it to be changed.
Actually in [poly] it is only preserved once and is then available if voice stealing is allowed.
I don't think it matters which voice is stolen....... just one that has already output "symbol 0" maybe.....
David.

@60hz Not that I know...
I think you will need to build a patch based on [route] ....... so [route dummy] so that you can change its symbol.
Then as an abstraction in [clone] with a method of communication between clones for voice stealing.
It's an interesting challenge.
Maybe someone that can read C can post how it is done in the [poly] binary?
David.

@Muology A $0 in an object (a box) gets its value assigned as the patch is created..... so as it is the argument for [dyn-abs $0]..... there is a space between dyn-abs and $0..... the value becomes the value of $1 (the first argument) inside the [dyn-dns $0] abstraction.
Then the sends and receives.... [s $1register] and [r $0register] become identical and can communicate.
The same is not true in a message box.... $0 will have the value 0...... not useful.
Please read this.....
https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4
David.

@yannseznec I suppose that's likely..... if you have the .c files in your distribution you could check that the bugfix code is in there.
Otherwise maybe there is more info on the RPI forums..... but if not then you could report a bug on the Pd list.... but..... maybe it is a problem with a particular Linux distro if that is different on the 3 and the 4.
Clutching at straws and although I have a RPI I don't run Pd on it.
David.