Latch mode with tempo sync goes out of sync

[K0rrid0r]

Describe the bug I always felt something was off with the tempo sync in latch mode (also during my live gigs one usage with surge was as an effect with latch mode on and then LFOing the filter sliders this could for example be used on top of a hardware synth that was synced with gate trigs also from FL etc)

I remember "fixing" this by retriggering surge at some point even if it was in latch mode, so that made me forget this bug, until today. Now this morning i finally did a proper test, and yeah.. Latch mode with tempo sync actually goes out of sync.

And @baconpaul this reminds me of the MSEG sync bug you fixed recently. Could it be something in the nature of that? Phase overflow again?

Here is a 10 minute youtube test sync film i uploaded just to show the problem. Test was done with 1/4 dotted. https://youtu.be/TelDmQicV44

What we want is the tempo sync to sound just like it does the first seconds when the kick comes in when i click play. Already at 15-20 seconds you start to hear it is slowly progressing off more and more. After 10 minutes its just completely off.

Here if the surge patch from the film tech bell 1.zip

Please let us know your surge version hash f704465

[baconpaul]

So this problem isn't a phase accumulation. It's much nastier than that and I'm not sure of a fix yet. The problem is truncation of the rate accumulating over very long time periods.

With a quarter note, you get a rate.f of -2 and then a rate of 0.000166666667

that accumulates over time

I think I need to tackle this with a retest. Probably what we need to do is not use envelope_rate_linear_nowrap which linearly interpolates 1/k. All that truncation.

So let me ponder this one. I'll start with an automated test so I don't have to wait 10 minutes. But this fix is not easy like some of the other phase overflows.

[baconpaul]

@K0rrid0r can you try something for me? In LfoModulationSource.cpp replaces this like, around like 298

   float frate = envelope_rate_linear_nowrap(-localcopy[rate].f);

with

   double xx = -localcopy[rate].f;
   xx *= 16;
   xx += 256;
   double k = dsamplerate_os * pow(2.0, ((xx - 256.0) / 16.0)) / (double)BLOCK_SIZE_OS;
   double frate = 1.0 / k;

and see if you still gt the drift? There's one of two reasons and that will help me out a lot. Thanks!

[mkruselj]

See, I knew this one was trickier than the other ones ;)

[baconpaul]

yeah but it is a big problem if it is what I think

[baconpaul]

@K0rrid0r I edited to use double rather than float. That's important.

[baconpaul]

btw very cool patch.

[mkruselj]

Yeah, these sorts of drifts are usually not an easy affair...

[baconpaul]

With the change above in LPX at 110bpm at minute 04:25 I am still perfectly syncopated against the metronome

Will leave it run through dinner.

[baconpaul]

Yup made it to 19 minutes with no drift.

So the problem here is accumulated error on the float approximation of 2^x.

Will ponder.

[baconpaul]

OK @K0rrid0r can you check baconpaul/drift-2675 and confirm? I think it fixes it for me but would like you to look also.

If so that branch is mergeable.

[K0rrid0r]

@baconpaul This was a very old problem from 1.5.2 days!

The baconpaul/drift-2675 branch plays perfectly tempo synced, honestly great fix!

Merge!

[K0rrid0r]

The tempo sync still drifts using it in this way but much slower. which is a good improvement, but not perfect.

Paul suggested another algorithm is needed in order to get out of the accumulated errors in the current algorithm

https://en.wikipedia.org/wiki/Kahan_summation_algorithm

[baconpaul]

Nah that's not the fix. (That's only the case if you accumulate, which we do, but also we loop phase, so it doesn't apply).