This is where the good’ole DEBUG() is coming into place. Put conditionals for NAN and INF on the inputs and print them out. This is how I traced down the random::normal bug that killed an oscillator code I was working on with ONE!! -inf sample every hour (if I was lucky - as this is a statistical probability).
2 Likes
Ok, that should be fixed. Now Incubus should be possible to abuse by randomisation happening a 100 timer per second.
1 Like
Sometimes the nAn value can be read anywhere in the patch (inconsistently) ‘after’ a certain module has crashed. See the discussion i had with Paul here:
I been experiencing nAn overload with many different modules over the past few years with Rack, usually these nAn overloads happen when sending CV into a modulation input that can not handle the range of CV coming in.
3 Likes
Is this widespread enough that it should be bubbled up as a Feature Request for Rack itself? I’m no developer so I’m not sure of the feasibility of these things, but it seems like the best things would be that 1) modules never output bad values (root cause problem solving and all), but 2) if that’s not going to happen, the framework itself maybe should deal with NaN’s similar to what MindMeld is doing.
1 Like
Hm, Rack could check on invalid values on cables and disable a misbehaving module. Could be worth a feature request.
3 Likes
or
7 Likes
Not sure what the best approach would be but maybe options could include: disable the module, throw up an error and pause the engine (“Error: Module [Module Name] created an invalid voltage value, the audio engine has been paused.”), default any invalid values to 0 volts. The first two could at least give users and developers some indication as to which module was at fault, which I like.
EDIT: Or what Antonio just posted. 
It is indeed Hora Drum in the patch I posted. Do they post here? I guess this is exactly the same problem with Rings.
The update to mindmeld doesn’t seem to have fixed the problem with Resonator even though it appears to be a similar problem. Guess there really is a bug with that specific module beyond this ~inf/nan behaviour.
If the bug with Resonator is still causing the MixMaster to misbehave, whereby all the aux sends/receives light up like in your intitial picture:
then I would appreciate a followup, since with the new version it should not do this. Can you confirm that the mixer itself is now behaving ok?
Hi Marc, yes the mixer is working as it should. The resonator bug doesn’t cause all the sends to light up like that picture but affects just the channel that the it is plugged into. I think when it happens resonator is just outputting a constant voltage so it’s probably a completely separate issue than the one addressed in this thread.
There are a couple of open (and duplicate) issues open about it if you need/want to reproduce it.
1 Like
Not sure who heapdump is and what module you are referring to, but Audible Resonator is by Andrew Belt I believe, if we are talking about that Resonator. But I didn’t follow all of the discussion unfortunately, so apologies if I’m in left field on this one! 
Ah ok, sorry! Then yes, it should definitely be fixable; the best would be to try to get a good way to reproduce the problem and open an issue on his github. In my screen capture above though, to Patrick’s defense, his module was connected to others that perhaps we sending transient NANs etc, so it would need more testing to make sure where exactly the problem originates.
1 Like
You posted int clamp(int, int, int).
float clamp(float, float, float) is defined with fmin/fmax, so it protects against NaNs.
Ah, true, my bad. Glad to see the float clamp will work then
Maybe it’s my fault in some cases. I figured out that Neo can cause NaN’s in some seldom cases, I don’t know why, but it seems that it’s some bug in the math model. BUT: It happens only on startup for a short period and then it continues with valid numbers; also on my tests it happened rather seldom and is not reproduce able, which makes it hard to find the bug. :-/ Will do some further tests today…
2 Likes
Hi all,
after a lot of stress-tests I figured out that Neo can output some bad numbers on startup. For a short time the filter outputs some very high numbers around +/- 10^12 but I didn’t find any case where it outputs some NaN’s. But it caused to crash Sangster which can’t handle that big numbers correct. Maybe also other modules cannot handle that malformed numbers and react with NaN.
It’s fixed in the upcoming version 1.3.0 and I/Os protected now.
8 Likes