You can run PD with the

-noaudio
-noloadbang   

flags.
Or load a patch as abstraction with [switch~ 0] in it.
But I doubt this would help here.
https://puredata.info/docs/faq/commandline

@tomatoKetchup said:

does not like that all my arrays are duplicated.

To avoid duplicates, rename your arrays with $0-arrayname

@mganss said:

an external that executes JavaScript using V8

Really nice work!

Could you please give a brief summary of how to implement such an engine or library in PD?
What have been the steps to embed it in PD?

maybe [pool] is slightly related
https://grrrr.org/research/software/pool/

@djaleksei To make sure that you don't get one block of delay by the [s~] [r~] or [throw~} [catch~], add a dummy i/o and connect the sending and receiving objects:
This ensures [s~] is created before the corresponding [r~], just as described in help>audio examples>G05.execution order with delay lines and subpatches

This works with @whale-av 's suggestion.
@djaleksei You want to route signals from different instances of one cloned object into different instances of another cloned object?

[s~][r~] and [throw~] [catch~] might be the cheapest CPU- and patching-wise

(and [poly] might be part of your interest.
with [switch~] you can turn instances on/off)

@Lev
see intelligent patching and text editing of .pd files:
https://forum.pdpatchrepo.info/topic/13134/things-i-wish-i-had-known-when-i-started-pd/22

@raynovich fill an array, sum with [array sum] and divide by array size

With a crossfader you can even do continious morphing.
Yes, with large arrays you'll get resolution issues. These already happen with [phasor~][*~ highnumber], too - because it does the rounding between the range of 0 to 1, some circles not reaching 0 or 1, while keeping its frequency perfectly stable
https://forum.pdpatchrepo.info/topic/12865/samphold-noise-phasor-noise-round-off-error-or/15

@JMC64 I currently can't run pd here, as im writing on a phone, but I'll explain
@lacuna said:

@JMC64 phasor~ is part of the sound, because when reading the wavetable, a jump is occuring at it's rising edge . Better use a triangle.

Sorry, that was wrong: the jump is at the falling edge.
Looking at the shape of phasor~s waveform: / / / /
it is a ramp from 0 to 1. Then it jumps within one sample back to 0. That's a sawtooth.
With a triangle ^^^^
you can [tabread4~] parts of the array back and forth, without any glitch.

As you change its range from 0-1 to 0-2048 by multiplying with [*~ 2048] ,
[+~ 2048] is adding an offset: 2048-4096

snapshot~ and all other control-objects (everything without tilde ~ ) have a resolution of one blocksize, not updating the right inlet of [tabread4~] on each sample, but up to 64 samples too late.
Control objects calculate and output between the blocks with 64 as fastest rate (even if the blocksize is changed by [block~] )
(Bela is running a modified PD with 4 or 8 samples blocksize as minimum, I think - but still. )
Signal ~ objects calculate between the blocks and output continiously samplewise within the block of the realtime audio stream.

@JMC64 said:

I am struggling with creating a externally synched LFO receiving a clock from an external source. For instance a sawtooth (phasor~) .

receiving a tick( bang) from the emitter

But the emitter of the clock is of course is not perfect and the clock not completely steady.

What clock-source is this?
An audio signal? A Midi clock?
Keep in mind that PD's control/message domain, including Midi i/o and most control-objects, (such as [snapshot~] ) have a resolution of 64 samples only.
Is this the cause of jitter here?

With [tabsend~] you can use every sample of a block~ in the control-domain.

I tried averaging the value of the time interval with a running average but this is not satisfactory.

I also wish not to change the average value of the frequency of the LFO every time a tick is received is received, but only when a significant change occurs.

Maybe try the median, instead of a moving average?
Together with a hysteresis detecting greater changes, as @whale-av has suggested.

leading to a desynch with the incoming clock and a slow respond to real change of the external clock (i.e. 120 -> 130 BPM).

Every averaging filter won't be exact by definiton.
And to be "on time" at a change, you have to "look-ahead".