In plugdata v0.9.2 hosted on REAPER v7.48 running on both Windows 10 and 11, I can't set the plugin's latency under Settings...->Latency (samples). When I enter the number of samples and close the dialog box, it immediately reverts to 0 and REAPER reports a plugin delay compensation amount of 64 samples which is what it reports when plugdata is first loaded. I fell back to plugdata v0.8.3 on my Win10 machine and was again able to set the latency, so there's my workaround.

Surprisingly, if I copy that same REAPER project hosting plugdata v0.8.3 over to the Win11 machine that has plugdata v0.9.2, it retains the latency I set on the Win10 machine, but as soon as I try to edit it, it reverts to 0.

Anyone else seeing this issue?

I'd also love to know if there is a way of setting the plugdata latency setting within Pd. My patch has a look-ahead detector, and when I change the look-ahead amount, the latency has to change accordingly.

@whale-av Thanks.

I tried a few things,different Vst,tried the [osc~] and same latency.Tried different Asio drivers,i am on windows 10 but anyway i don't have this much latency when i do the same thing in a different DAW.For example Plogue Bidule,exact same driver,same midi keyboard,same setup and the latency is the normal one i have with 512 samples where as in PD it is like 3-4 times more,well hard to measure by ears when i hit the key but it's not really playable.
I didn't intend to play live keyboard with PD but would be nice if i could get this to the normal latency with 512 samples.

That is the proper way to send midi to a synth right?

• Just to add, i used the first output of [notein] to control the frequency of an [osc~] and had the same latency.

The question of how to tune an all-pass to compensate phase shifts of an IIR filter is also part of my interest.
How to calculate the phase response of an IIR and then build an all-pass with the inverse phase-response?
Maybe @manuels can help here?
Or is a machine learning approximation required?

On latency: As all-pass filters add latency (the phase-compensation is addition of frequency-dependent latency), I would not be surprised if the all-over latency would be in the same order with FIR filters for such a low cutoff-frequency.

Looking at the filter:

delay (msec) is to create the total buffer size. Its important for round trip latency where PD is looping the input to the output - the delay (msec) gets added with the block size (which for compatibility with other patches just keep at 64)

Usually JUCE based programs just give you a "block" of audio, PD is more under the hood about the DSP, the 64 block is a ring buffer that the main patch is at (which is why you have to subpatch to reblock) and the delay msec is padding for the CPU.

Normally you only run into it when you have to up the amount with the sine playing in 'Media, test audio and midi' when you first install PD until it stops sounding scratchy

but also theres another patch in the help browser under 7.stuff/tools/latency you can loop back the output of your audio to the in and play around with lowering it. Either with a loopback function on a dac, or like a wire plugged from out ot line or just have the mic and speakers setup where they could cause feedback if turned up too loud. Tests on the internet for mostly vintage DACS doing round trip latency were actually done in PD.

playing around with it I found Intel macs can go down to 3, and prosumer asio (like an old external edirol dac) can go down to the lowest, 2. Its up to the low level driver to give you the real round trip latency.

usually as long as you can get the sine wave to play in Media.. test audio and midi you are good. Its really only for processing audio in with minimal audible latency - super small delays go off the rails the second you really hit the CPU with polyphony, delay lines, small block sizes.

For a while I had it at as low as it was without being scratchy, but as I got into more complicated (and bloated) synth designs I just kept mine at 50 because when it was having problems more latency than that never helped but less could cause stutters/scratchy sounds.

Linux and Windows are usually set by default to 50 or 100 tho I dont have a problem above 23, offhand I think intel macs were set to 5 or 10. the new arm macs can run into a problem where the old default was too small and should have it higher as well. So the real winners were old intel macs.

use callbacks is only for some older audio drivers in linux

@bklindgren Maybe "expected I/O latency" or "realtime processing budget"? I say that because if the actual latency is greater, you'll hear clicks as blocks are dropped or corrupted. But the expected latency can be set much greater than the actual latency without problems. Look at the following test:

REAPER sends the test tone on track 1 out its audio loopback driver to Pd, and Pd returns it on the next 2 channels in the loopback driver. I recorded the return signal on tracks 2 through 5 using Pd delay settings of 50, 20, 10, and 100 ms, respectively. The delays on the return tracks are 52, 21, 11, and 101 ms respectively.

@bklindgren It is usually called a buffer and set as "buffer size" in samples...

Pd is unusual in calling it "Delay".
The buffer size in samples divided by the sample rate equals the delay (latency) in seconds.

Of course the block size of 64 samples gives internal latency.
You only need to worry about latency for live work and live monitoring in a studio,
A latency of 2.9 milliseconds (128 samples at 44100Hz) is the same as moving an instrument just under 1 meter away from a listener...... so not really noticeable..... (speed of sound approximately 343 meters per second in air)
David.

@ddw_music Oh OK, well I redid the test using a 1033.6 Hz sine wave (1.5 cycles/64 sample block) and the result is consistent with a 64 sample shift (i.e. 180 degrees out of phase), plus it goes away when I set plugdata's latency to 0. I'm gonna check on the REAPER forum to see what they say about PDC--maybe the issue is that REAPER assumes a base 64 sample latency for all plugins so plugdata doesn't need to report that portion.

It would still be interesting to see if other DAWs behave similarly. Maybe I have to dig out my old laptop and struggle with Cubase again. 1033.6 Hz sine.wav

BTW, is there a way to set plugdata's reported latency to the host programmatically? I have an FFT resynthesis patch that uses different block sizes. Camomile has that facility.

Update: I think I'm seeing the same behavior in Audacity, but my understanding of Audacity is weak. I also tested an FFT resynthesis patch in REAPER using a 16384 block size and set plugdata's latency to 16320 (16384 - 64) ; that produced the alignment I was expecting. So I'm provisionally declaring that you should set plugdata's latency to the latency of your patch as measured between adc~ and dac~. In retrospect that seems completely obvious, but I was thrown by plugdata's default of 64.

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.

@whale-av said:

I am almost certain that Gui objects in TouchOSC can talk midi and OSC at the same time.
But I doubt that it will communicate over wireless (required for OSC messages) and USB at the same time.

GUI objects in TouchOSC can send Midi and OSC at the same time, and wired USB connection does work for both, no issues. no need for having the iPad on Wi-Fi. just takes a while for TouchOSC on the iPad to realize what the IP address of the laptop is.

The communications between Pd and touchOSC are set in the abstraction [osc-s-r] within the [globpitcharray1] patch in the zip I posted.
There is a TouchOSC layout plom.touchosc in the zip that should be used with this patch (for a test demo).

thanks for breaking this down for me!

You would need to fix the IP address of the Ipad (static address) and use that address for [netsend] and [netreceive] in [osc-s-r] ....... if you ever get over your fear of using Wi-Fi for this.... or just feel like trying it to see what it will do.......

yes, [osc-s-r] is definitely where it's at. thanks for spelling out the [netsend] and [netreceive] to me, cos looking at the screenshot i had, i can now realize where to input 11000 and 11001 for send + receive. the connect portion of the script was throwing me.

i hope i have it right now,

The amount of input-->output latency comes from the soundcard driver settings, specifically, the hardware buffer size.

"Where does latency come from" is this:

The audio card driver processes blocks of audio. (If it didn't process blocks of audio, then it would have to call into audio apps once per sample. There is no general purpose computer that can handle 40000+ interrupts per second with reliable timing. The only choice is to clump the samples into blocks so that you can do e.g. a few dozen or hundred interrupts per second.)

Audio apps can't start processing a block of input until the entire block is received. Obviously this is at the end of the block's time window. You can't provide audio samples at the beginning of a block for audio which hasn't happened yet.

You can't hear a block of output until it's processed and sent to the driver.

| --- block 1 --- | --- block 2 --- |
| input.......... |                 |
|                \|                 |
|                 \_output......... |

This is true for all audio apps: it isn't a Pd problem. Also Pd's block size cannot reduce latency below the soundcard's latency.

You can't completely get rid of latency, but with system tuning, you can get the hardware buffer down to 5 or 6 ms (sometimes even 2 or 3), which is a/ good enough and b/ as good as it's going to get, on current computers.

hjh