each stage of packet- or audio-handling could add latency (we dont know your system).
@romulovieira-me see this audio latency tester by @katjav
With this approach, you need some sort of loop-back (and be aware of the audio i/o latency)
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
or a sample-counter and [samplerate~]
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
Or load a patch as abstraction with [switch~ 0] in it.
But I doubt this would help here.
does not like that all my arrays are duplicated.
To avoid duplicates, rename your arrays with $0-arrayname
@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
[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)
see intelligent patching and text editing of .pd files:
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