Pitch Shift effect causes a delay in playing track when enabled

[FrancescSunol]

Bug Description

When the "Pitch Shift" effect is enabled (by pressing the "Enable effect" button), the playing track suffers a delay of some fraction of a second.

As a consequence, when 2 tracks are playing together in sync, activating the pitch shift effect (even when the metaknob is at minimum) results in the lose of sync.

How to reproduce:

1. Play 2 tracks in sync.
2. Activate the "Pitch Shift" effect in one of them (by either the effects rack, or by the Quick effect Superknob). The 2 tracks are now not in sync.

Version

2.4.0-beta

OS

Debian 11.7

[Swiftb0y]

Yes, that's an unfortunate consequence of pitch shifting algorithm. The effect introduces latency which is very difficult to compensate for due to it being used in real time. The pitch shift within the deck itself does not have to be as real-time because the input is much more predictable and thus we can use more trickery to compensate that. Those tricks can't really be applied to the real-time effect. So see the pitch shift effect less as a pure pitch shift but a pitch shift with built-in delay :wink:

[Swiftb0y]

I assume by the "loss of sync" you just mean audible sync, right? Eg. they play together again when you disable the effect.

[FrancescSunol]

Yes I mean audible sync, and yes they recover sync once the effect is disabled :)

[daschuer]

We cannot undo the group delay in such a real-time condition. But we can work around it. One common solution is to report the group delay and apply it to the other channels a well. Depending on you use case we may also remote control EngineBuffer to apply the effect to the buffered data, or apply the offset there.

Why you don't use the pitch shift feature in the Mixer for your use case?

[FrancescSunol]

Why you don't use the pitch shift feature in the Mixer for your use case?

Yeah that pitch shift doesn't add any perceptible delay, but the whole puropose of the pitch shift effect makes a lot of sense since it would be great to have a pitch shift effect where the pitch and range can be controlled using knobs.

[daschuer]

Are you fluent in C++ or any other language? Than you may implement our old "transport effects" idea.

This is an effect that remote controls the EngineBuffer that is responsible for the track transport. It allows to the effect region of your controller for temporary accessing advanced transport controls that are normall not accessible or have smaller range than desired.

In you case the first Version might just control the "pitch" and "pitch_adjust" controls, that are probably not part of your mapping. It may also feature an "rate_ultra" control as proposed in #1767

Do you have interest to look into that?

[FrancescSunol]

@daschuer, I don't know C++, anyway if I had time to invest into mixxx development I would focus my efforts on the Echo effect rather than on this (I just reported the bug) since I have much more interest in changing the behavior of the current Echo effect (for example, we can't apply additional effects on the echo tail uniquely, without affecting the whole track). I will open a feature request when I have time to write it down appropriately.

[CaMeLCaseError]

one aspect to consider with the delay is also the cross fader (and channel faders) becoming delayed in their effect and thus pretty hard to control. Since all effects are applied post fader this seems unavoidable. it might make sense to put the pitch shifter pre fader so at least a quick cut with the fader is still possible.

[ronso0]

Related: #9094 not that easy...