Lb302: Consistent decay in time

[michaelgregorius]

The previous implementation of Lb302`s decay used a fixed decay factor that was multiplied with the signal until the minimum threshold of 1/65536 was crossed. This fixed factor resulted in different lengths in time for different sample rates.

This is fixed by computing the decay factor by taking the sample rate into account as well. The new static method computeDecayFactor computes the factor that is needed to make a signal decay from 1 to a given attenuation over a given time.

The parameters used in the call to that method in Lb302Synth::process have been fine-tuned such that, at a sample rate of 44.1 kHz, they result in a factor very close to the previous hard-coded factor of 0.99897516.

[zonkmachine]

This seem to work fine but I bumped into a couple of issues that makes the PR a bit hard to test.
There seem to be an issue where lb302 (and perhaps it's not isolated to this instrument) doesn't export at the same phase. The tracks are almost identical but seem to start at a different point in time. This does not originate from this PR but makes the tracks a bit difficult to compare. It may or may not relate to whether the track is reset by loading the project in afresh or not but I need to test if more. I've also caught a glitch that only popped up two times (but on the same export) where a segment is replaced by just a straight line and then the missing part seem to be mixed in a bit later. It's been teleported. Might want to keep an eye on this

lb302 timing

lb302 buffer teleport

[zonkmachine]

Looks good. Tested, exports fine at different sample rates. Fine that is, except from the issues reported earlier in the thread.

[michaelgregorius]

@zonkmachine, thanks for testing! The phasing issue will likely be caused by the attack which is still hard-coded to the following value in the constructor:

vca_attack(1.0 - 0.96406088)

The attack code looks a bit more complicated, so I am not sure if it can be fixed in the same way. It already seems to somewhat take the sample rate into account though:

if(sample_cnt>=0.5*Engine::audioEngine()->processingSampleRate())
				vca_mode = VcaMode::Idle

[michaelgregorius]

The phasing issue seems to be already present in master. Here's a screenshot that compares two exports that have been done in master (at commit 8636381) with the amplification not being applied to the signal. The first is at 44.1 kHz and the second at 192 kHz:

I guess it is caused by the filter which might not be aware of sample rate either.

Edit: the wobbly start at the 192 kHz export is caused by the filter which is excited with a step. See results about the band-limited oscillator below.

The filter does not seem to be aware of sample rate nevertheless.

[michaelgregorius]

The phasing problem is already present in the raw signal. Here's 44.1 kHz and 192 kHz in master with no filtering and no amplification, i.e. the raw signal:

So it might be something with the band-limited oscillators which my test project uses.

[michaelgregorius]

It's the band-limited oscillator. Here's the raw output with the naive saw:

[zonkmachine]

OK. I'm not sure what all this means but none of it seem really related to this PR.

[michaelgregorius]

It seems that the problem with the phase is caused by the Lb302 instance keeping some state. I have exported two times at 192 kHz. With the first export the signal starts at 0 (phase 0). The second time it starts "in the middle" as seen in the screenshot above.

[michaelgregorius]

OK. I'm not sure what all this means but none of it seem really related to this PR.

Yes, it indeed seems unrelated. Shall I merge this one?

[zonkmachine]

Shall I merge this one?

Yes.