Denormal Noise is visible out the back of Surge

[baconpaul]

This was a DeRez problem with loads of investigation

I was able to fix DeRez in 04e38b3 but the small value 1e-15 noise which is there to fight denodm problems still causes a problem

I think the @mynameismuhl fix along with our FTZ flags mean we are fine to set it to 1e-25 and I will do that once we ship XT1.0 but too late in cycle for that now.

---

1. Fresh session
2. Load up "TNMG/Sequences/One Node IDM" <- do you hear a glitch at 'load'
3. Toggle th enext patch button forward and back (so unload and reload One Note IDM). <- Do you hear a glitch at 'load'
4. Bypass all FX (so put FX bylass all the way to 'all') and then repeat step 3. Does the sound go away?

it seems to be the airwindows derez

[baconpaul]

This happens even in init sine with derez in slot 1

[ghost]

This may be a red herring but it looks related:

With either DeRez loaded in Surge
or the DeRez2 VST on the same track after Surge
(init saw, no sound playing)
lowering Resolution/Rez slider
at 44.1kHz I see this peak at quater samplerate/half nyquist:

which disappears if and as long as a note is played
This happens only in combination with Surge (XT and 1.9).
(not with dexed or ob-xd)

With only Surge on a track,
(init saw, no sound playing and no FX)
I see this on a bit meter:

could this be responsible for the excitation?
(and what is it?)

[mkruselj]

That's probably what is causing the excitation indeed. As to what it is, who knows...

I noticed another weird thing: the bit pattern changes if you mute ALL oscillators and press a key!

[ghost]

...or deactivate the highpass filter.
and loading either Combulator, Ringmod, Ensemble, Resonator or bit glitter as global FX
"silences" the bit meter.

[baconpaul]

Let me just tag in @airwindows here

Chris - derez2 makes noise when we load it. We don't know why. Any thoughts?

[mkruselj]

It seems Surge is creating something in the very high bits of double precision float for no reason. This is before loading any effect at all. I tried a dozen other synths over here and none of them do this. Weird.

[baconpaul]

wierd
surge is all floats all the way out to the interface coding wise. where does it get converted to double I wonder?

[mkruselj]

I don't know, but 1.9 is behaving exactly the same!

[ghost]

This is Surge doing nothing with the same peak at inaudible level.
When I'm truncating Surges output to 48bit it is gone.

I think the bitcrusher in DeRez (and other bitcrushers)
just brings that to an audible level but is not the problem itself.

[baconpaul]

so surge is float (32 bit) through the entire pipeline
i wonder what's reconstructing the noise in these higher order bits
i don't even have an option to set them! I just get an AudioBuffer and push the floats onto it.

[mkruselj]

You can use this free bit meter plugin in any host:

https://www.stillwellaudio.com/plugins/bitter/

rather than rely on Reaper-specific JS effect.

[mkruselj]

So it turned out this is caused by clear_block_antidenormal_noise(). But that is there for a reason (otherwise patches with long reverbs and delays will grind CPU for far too long while calculating denormals all the time).

BUT other plugins also fight denormals, and don't exhibit this behavior. Hmmm....

[mkruselj]

It seems there's not much we can do about this issue. At least not in the current milestone, so pushing it out to Currently Unscheduled.

[ghost]

lowering smallvalue in antidenormalnoise (basic_dsp.cpp) to 1e-25 helped to keep the problem
surge internal, meaning plugins (bitcrushers) running on a track post surge don't pick up
the noise shown above anymore.

If I change the clear_block_antidenormalnoise() occurences in SurgeSynthesizer.cpp
to clear_block() the problem is gone.

I clearly don't understand the process enough but seeing that denormals are flushed
in various places in surge I still wonder if the noise isn't redundant?

I tested a lot back and forth and I don't see the "cpu hogging" @mkruselj mentioned with these changes.
Since we're both intel might there be a difference in compiler optimization? (clang 12 here).

[baconpaul]

So this is really interesting and gives me an idea
I wonder if we should clear_block until the first noise is made by the synth post engine halt, and clear block with noise after that

[baconpaul]

Yeah so this is entirely in the derez warmup

If I put this in SurgeSynth

static int i = 0;
    auto clearfunc = clear_block_antidenormalnoise;
    if (i < 100)
    {
        clearfunc = clear_block;
        i++;
    }

and call clearfunc rather than clearfunc antinoise the startup load of one note idm makes no noise (and a subsequent shift does, because of that static).

So I think 'don't warm up the fx with noise' may be the answer here.

let me see if i can bodge that in.