@tyldurd Messaging is limited by the control-rate. [Messages( get processed between the blocks of 64 samples.

If you want to update the filters externally at signalrate, which is more expensive, you can use $1 inside the clones.
Some of many ways here:
https://forum.pdpatchrepo.info/topic/13268/routing-different-signals-to-clone-instances

subtracting a lowpassed signal from its' original results in a highpass (and vice versa):

@Metronome
the vanilla way is to use [==] as condition and [*~] as amplifier.

In your use case the signals won't be uncorrelated, so don't use [pow~ 0.5]

each stage of packet- or audio-handling could add latency (we dont know your system).
@romulovieira-me see this audio latency tester by @katjav
https://forum.pdpatchrepo.info/topic/7065/samplewise-delay-meter
With this approach, you need some sort of loop-back (and be aware of the audio i/o latency)

@nicnut

Instead of relying only on [metro]
with it's control rate resolution swing

for a steady clock,
without testing, I'd say

calculating with the output of
[realtime]
or a sample-counter and [samplerate~]
or [timer]
a message
for [vline~]

should do the trick.

Composing the delay-time-message for [vline~]
by substracting the expected exact time
from the actual time ( at block boundary )

There are many ways to build messages and trigger [vline~] accurately.
Am interested in what you come up with!

Also the time-stamping t3 objects in the iemlib could help!

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)