The latency that is calculated via the (getlatency) message to supervp.scrub is incorrect.
It seems to be twice the actually latency (i.e dividing by two seems to correct it).
At window sizes above 8192, this fix does not work and the latency is off by several 1000 samples. In the reference it states that the latency is output in ms, which is incorrect.
supervp for max version: 2.18.9
Max 8.5.6
OSX 10.15.7
Hi srs,
getlatency gives you the max delay depending on the current settings: Output max i/o latency in samples.
the getdelay message gives you the current latency (variable).
In the doc source the units are correct, pbly we need to regenerate the maxref some time.
Best
Thanks Diemo. I didn’t know about the getlatency message.
I am trying to sync up different objects that play through a sample via a ms playhead position (e.g. using both supervp.scrub and mubu.granular with the same playhead position source input) so the issue is a bit more complicated than just the object’s current latency.
Does each window size, overlap and oversampling amount introduced a fixed latency in samples regardless of the system the patch is running on?