DUNE3/LogicX: Popping sound in Delay on tempo change event

[pluranium]

Hey, I'm loving Dune3 but this is very annoying. Repro steps:

1. In Logic Pro X, create a new track with Dune3.
2. Choose/make a sound with just a pure sine wave and a delay effect
3. Record a bunch of random notes.
4. Add a tempo track with a number of tempo changes.
5. Play back.
6. The delay effect will make a popping sound on each tempo event.

Thanks for fixing!
Markus

[Richard]

This cannot be fixed, at best mitigated to some degree.

Changing the tempo of a clocked feedback delay will always result in some sort of artifact. This can be a pitch change, timbre change, click, silence etc. depending on the implementation.

One solution would be to un-sync the delay, or simply avoid the delay during the tempo change.

[pluranium]

Mitigation is the way to go since popping makes the effect totally unusable in this situation. So any mitigation is better than what it's doing now imo.

I'd think that, upon detection of a tempo change, cross-fading between the old and new delay would be fairly unnoticeable. You'd spin up a new instance of delay with the new tempo setting, smoothly cross-fade over let's say 200ms, then discard the old instance. Just an idea from a non-expert. I've been in video games engineering for 25 years so lots of similar problems there...

I just switched the effect off for now so that "fixed" it for me.

[Teksonik]

Couldn't you automate the Delay On/Off in your DAW ? Send an Off right before the Tempo change automation and an On right after.

D3 042920.png

Is Dune 3's the only Delay that you've tested ? Also try your test with a VA Saw Wave instead of the WT Sine wave.

[Richard]

I'd think that, upon detection of a tempo change, cross-fading between the old and new delay would be fairly unnoticeable. You'd spin up a new instance of delay with the new tempo setting, smoothly cross-fade over let's say 200ms, then discard the old instance. Just an idea from a non-expert. I've been in video games engineering for 25 years so lots of similar problems there...

Certainly this can be done, the overlap or crossfade period will be audible though. Another, much bigger problem is that you can have a series of tempo changes coming in every tick. So there is not enough time to complete a crossfade & populate the new delay buffer, before the tempo changes again.

Anyway, if you come across a delay that handles every tempo change situation perfectly in your opinion, let us know, we are always looking for the best solutions possible

[pluranium]

In video games there is a similar problem with crossfading animations. The solution is a blend stack. You blend the first two instances, then the third with the result and so on. The delay instances could probably share the same buffer. But I agree this might be overkill.