Smoothly interpolate parameter / control changes.

[mixxxbot]

Reported by: ywwg
Date: 2012-11-22T17:15:22Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1082115

---

We need to add a utility crossover function to mixxx. That way when parameters change we can smoothly fade from one value to the other. The code would look like this:

if (new_val != old_val)
{
   buf1 = process(old_val); 
  buf2 = prcocess(new_val);
  output = util::crossfade(buf1, buf2);
}

This could be used in EQs, effects, faders, loops, cues, etc etc. For instance it would fix https://bugs.launchpad.net/mixxx/+bug/854082

It will increase CPU usage, but only when values are changing, and only for the changing values.

[mixxxbot]

Commented by: rryan
Date: 2012-11-23T16:52:48Z

---

This could be built into ControlObject transparently to the rest of Mixxx. You could set an easing function on a control along with a fade duration.

I think it would be negligible CPU impact but depending on the fade duration you put on a control it could add latency to individual controls. For example if you forced volume to interpolate from 0 to 1 then the duration you take to interpolate would be the latency between the control taking on the full value indicated by the user.

My suspicion is that to reduce discontinuities in the audio we only need a very mild small duration for controls like gain / volume / xfader / etc. Just something to keep the value from shifting dramatically.

[mixxxbot]

Commented by: daschuer
Date: 2012-11-23T23:07:14Z

---

It is not a pure CPU usage issue, its more a real time issue. We have ensure that we have the CPU in time.

When implementing it, please be aware not to overload the Qt event queue between the threads.
Mixxx is already suffering issues with the overloaded event queue, which results e.g. in waveform jerking an leak of reaktion to GUI controls.

Every additional timer driven QT event will make the things worse. We should consider to itroduce a time management based on the audo buffer / latency for the engine thread and based on the display refesh rate in the GUI thread. Maybe a third timer for MIDI (not sure). All other events should be derived from this timers, without preventing to process the following timer event in time in the next cycle.

[mixxxbot]

Commented by: pwhelan
Date: 2012-11-23T23:48:49Z

---

"We should consider to itroduce a time management based on the audo buffer / latency for the engine thread and based on the display refesh rate in the GUI thread. Maybe a third timer for MIDI (not sure). All other events should be derived from this timers, without preventing to process the following timer event in time in the next cycle."

I have been thinking of the same thing. It would also be great if we could also inject time delayed/repeated events into a control object queue that also works with the timer. That way we could possibly make scripts almost latency-free or at least latency consistent.

[mixxxbot]

Commented by: daschuer
Date: 2012-11-24T18:16:59Z

---

I think RJ put some good ideas ito lp:~mixxxdevelopers/mixxx/engine-control-refactor.

Are there some documents about the real time issues in Mixxx? Unfortunately all these things have a strong dependency, so maby its a good idea to collect them on a single place.

Is there already a place in our Wikki or should we create one?

[mixxxbot]

Commented by: daschuer
Date: 2013-01-02T07:10:46Z

---

Made some investigations about abrupt gain changes. The results can be found in Bug #⁠854082.