Spring Reverb -nanV

[ContemporaryInsanity]

I have a String VCO into Filter into Spring Reverb, this is randomised by Stoermeldder Strip. After several instances of randomisation, Spring Reverb outputs constant -nanV.

This is easily reproducable.

[baconpaul]

Ahh I guess those spring reverb filters are less stable under extreme modulation than we thought! Lemme tag in @jatinchowdhury18 too

it may be the same problem we fixed in the exciter where surgr vst uses half amp signals at fx. I wonder if it is the input jump or the parameter jump. Is it possible to randomize the string and filter but not the reverb and if so does it still nan out?

thanks as always for the clear report

[ContemporaryInsanity]

"Is it possible to randomize the string and filter but not the reverb and if so does it still nan out?"

Still fails. I also noticed what I'm pretty sure was a -nanV out from Filter momentarily, but that recovered, unlike the verb.

[ContemporaryInsanity]

Only randomising the String VCO is fine, so it seems Filter falls over on parameter jump, spits out -nan, which screws the verb, the filter then recovers, the verb doesn't.

[baconpaul]

Thank you

I should probably add an every 128 blocks nan check and reset to the filters waveshapers and fx in general - rack can modulate them more violently than the vst

but I will add it to the list for next release and maybe sneak that nan check into a nightky before that in case we do a 2.1.2

[baconpaul]

Hmmn I just pressed random on strip in this configuration for 4 minutes and got no nans either on ARM or X86 mac.

Do you have the original patch which was throwing nans? Also you are on linux right?

[ContemporaryInsanity]

Interesting.

I'm on d66e157 under linux. For some reason it's taking a lot longer to fall over than before, but it finally has having fed Strip randomise a clock for a minute or three.

Run it with the clock and you'll see filter fall over and recover, verb get stuck.

[ContemporaryInsanity]

But yeah, exact same set of modules, frequency of failure has gone way down.

[baconpaul]

ahh the clock is a good tip

yeah on x86 with a clock i can get spring reverb to fall over after a few minutes

[baconpaul]

Sigh I just left it running for 45 minutes with a fast clock andndidnt catch a nan again

I think I’m gonna fix this by adding a stress signal test module to baconplugs then see if I can force the module into nan with a pattern. Then I will be able to test recovery. But that’s not a quick fix today so I am going to push this out of the 2.1.2 micro release and leave it open

[ContemporaryInsanity]

I made one of those in v1, Module From Hell. The guts:

    outputs[MINF_OUT].setChannels(16);
    outputs[PINF_OUT].setChannels(16);
    outputs[NAN_OUT].setChannels(16);
    outputs[VOLTAGE_OUT].setChannels(16);
    outputs[EVIL_OUT].setChannels(16);

    for(int c = 0; c < 16; c++) {
        outputs[MINF_OUT].setVoltage(-INFINITY, c);
        outputs[PINF_OUT].setVoltage(INFINITY, c);
        outputs[NAN_OUT].setVoltage(NAN, c);
        outputs[VOLTAGE_OUT].setVoltage(params[VOLTAGE_KNOB].getValue(), c);

        switch(rand() % 6) {
            case 0: outputs[EVIL_OUT].setVoltage(-INFINITY, c); break;
            case 1: outputs[EVIL_OUT].setVoltage(INFINITY, c);  break;
            case 2: outputs[EVIL_OUT].setVoltage(-666.666f, c); break;
            case 3: outputs[EVIL_OUT].setVoltage(666.666f, c);  break;
            case 4: outputs[EVIL_OUT].setVoltage(NAN, c);       break;
            default: outputs[EVIL_OUT].setVoltage(rand(), c);
        }

If something like that doesn't kill it nothing will :)

[baconpaul]

Ha yeah indeed.

[baconpaul]

So I still can't trap this. What I'm going to do for XT 2.2 (coming in Dec) is add a NAN check every 32 blocks or so which resets the effect if it does NAN out. I'll close this issue once that's there. It will only be on for spring reverb since that's the only one reported with this problem so far but it's just a template arg for other FX if we want