BUG: Sidechain signal within groups not PDC compensated, depends on audio latency

Help, Support & Bugs
1

Not sure if this already was a topic: If I send a sidechain signal from a track which introduces PDC, the signal at the receiver device will not be compensated, but instead delayed… Shouldn’t this be compensated?

I think it should be compensated at the receiving device in the sidechain, before the signal actually flows into the device, not at the sending channel (because the sending channel already has that amount of PDC).

2

I tried recreate this with Ozone and Pro-c2 but it appears to be working here.

On track 01 I added Ozone which create 177ms latency and then a sidechain device sending to a Pro C2 on track 02. Maybe I could be doing something stupid!? :sweat_smile:

Maybe you have accidentally turned off PDC?

sc-pdc-test

3

Hey, thanks for your ideas, but here is an example xrns, I hope you can replicate this as well (macos user here). Steps to reproduce:

  1. Install MRatio VST3 from free Melda bundle. For an additional test, install elite reducer from here (just put both files into vst2 plugins dir).
  2. Set the audio device to maximum latency and 48khz (80ms here)
  3. Load the xrns:
    sidechain-pdc-problem2.xrns (25.7 KB)
    The bass should appear in the middle between kick and snare.
  4. Now disable the send device on track in the “basses” group (not “bass” :laughing:). It is followed by a sidechain device. As soon as you deactivated the send device, the bass should appear very delayed.
  5. Set audio device latency to 8ms or so. The bass delay should almost disappear.
  6. Enable the send device again. Remove the already disabled elite reducer from the snare track. As soon as you remove it, the snare transient should be quite different / louder.

So something seems to be very wrong here, dependent on the audio latency. If you set the audio latency to most exactly the song PDC, the problem almost disappears…

EDIT: It seems to me that the generator latency is not taken into account here…?

4

When I bypass the send it does sound delayed and not good, it’s just odd that I can’t reproduce this when i introduce MRatio in my own test file.

You have a bit of an elaborate structure going on where you send the signal around, maybe the bug is hidden somewhere in that chain of sends?

5

Ok think I narrowed down the problem:

The problem only appears, if a group is sending the sidechain signal. Proof:

  1. Play
    sidechain-pdc-problem2b.xrns (23.0 KB)
  2. While playing, drag the sidechain send device from the “basses” group onto the bass track at the very last position. The lag disappears.

Also as a workaround, this seems to solve the problem:
Duplicate the sidechain send device, leave it on the group and put a copy to the inner track(s), but disable it (it needs to have the same target, even when disabled). The workaround does not work for groups in groups :confounded:

1 Like
6

Right, you’ve found it, when I put the Sidechain on a group it does make a difference too in my test, look at the spike. Let’s hope @taktik takes a look :face_with_monocle:

sc-pdc-test2

3 Likes
7

Hm how do I fix my templates now? It seems that currently sidechain should not be used on any kind of group tracks or nested tracks… I had such I nice idea for a good synthwave template, now I need to use many sends, so ugly.

8

Also I have the feeling that you @taktik fixed this already in some beta…? I mean, weird that nobody found this already before.

9

This is not a good bug to have long term :thinking:
Hope everything is okay with mr. Taktik.

1 Like
10

Bump @taktik - if you can’t share details on the future, perhaps try to at least acknowledge bugs?

2 Likes
11

Sorry for the late reply.

The problem here is not the PDC, but the parallel audio processing (multi-CPU). If you set the number of real-time audio CPUs to 1 in Renoise’s Audio preferences, the timing should be perfect, no matter what latency is introduced where.

Working on a fix now…

10 Likes