High-pitched noise with RR group XFades with low buffer sizes
-
@tomekslesicki Hmm, I can't hear it, the example sounds fine and I can't spot a difference going between 64 and 512 (or the saw tooth does at least cover the artifacts).
What you're describing would be a problem of a control rate resolution issue (so that the gain value is only added constantly for a buffer like if you're poorly modulating stuff in scriptnode), but the crossfade gain values are calculated as audio signal and are applied to each sample (if the modulation is time-variant).
Can you upload an example of how it sounds on your system with the different buffer sizes (you can use Tools -> Record one second audio file to quickly capture the HISE output and dump it on the desktop).
-
@Christoph-Hart sure, here are some bounces for you:
64 buffer.mp3
32 buffer.mp3
128 buffer.mp3
256 buffer.mp3The glitch appears at the very start of the files. At 256, it's inaudible.
And some spectral views from RX:
Buffer 256:
https://imgur.com/OuIB6vkBuffer at 32:
https://imgur.com/3SE8eeaThe artifact appears where the crossfade takes place.
-
@tomekslesicki They sound exactly the same to me, but I'm not in my studio so I can't hear it on the speakers, just my AirPods.
Can you reproduce it with a less harmonic content? Usually these effects are best displayed with sine (or triangle) waves but the sawtooth kind of masks anything that might be going on.
Also does the problem go away when you increase the attack time?
-
@Christoph-Hart ok, try these instead, they should be more obvious. I replaced the sawtooth with a sample with less harmonics, and adjusted the xfade tables to showcase the problem in a more in-your-face way:
Test 2 buffer 64.mp3
Test 2 buffer 128.mp3
Test 2 buffer 256.mp3
Test 2 buffer 512.mp3
Test 2 buffer 1024.mp3The problem is still there, even at 512 and 1024 when the modulation gets slower - listen to the entire files, they're not super long, and will hopefully give you a sense of what's going on.
The xfade tables are set like so:
Group 1:
Group 2:
Updated snippet:
HiseSnippet 1262.3oc4X0saaaCElJNLs1qMcsnWraFftXWjhTjZm37G1EyI9mFiZGaX4zkbUAiDsMWjIEnnbh6v.1iztZW28JrWg8Br2fMRIYaJG21Til.WTcgfN+Q9wy4vCOTM4LaruOiCLR2dnGFX7.n0PpnWwdHBETsDv3dvSqfbvfCG5g78wN.CiTuTIzH8xfvm+8mND4hn13Ir.fWyH13Zj9DwDtMK7JhqqZzZS5qoc9BUsYzhLWVfDHofYAdH6KPcwGiTpsDDXrRYGhfwsDHA1GXr7gLmgV8XWRiz+0Dex4tXEQNfkbfhXWg45nPrhKnXOhqSyQKXe.v.1bxxOUzx+ov5DGxX9SbCean.yIVn6OLVJI7Rk.d4zgWVM3MCHYnAokifzigV1bhmXhDEd9FXUp.y6frSFZhzEX72vhLoBTwF8QWfqvkDiMXscxl84lxWO6Gyj4EuvrYqxVVlE2z73FsK2IfZKHLpIidLSfaPW6YY90Loy7aYLmVTmNyTlZh4LWWLelhUwd9Gxv0nA8OGyet4.ja.drhRGRRuL786k0SBri7CZJxnUoDQCOL88kZ.hcdxuNoZIj.oBMw7j54g4BhBBFkvCj44QApzvRX+KDLOYl90hhx7GlSfKRjLoRsSJVfzGjHRpBWTehXn9NsOaYZ2TH9XXShvt2rw3Ry.iRO0sAFi2e9PX4Ncv1hI.bYXkSuc1LpO8eezz+DnkfiQ8IztVn9dxT7PLjAFSk6yQYRuabYxlbrKC4XQdqlZuqvgAReDOI2+nP3TcPeV.MwbEi7VXOLRHCyZ1b+BsZ8RNKvaZq.EBSJZykkoktB80XCJV5q00ETjy786HWNgikut1MC3cU9pIJ2BO.y8Sx63f9x3MkhcU65MLT6J8wp3KwtNRvIWoqc3rjsMJLF+mvbas4Fie1un70fFVux+s6Ml4fF0u5Hq80jeJduK1WStT8qzk6rU200kWkTqx5ZxK0X2ZqqI2dXcKc4mbxImoKW9pit7n0PtYuFhsoxY+xk6oYSqJm0VGSmKx6pi4F6NXnt7KK1XC84baWTEcLQpcUMc4Jejt7b+L9Lc4iWCwxiVCaFuFjmgGRu0Tz4mhd6on2YJ5cmPGk3VG4E0kxUpLrqcFwJ2ryHjiRSjL+RSyCIcGOCQb9HcSrxBW2DeAbLThFdROBiVDkiuLcfr7ljiBiOQd3ZGTfqXD2jkZqynLudLJwNYwDYwgtcwbcrOyEzABgrV1DNOsPKrKF4qUM7GJTiPwHdxZjeR9hbexM+My302Aifqo57AyubaeH0WMsO7gbQqF27fobF4hEvX3CfgkdMu10.uCKM7nH7cO3AGUxpUbpU32l2lEDJFvGjnesRXazvqwMY0ie+e9qBQbpIalwUWwijGgnWQIb3Fy3c7BVA9hDcMpv7TEhxWnrM61qJD7FlV7P8pPKfosqNBeQQgEw8Ugg+EU+2ifwIiKrNvUgw6MtycgsXAB4EeFc4Cn7FJVxakYi0umxRp69DQmUQq.gEl5DR7exmXg4FcoFkvbiDBrGMTx0S72g+IBiTXppI3vKf6NcEFe4c+TPR1f7cBJ6ir4r2XG8maTX89gbjnjF9y6RCqqnMyAB+aN5PsurE32XambntlgaNuFt07ZX940vsmWC2YdMb240v893FptgxAABV+n91.f5MKGk.ZTdbBXJv+Cr2bdeJIt doesn't matter what is modulating the xfade - LFO, envelope and scriptnode modulators all create the same issue.
-
Hmm, I can't replicate it here, it sounds like this:
(it's with 64 samples buffer size, but it doesn't change with other settings). Does the sample rate have an effect on the artifacts? This doesn't sound like zipper noise of a poorly control rate but rather some resampling issue.
Can you upload a short file with raw PCM (not mp3), then I can look at the waveform to spot some irregularities (I don't trust the MP3 codec not to mess with the artifacts with their psychoacoustic compression techniques)?
-
nevermind, I followed my own advice and replaced the sawtooth with a slightly saturated sine and now I can hear it.
Sometimes I'm so smart it hurts... alright, now onto the debugging...
-
... And it's gone.
It was in fact an issue with a too low threshold (60dB) for detecting whether to use the full modulation signal or just a single value for performance reasons. I upped it up to -80dB and now it's basically inaudible.
Let me know if that problem persists with your real-world project, then I'll add a custom preprocessor where you can define a threshold for the detection - it's used in a few other places, just search the codebase for
0.001and look for comparisons.There was another related thread a few weeks ago about the AHDSR silence threshold so maybe it might be a good thing if this was customizable without hacking in the HISE Source code.
-
@Christoph-Hart thanks so much, I'm going to check this later today!
And I'm all-in for customizeable silence thresholds!!!
-
@Christoph-Hart I noticed you just added the HISE_SILENCE_THRESHOLD_DB preprocessor, thanks! :-) Could you please tell me about the value logic? For example, if I'll build HISE with:
HISE_SILENCE_THRESHOLD_DB=100the threshold will be set at -100db, or should I rather build with
HISE_SILENCE_THRESHOLD_DB=-100instead?
-
-
This is in the comment of the preprocessor:
but you can override this (as a positive value, it will calculate the gain factor by taking the
number as negative dB value and convert it to a gain factor)But it doesn't use this value for the crossfade detection (I've still hardcoded the -80dB) there, so you don't need to change this preprocessor to fix your issue.
Edit: Dave was faster :)
-
@Christoph-Hart @d-healey thank you!
I just tested the latest commit and it's indeed way better, but I'm still getting a bit of the buzz when the envelope gets to the curved part (so when the modulation slows down). Could you please bring it down a little bit more, or add the xfade threshold as a preprocessor so I can experiment with this myself?
-
@tomekslesicki you can just change the location I modified in the commit and use an even smaller number above zero, then let me know what you end up with :)
-
@Christoph-Hart well, that was a logical answer :D I built a couple of versions with different values and 0.00000000001f works prefect for all buffer sizes.
-
@tomekslesicki said in High-pitched noise with RR group XFades with low buffer sizes:
0.00000000001f
That's some precision!
Libre Wave - Freedom respecting instruments and effects
My Patreon - HISE tutorials
YouTube Channel - Public HISE tutorials -
0.00000000001fhaha this is basically zero with the single precision resolution of seven digits... You're effectively just deactivating the logic that will save you CPU cycles when there is nothing going on in the modulation signal.
I guess I'll rather make a preprocessor like
HISE_ENABLE_CROSSFADE_MODULATION_THRESHOLDand if that is set to true, it uses the -80dB threshold that gets rid of most artifacts and if that's not enough for your particular project you can disable it entirely by setting this to zero. -
@Christoph-Hart sounds like a good plan! ;-) By setting it to 0, you mean something like this?
HISE_ENABLE_CROSSFADE_MODULATION_THRESHOLD=0 -
@tomekslesicki yes. Also you then can just leave it as default in HISE and just add that to your project definitions (if you can live with the low artifacts at -80dB during development), this way you don't have to edit the source code at all.
-
@Christoph-Hart epic, thank you!
-
@Christoph-Hart we don't have this HISE_ENABLE_CROSSFADE_MODULATION_THRESHOLD yet, right?
