Manual Pdc

As most of us know, Renoise does not support automatic PDC (Plugin Delay Compesation) yet.
Due to that circumstance, a lot of plugins introducing their own latency in order to process the audio, are rendered useless as a track effect, because the respective track would go out of sync.

Since v1.91, Renoise is featuring a very helpful gadget: the VST info box (or info tool).
Now every VST fx plugin has a [?]-button in the upper right corner of its dedicated area in the DSP chain:

If you either click or mouse-over that button, you will obtain the following information:

As you can see in the screenshot above, Dblue’s Glitch VST is not reporting any latency at all (0 samples) and therefore requires no PDC.
If you are only using plugins that introduce zero latency, you’re already on the safe side and this little tip is superflous for your setup.

Now what if a plugin reports some latency, like this one:

As the infobox tells us, this VST is causing a latency of 142 samples which would make your audio of the track you applied the plugin on to be ~3.2 ms behind the rest. This certainly won’t be too much of a problem if you’re playing some slow-attack strings on that track, but most likely will bug you if there’s some percussion going on.

Now we need a 3rd-party tool, that enables us to delay all the other tracks by the same amount of samples.
This is where Voxengo Latency Delay comes into play.

LatencyDelay is a simple and free VST plugin which merely enables you to delay a single track of your song by a freely customizeable amount of samples between 1-10000.
If there is one track causing a delay of 142 samples, all you have to do is to setup VoxengoLatencyDelay to delay all the other tracks by the same amount, which is quite easy:
The plugin itself will natively and intentionally cause a delay of 10000 samples. Via the GUI of the plugin (or the faders in the DSP chain view), you can set a 4 digit value.
That value will tell LatencyDelay how many samples of the aforementioned 10000 NOT to delay.

If you set the plugin’s value to 9999, you will obtain a delay of 1 sample (10000-9999).
If you set the plugin’s value to 8500, you will obtain a delay of 1500 samples (10000-8500).

So to match a delay of 142 samples, all we have to do is set LatencyDelay to the result of its native delay minus the delay of the latency to be compensated.
=> Ergo: 10000-142 =

Now simply copy the correctly set up instance of the LatencyDelay plugin to every other channel (YELLOW) BUT the master, send (BLUE) and the [i]“to-be-compensated-channel”/i.

You can most comfortably do that via the mixer view by holding the left-CTRL key and dragging+dropping the VoxengoLatencyDelay to all the other tracks one after another.

Done - delay compensated! ;)

Now of course you could argue that setting up a send track with one Voxengo would be more handy, but i think you would then sacrifice a bit of the send-channel routing flexibility which renoise initially offers.
But that’s up to you and your individual needs.

Any suggestions or improvements are welcome.

As a substitute for Latencydelay, you can also use Voxengo SampleDelay.
SampleDelay incorporates the advantage that you can set up the respective delay directly in the Plugin, without having to do some calcs, which you would have to do if using LatencyDelay.
So it’s more straight-forward and comfortable to use - unfortunately looza had to introduce me to the plugin after i started this thread. ;)

The setting to be seen in the above screenshot would induce a latency of 1024 samples.
And to match the latency of the EQ plugin used my example above, you simply would have to set up a 0 0 1 4 2 , instead of the 0 1 0 2 4.

A big thanks to the devs for making the latency display in samples (as well as ms). This has come in real handy!

Top post keith. Worthy of an InDepth article.

Yeah, that new info button is very handy for checking out & correcting latency.

Since I’m lazy, I only use the latency introducing plugs on the master channel, like convolution reverbs or multiband-compressor plugins.

I use sampledelay (not latency delay) which actually lets you input the number of samples you want to delay a track … it’s the backwards approach but works better for me because I don’t have to calc 10000-x all the time …

and (if I use that approach) I tend to insert it at the end of a chain because of LFOs synced to bpms (or similar) because I had the case when a saw-wave-lfo sounded quite off because of the delay.

and apart from that, great post keith. the fact that you actually managed to make a tutorial about this really gives me hope that some PDC-Solution might come around the corner soon … because this all could be done automatically by renoise (or a php-script). Too bad I can’t help with any of this.

Wow. Superb solution. Thanks a lot Keith.

It seems here is a PDC solution for mac heads from Nugen.

What KVR says:
Line-up is a delay unit, specifically designed to allow rapid and simple sample-accurate delays to be set-up with minimum CPU overhead and screen imprint.

Delay time automatically steps through powers of two to allow rapid dial-in of frequently required numbers. Double-click allows direct numerical entry and holding down shift whilst click-dragging steps through in single samples.

Although primarily intended as a line up tool for misaligned tracks (no host PDC, phase re-alignment, long mic/speaker recording delay, etc.), Line-up can also be used as a send effect to create very precise chorus, phase and doubling effects.

Its a free tool, but u need to be registered at Nugens site.

Haven`t tested this tool yet.

damn, you’re absolutely right.
i didn’t bother to give SampleDelay a try after i figured that LatencyDelay is doing the job i was looking for.
i think that working with SampleDelay is way more feasible, since you don’t have to do any calcs and can enter the respective amount of delay in samples straight forward into the tool. i already wondered why LatencyDelay is taking the “backwards approach” and now i wonder why LatencyDelay is existant at all when there is SampleDelay - odd.

i’m probably just a too shortsighted to imagine the difference correctly, but as far as my logic is concerned the two scenarios (compensation of the audio stream at [1]the end [2]the beginning) shouldn’t differ from their final result at all. because in either of the two ways, the audio won’t be output any earlier than what the latency is set to.
and the BPM doesn’t differ at all, it’s just time-shifted, so i wonder why LFO should cause problems in either of the two ways…
but of course that’s just my theory and when your practical experience differs, my poor logic is most likely flawed ;)

as far as the reference at KVR informs us, there also is a windows version.
good find, will give it a try tomorrow when i’m finally home again!

afaik latencydelay is meant for PDC-capable hosts and allows you to play something earlier. This is actually the plugin to use in a PDC-enabled host if you have a plugin that does add a delay but does not report the correct size (like the one you mentioned in that other post).

The approach you demonstrated above basically delays all other tracks so they match with the delayed one and for this the sample-delay is perfect.

if you have a PDC-enabled host and a “lagged” plugin then the latency-delay makes much more sense :

afaik it introduces a 10.000-sample-delay which normally gets compensated by the host and then you can fiddle the knobs to substract the delay that “delayed” plugin has. This way you just need a latency-delay on the delayed track and not sample-delays on every other track.

(does this make sense ?)

about 2nd :

well, it is about that timeshift-thing, I guess f.e. a trancegate that gets the midi-timing from renoise which is applied to an audiostream that is seriously delayed (whyever) will probably sounds strange because the audio is actually shifted in time (which makes the impression that the gate closes and opens too early), so I just thought I do this “delay”-thing at the end, so I don’t mess things up even more. something like that.

Since renoise doesn’t support pdc, no matter which vst you will use to delay compensate you will have to set it on every tracks. So even with sample delay you will have to set and calculate for each tracks.

In fact, I totally don’t get how you compensate with sample delay without having 1 instance of sample delay per tracks, because, let say tracks 1 has 500 sample delay, track 2 has 0 delay and track 3 has 80.

With latencydelay you just load one instance of latency delay per track at 10000 minus the vst delay of each specific track. Your standard time for every tracks would be 10000 samples minus the sum of the delays induced by the vsts on this track.

With sampledelay you would have to keep the biggest delay (track 1) as your “standard time”, then adjust every others tracks to this one. Load sample delay to track 2 with 500 sample delay, then load it on track 3 with 420 sample delay etc.

Or do you do it in any other way ?

no, you got it mixed up, there are two plugins :

latencydelay : adds 10.000 samples of delay minus the amount of samples you enter, not really suitable for renoise.

sampledelay : adds a custom amount of samples, this is the more comfortable one for renoise.

and yes, you need a sampledelay for each track (except the track with the longest delay).

About your example : track1 has 500, track2 zero and track3 has 80.

so you leave track1 alone, add a 500-sample delay to track1 and a 420-sample delay to track3.

(and now use sendtracks with senddevices somewhere in the chain (not at the end) to completely loose your mind. Been there, didn’t like it.)

Oki, I thought you were saying that you only used sampledelay only on the tracks who needed delay. So yeah sample delay is better because it doesn’t induce 10 000 samples delay to every tracks. The only “downside” is that you have to calculate for each tracks, 6th grade level though ;p

aslong as you are with 4 tracks all is pretty okay, from 8 tracks+3sendtracks on it gets horrible.

however, if you don’t really hear the problem induced by PDC and just want your music to be “correct” on a technical scale you can also just track away and when you are finished you add a hard attack sound (a click or similar) to every track in an empty pattern at the beginning of the song, render all to single tracks, use some sample-editor to cut the lags (small pieces of silence) infront of the click and mix the whole stuff in some other software like reaper etc.

Yeah that’s what I’ve been doing till now, but it’s really annoying (unpossible) if you wanna process a sound by mass layering/FX’ing with something else than renoise’s natives effects. In fact, you can’t realtime process anything with third party vsts as soon as you layer 2 sounds with different effects, if you don’t use those third party delay solutions. It’s that or you do all your processing in another daw.

So far I had about two instances where the problem really P***ed me off, in all other instances I could kinda ignore it until later.

no, that’s not the case.
you actually cannot play something “earlier”, because then the plugin would have to be a fortune teller, which knows what audio signal is going to come before it’s actually there.
latencydelay basically does exactly the same as sampledelay is doing: they both delay the applied audiostream for a set amount of samples, whereas sampledelay does natively not introduce any latency and starts counting upwards from 0 to a value set be the user and latencydelay introduces a native latency of 10.000 samples which gets subtracted by the value set by the user.

so at least in renoise, both ‘‘behave’’ identically, with the only difference that in order to perceive the desired result the user has to undergo inverted approaches (the one counting up from zero, the other counting down from 10.000).

i absolutely don’t sense a difference in their general purpose at all.

But you can offset the existing data to start earlier…

let’s say there are 8 tracks.
track 1-7 start at timestamp “100”, whereas track 8 starts at timestamp “0”.
so that makes track 8 start “earlier” compared to the rest, but actually that’s just because track 1-7 start “later” and track 8 just plays in “realtime”, if you know what i mean…
we’re probably also talking about totally different things or just don’t use the same definitions of “earlier” and “later”.

no matter what, in my defination of “earlier” it would imply that a sound is being played BEFORE it actually is generated.
sounds like an impossible task, if you ask me.

Yes, we do talk about two different ways to compensate.
What I meant is that you can offset existing data (midi/notes/automation etc). So instead of compensate the audiostream by delaying 1-7, you could move all existing data in those tracks 100ms earlier. You would then get a 100ms lag when you hit play. But after that initial delay everything is in ‘real time’ (assuming you are working live on track8 and track 1-7 are pure playback).

which is how they do it with the big DAWs.

You need to distinct between the visual feedback in a program and what’s really happening under the hood, as psyj said if you press play in f.e. cubase you will have a small delay (probably not even noticable) and while the software “seems” to play that exact spot you are at the software is internally a few samples/ms ahead, rendering the audio.

and because latencydelay causes a delay of 10.000 samples the audiostream gets started 10.000 samples earlier. and if you now reduce that delay the audiostream is actually playing “ahead”.

Nice tip !

But is there a way to know the delay of VSTis ? This tip could be very useful for instruments.