NAN with Multiple Envelope Follower in Single Core Macro

weissmf

Hey everyone,

I am trying to build an external audio effects processor and running into some mystery problems. I'm using a couple of Envelope Followers within a core macro that are part of a multi-stage audio process wherein the signal gets analyzed by EF #1, gets modified based on EF output, then proceeds to EF #2 which in turns controls audio modifiers downstream. What I am running into is a situation where EF #1 works fine, but EF #2 consistently returns an NAN output. I've tried switching out the core cell numerous times between the different library EF's, Peak Detectors, and so on. Each time the same behavior. I've also verified the that EF core cells have implemented a DNC internally. Any ideas what is going on?? Thank you!!!

bolabo

Can you post the ensemble here?

weissmf

Hello Bolabo – Thank you for responding! The entire Ensemble itself is a bit of a sprawl, but here is the Macro in question. It is basically a 3-part wavefolder. If you look inside, it should be fairly straightforward to see what is going on. One point to mention is that there is a 3rd EF signal that is coming into the Macro at the beginning ("GTR EF") as a scoped bus. I have replaced that connection with its own EF ("EF #0") for the sake of posting it here.

OK – after extracting the Macro and placing it in its own ensemble at the highest structure level below panel . . . now it's working. LOL. What the heck. I am wondering if the problems I have been encountering have to do with how far down the EFs are in the structure?

NAN issue with EF #2.ens

weissmf

OK, quick update: it seems to be doing the same NAN behavior in this excerpt ensemble, too. If you adjust the knobs, the NAN will kick in.

colB

Its a divide by zero error. Your knobs go from zero to 1. So when e.g. tone 1 is at zero, the logic in the first 'mirror fold' module forces a divide by zero which will throw and inf. If you stick an inf through a feedback loop, you get a NaN... something like that.. The output of the first fold goes into an envelope follower with a feedback loop...

If Tone1 is at zero, 1:mod1 is zero.

1: zero * anything = zero

2: zero - zero * anything + zero = zero

3: 1 / zero = inf

Obvious solution is to clip min the Mod values to some positive non zero value... or use a test before the divide to prevent the divide to prevent it if the divisor is zero...

weissmf

Thank you, colB! I really appreciate your taking the time to respond. I am a big fan of your work over the years. And also your commentary on the various threads.

OK so you are correct about the divide by zero issue in the ENS I posted. This was sloppy on my part! In the original ensemble, I have a set of four knobs controlling other sets of knobs whose values are appropriately calibrated from 1 ("min") to .001 ("max"). So I have actually anticipated and solved that problem already in the original ensemble.

But here's the deal – even though the knobs are properly calibrated in the original ensemble, I still get NAN. The issue seems to originate in EF #2. It seems to arise in the feedback loop within that Macro. And this only happens in the EF #2. It doesn't happen in the first one in the series. Here is a screenshot of the EF #2. Again, the zero values are not an issue because in the original ensemble I have accounted for this in the knob calibration. Please let me know if more info would be helpful.

colB

If I limit the knob inputs on the ensemble you posted, I don't get NaNs any more.

To take this further, you will need to post an ensemble that exhibits the problem in a repeatable fashion. (one where it only happens intermittently every 20 minutes or every hour isn't going to be useful ;-))

I would suggest if it's intermittent, that you wrap those divisions in a zero test and see if that stops the issue.

Also note that its common to see a NaN in a feedback loop, but that doesn't mean that it started there, it's just that if one gets to a feedback loop, it will never leave. However it could have originated somewhere upstream of the feedback loop.

weissmf

Thank you, colB! Really appreciate your taking the time on this.

Yes, I recalibrated the knobs on the test ensemble and the NAN issue stopped on my end, too. However, it persists in the original ensemble, which I have attached here.

I believe that the ENS will open to Macro in question, but, if it doesn't, it's under SYNTHESIZER>OSCILLATOR>TONE>FOLD.

You'll see that the wave folding operation is organized into three lines, more or less. The first line is controlled by an external EF ("GTR EF") that's routed in by scoped bus. The second line is controlled by "EF #1" which is part of the Macro. And the third line is controlled by "EF #2" which is also part of the macro. If you turn the ensemble on, you'll note a couple of issues: 1) audio is intermittent and seems to blink in and out depending upon whether certain macros are in focus or open (not sure what this is about); 2) The first and second lines of waveshaping work OK if you wire them directly to the output, but the third line returns NAN messages and won't produce audio.

Here's another screenshot for reference.

It's a mystery :) Thank you for your help!

30.2.ens

weissmf

OK, another quick update.

1. I recalibrated the "SENS" knob so the minimum is .001. Previously, I did not believe that it would cause an issue because it is only potentially adding zero values to the overall "limit" value of the wave folder. But it does seem to have some mysterious effect, and setting the minimum to .001 seems to help . . . somewhat.
2. I goofed and the third line of the wave folder is not wired up properly. My apologies. Below is a screenshot of the proper wiring.

Finally, there is something about clicking into the EF #2 structure and then clicking back out into the FOLD macro that seems to get the NAN error "unstuck."

colB

try this:

The DC filter is causing issues, I think on initialisation. You could fix it, maybe just by switching out the arithmetic for mod math macros, but for now, just swap out the whole thing with a factory high pass with very low cutoff - that's all a DC filter is anyway!

Not sure that completely fixes your issues, but it takes away one source of NaN

colB

OK, changing the coefficients from 1 and -1 to 0.9999 and -0.9999 in the DC Filter seemed to fix the issue. I guess there was some sort of numerical explosion on initialisation due to numerical error causing a greater than 1 value in the feedback, or something, very quickly getting beyond the limits of 32bit floats hence 'not a number' that can be represented. not usually a good idea to max out coefficients like that... I would stick with the factory 1 pole though - not sure how changing the coefficients will effect the cutoff. Should be OK, but I don't know for sure... so :-p

weissmf

colB – thank you so much. Really appreciate your help here. Seems like you are on the right track with this solution. I have noticed some weird behavior with that DC filter but I left in there anyhow . . . not even sure where I found it. But swapping it out with the 1P HP seems like the way to go. I will do that and hopefully it takes care of the issue! Thanks again – Best, Michael