-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Portamento ST mode does not go all the way to zero #7224
Comments
Thanks for reporting! This is suspiciously similar to 6984, I wonder if something has regressed that. Investigation needed. |
Yeah thanks for the excellent report I wonder where the lag is coming from. Something - at least in modern - must be lagged too aggressively. With this report it should be straight forward to at least diagnose it. |
Ahh I see exactly why this happens with modern. It is a remnant of the original version of the algorithm which is no longer needed. Let me see if I can at least clean up that branch. |
addresses surge-synthesizer#7224 The original version of Modern used the trailing three points for the derivative, but didnt' recaclulate all three at once. This meant it was a bit unstable under extreme pitch changes so we used a lag/lpf on pitch and dphase. We subsequently changed the algorithm to always calculate the trailing three points but never undid that lag, leading to low porta high shift having an audible sweep in modern, as reported in surge-synthesizer#7224. This change fixes that and simply block smooths pitch shifts.
Initial investigation on the filter is: it is not the key track being smoothed. the filter gets the cutoff reset immediately. The filter does have history (it is a filter after all) and I wonder if that's what's actually smoothing the self oscillation. |
OK the filter is getting reset immediately but the algorithm has enough history that there's a small lag. the coefficients reset instantly though. So to understand the filter behavior gotta wade through this
and turn it into math and understand how to make it have less hysteresis when self oscillating. It seems. So either i'm wrong about that and there's a lag elsewhere (but I did a print-when-coefs chang and they are instant) or I'm right about that. In either case: not today! |
That's the parallel intrinsics stuff right? Looks intimidating... Anyway, nice about the modern fix! |
addresses #7224 The original version of Modern used the trailing three points for the derivative, but didnt' recaclulate all three at once. This meant it was a bit unstable under extreme pitch changes so we used a lag/lpf on pitch and dphase. We subsequently changed the algorithm to always calculate the trailing three points but never undid that lag, leading to low porta high shift having an audible sweep in modern, as reported in #7224. This change fixes that and simply block smooths pitch shifts.
yeah its not that hard to read just you need to do it. then figure out the math. putting it here for when i stumble on it next. My guess is the filter has enough history that it takes its time adjusting state. It is a low pass filter after all. But I can't demonstrate that. What I was able to show is that the inputs to configure the filter snap immediately, and there's no other code lagging in the way. So I think the lag is in the math on that. |
|
{
F1 = C[0]; Q1 = C[1];
L = R[1] + F1 * R[0];
H = in - L - Q1 * R[0];
B = F[0]+ F1 * H;
L2 = L + F1 * B;
H2 = in - L2 - Q1 * B;
B2 = B + F1 * H2;
R[0] = B2 * R[2];
R[1] = L2 * R[2];
R2 = max(0.1, 1 - C[2] * B * B);
return L2 * C[3]; // C[3] is 'gain' in the comments
} so when that is self oscillating what's the lag under coefficient change? The C[0] etc.. are all set in the coefficient maker. Not obvious. |
well ≈512 samples, I guess judging by Sintels report. But indeed, it's not obvious why that should be so. Lemme try if it's different at blocksize 8 just for good measure. |
no. there's a slightly different coefficient restatement speed but that's block size nothing else. and the statements are just math so they work same on intel and arm. that's with the filter patch? the modern problem was a legit one though and is now fixed in nightly. |
Ok, that wouldn't be it then. Yeah that's the filter patch. I tried with a bandpass too and it was also quick. It's late here and I'm not gonna compile a block size 32 Surge to test with, but other than that and windows IDK what would be different between Sintels setup and mine. Weird. |
I used print statements didn’t even scope it I have an 8 16 and 32 build all set up in my ide so can peek tomorrow when I have my laptop open next thanks so much for looking. I can’t believe I didn’t! |
No worries. Catch ya tomorrow. |
Can confirm on latest nightly modern osc is fixed! |
OK I'll try and reproduce this week. That's useful information. It means something is slewing your key track. But I don't see in the code what that could be and it didn't happen when I tried it. Glad Modern is fixed! Great find on that. Thanks. |
I have had to revert the modern change since it causes pops under extreme modulation, which it shouldn't do but did. Demonstrating patches there for further investigation. |
Bug Description:
When setting portamento time to 0ms in ST mode, there is still noticable portamento on some oscillator and filter types.
For self-oscillating filters it is much longer than 32 samples so I don't think it is related to internal block size.
This also happens on 'modern' oscillator type, but not on wavetable or classic.
I have attached two patches: self osc.fxp and modern.fxp that demonstrate the issue, as well as exported samples and screenshots highlighting the issue in Audacity.
report.zip
Surge XT Version
Version: Surge XT 1.3.nightly.2405dfd
Build: 2023-09-27 @ 15:01:20 on 'fv-az407-912/pipeline' with 'MSVC-19.35.32217.1' using JUCE 7.0.5
System: Windows 64-bit VST3 on AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx
Host: Ableton Live 11 @ 44.1 kHz / Process block size: 32 samples
Reproduction Steps:
Steps to reproduce the behavior:
(see patch in attach)
Expected Behavior:
Instantaneous change - or at least on the order of 32 samples.
Screenshots:
Computer Information:
Additional Information:
Related:
#6984
#6986
The text was updated successfully, but these errors were encountered: