Patchwork - no latency compensation

Official support for: bluecataudio.com
Post Reply New Topic
RELATED
PRODUCTS

Post

Hi guys,

I am trying a demo of PatchWork (newest version with the vst3 implementation) in PT12.5, OSV 10.9.5, just one row, 8 columns. I wanted to compare different compressor plugins (AU) with PT's one, so I put in all 8 columns AU compressors from Logic9 and other one, this I saved as a Patchwork preset.
I use Patchwork in a Mono Track, this I send via BUS to my second AudioMonoTrack where I record what comes from Patchwork. While testing I got these result about bad latency compensation, pointing out in an earlier waveform:

In relation to my guide track,
- a processed one via Patchwork only a plugin in the slot in the PRE section (the parallelchain is OFF, POST plugin is bypassed) is fine and in sync/ in time.
- a processed one via Patchwork only one plugin in the ParallelChain, but bypassed, TDR Kotelnikov (PRE plugin is bypassed, parallelchain is ON, POST plugin is bypassed) give me almost 190samples before the original!
- a processed one via Patchwork only one in the ParallelChain, TDR Kotelnikov (no PRE plugin, parallelchain is ON, no POST plugin) give me now almost 230samples before the original.

So it seems, TDR Kotelnikov is something strange in its behavior? And that plugins in the PRE and POST section decrease the amount of time. If I close and reload patchwork, I get same results

Now I did this:
I opened Patchwork with 8 columns, but no plugins except TDR Kotelnikov - and it's in sync. I put Kotelnikov in in slot 8. And it's not in sync. I repeat it and it is in sync. I did several times. Does latency compensation works first at 2nd time? So it's not TDR Kotelnikov?
Unfortunately this behavior now is not repeatable. If I reload that preset with 8 compressors (see above), I'll get the bad result again; here it starts from the beginning: I throw all out except TDR Kotelnikov = same bad latency ... and so on.

What kind of effect happens here - and why?

My general question is: How is it about latency compensation with patchwork? When all slots are full of AU and/or VST plugins, bypassed or in use?

Thanks a lot and cheers
Johannes

Post

Hi,

Regarding latency compensation, PatchWork does several things:
- it keeps reading latency from loaded plug-ins before processing every buffer to make sure it is up to date, even for plug-ins that do not report latency changes.
- it compensates latency between parallel chains to keep them in sync.
- it reports the global latency to the host so that it can perform its won latency compensation.

Now several things may happen in your case:
- when bypassed, a plug-in should make sure that it still delays the input signal from the same amount as the reported latency. Maybe this particular plug-in is not doing this, hence the extra pre-delay.
- sometimes the host is having a hard time updating its latency compensation engine in real time (since loading a new plug-in in PatchWork change sth elatency, Logic has to update its whole latency compensation chain). Usually simply restarting transport and/or disabling-reenabling patchwork in Logic should fix the issue.

Also you may want to try both the AU and VST versions of the plug-in, as maybe the other version works better regarding latency compensation.

Post

I know this is an old thread, but I'm wondering as you mention it's good to try both AU and VST versions. Generally speaking which (AU, VST) are more efficient regarding latency compensation?

Post

There is no rule, as this is highly dependent on the specific implementation of the plug-in vendor.

However, we usually recommend trying VST2 first, as it is in many cases the most stable implementation (this plug-in format has been here for a very long time!). And it is supported on both Windows and Mac, so you can share your presets.

Post

Blue Cat Audio wrote: Mon Jun 20, 2016 7:12 am Hi,

Regarding latency compensation, PatchWork does several things:
- it keeps reading latency from loaded plug-ins before processing every buffer to make sure it is up to date, even for plug-ins that do not report latency changes.
- it compensates latency between parallel chains to keep them in sync.
- it reports the global latency to the host so that it can perform its won latency compensation.

Now several things may happen in your case:
- when bypassed, a plug-in should make sure that it still delays the input signal from the same amount as the reported latency. Maybe this particular plug-in is not doing this, hence the extra pre-delay.
- sometimes the host is having a hard time updating its latency compensation engine in real time (since loading a new plug-in in PatchWork change sth elatency, Logic has to update its whole latency compensation chain). Usually simply restarting transport and/or disabling-reenabling patchwork in Logic should fix the issue.
I have a question about this, does the patchwork synth version also report the latency of plugins inside it to the host as described above? I can’t seem to get the to work. Using in logicpro.
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

All versions indeed report the latency. However I am not sure if Logic properly manages MIDI delay when a synth reports some latency.

Post

Yea I did get it to work, logic handles pdc on it but usually with fx plugins when you hover the mouse over the plugin button it reports the amount of latency but apparently for inst plugins it does not show this, sadly.

Could you clarify also what patchwork’s does inside of there are multiple parallel chains with different amounts of latency on each chain. I am guessing that they are all delayed to match the chain with the longest reported latency and that is the latency reported to host. Yes?
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50

Post

Indeed, that's the way it works! And this latency is reported to the host so that it can be compensated by the host too.

Post Reply

Return to “Blue Cat Audio”