Hey all,
Two questions:

1: What is the latency of gain~? (It is from the else library.)

2: How can I figure out the latency on my own?

Any help would be very appreciated.

0 samples

Using same technique as @katjav 's latency-meter, which was 1 sample off, here is a fixed version:
https://forum.pdpatchrepo.info/topic/13814/catch-would-like-to-set-the-name-programmatically/20

And there is a latency-tester in PD's doc:
07.stuff/tools/latency.pd

As long as there is no windowing, reblocking or delay line involved, objects usually have no latency.

Thank you! 1 sample. seems pretty amazing. Thanks though

@raynovich said:

Thank you! 1 sample. seems pretty amazing. Thanks though

A feed-forward unit generator should have zero samples latency. It gets samples in, processes them, and outputs them with no delay (unless delay is its job).

FWIW though, I was just trying to do a quick demo, and else.gain~'s messaging interface is really quite inscrutable. It's fine if I manually move the slider, but what if you want to initialize by loadbang? I just cannot get that to work.

You could just use a [*~] instead.

hjh

PS the demo:

@raynovich zero not one

Pd and the whole patch have latency.
The whole patch (and subpatches, abstractions) gets computed and streamed in blocks (usually 64 samples). But within the patch/block/stream, there is no latency.

Only if you do windowing (larger window size than 64 samples for FFT stuff for example or do reblocking in subpatches) or delaylines including feedback (or mess with {s~] [r~] order, mentioned in the linked thread above), introduces more latency.

@ddw_music in the helpfile is an example with [set $1( message. Then again the set message to set the slider without output is missing, but [gain~] appears to be a Vanilla? abstraction,