Probably that make the patch always editable -with the command key to force interaction with GUI (as it is in Pure Data in edit mode)- is the simpler approach. The "remote view" i was referring in the original post would be used once the patch finished. It just have to be done now!

Yep, the ctrl/cmd key is pretty handy. But i should have precised that my question is in the case where you rewrite all the GUI, as in a ♥️ dream 🌈. For instance i'm thinking about a way to navigate inside subpatches in the same window, and to connect objects without dragging lines. And since that my fork aims to allow live-patching, i'm in front of a question: Is that the edit mode really usefull? Without an edit mode the only problem that remains at first view is a way to distinguish between moving a GUI object, and interacting with it. I could make one behaviour the default and use the other with an option key. But is there alternate approaches i didn't see (in others softwares for example)?

I always found that switching from/to edit mode all the time is very annoying. But i can not think about a way to avoid that. Is there any UX expert here with an idea about how to manage both moving/interacting an knob for instance whitout that damn edit mode?

https://forum.juce.com/t/has-anyone-tried-porting-pd-to-juce-other-than-cycling-74/39077?u=nicolasdanet

Sign of life < https://github.com/Spaghettis/Spaghettis/issues/25#issuecomment-811075870 >!

I was pretty sure that [list foreach] was already there to iterate, but nope ...

.... just an old PR < https://github.com/pure-data/pure-data/pull/595 > never merged!

@jameslo: you are right, it is a bit silly.

Of course we have on TV. I have seen a lot of them when i was a child (long time ago).

For example [expr] has a different license than PD-vanilla.

It is also BSD now < https://lists.puredata.info/pipermail/pd-list/2019-09/125996.html >.

@jameslo: Note that latency is not equal to efficiency. In that case what you gain is to avoid the (e.g. 64 samples) offset introduced (in the delay line for instance). And IIRC it costs nothing (in term of CPU) as the inlet~ will be probably cropped/removed from the DSP chain.

If you know how to compile you could try to enable the PortAudio debug (PA_ENABLE_DEBUG_OUTPUT) flag?