Started a discussion of FB.
@synthi was saying that Complex Simpler might be better protected from NANs than Confusing Simpler, but they both seem to trigger something nasty that affects the cascaded Vult Freak filters that follow it but apparently Complex Simpler also goes to ‘stuck NaN’ outputs.
Also affecting Nysthi Simpliciter.
I had to look up NAN to begin with 
I’m not sure, if my reply is helpful at all, but I thought it may be worth a try. My latest patch uses 3 Complex Simpler sampler modules and tends to “get stuck” shortly after being loaded every once in a while; roughly every 5th to 10th try. It was stuck as in: the output was silenced and the output lines showed bright yellow non-flickering lights. In this case the patch could not be reset other but loading it up again. Once the patch was running it didn’t get stuck even once.
I couldn’t figure out what caused this “getting stuck”, but it may have a connection to the above mentioned phenomenon.
That problem is general. This is a specific thing. The particular way I’m using the Simpliciter/Complex/Confusing modules, they can get into a state where their output is NaN (Not a Number) which in turn makes @modlfo’s Vult Freak filters jam up, propagating the NaNs down the signal chain.
I think that a module programmer could check for NaN & infinite values, both on inputs and outputs.
This has been mentioned before by Andrew, but I haven’t heard if it’s going to stay or not:
Add infinity and NaN protection to cables, so they won’t propagate non-finite values from badly behaving modules. (Performance not fully tested, could be removed.)
I suspect that close to zero percent of module devs do that. I don’t. Very few modules output buggy garbage like this, afaik.
A module shouldn’t generate NaN on an output, full stop. I know there are ways easily toIf you actually have to put a guard in to check, it might as well call abort() and dump core, at least in the development phase. If you crash you can work backwards and see where they’re happening.
Given that the patch I was using was manipulating the record & playback triggers constantly, I’d suspect some sort of off-by-one error loading a sample from outside the buffer.
yes, it’s not a legal thing to do. … knows iv’e done it in prototypes before, but I don’t think I’ve every shipped one that did that.
I’m not blaming Antonio. Not sure anyone else has weaponized his samplers the way I have.
Oh, for sure anyone can make an obscure, hard to repro, bug in their code. I know @synthi is a good guy, and a wonder of the world in DSP programming. Hopefully, now that you can repro it easily, he will fix this.
oops just noticed!
I don’t have anymore a linux machine (was just a virtual box machine on mac and now I have an m1 that won’t run it)
I have to rebuild my 3 build machine (I’ve also no idea if my build script it’s going to work on my m1 )
I promise that if I touch the VCV build system again I’ll check this problem, sorry !
I need a repro patch, possibly built only with nysthi and vcv modules (because I run it in debug mode in another environment, with no extra plugins)
Well I built up a patch with only NYSTHI & VCV modules but in that case, Confusing Simpler (so far) doesn’t blow up and start outputting NAN. I can upload one of my patches that does blow up, but it has all sorts of modules besides VCV and NYSTHI.
Oh well I kind of like how this patch ended up sounding 
ConfusingBug.vcv (29.3 KB)