Has anyone narrowed down the sends and returns bug?

Just to make sure: clamp prevents NAN?

Curious here too, and if so, what does it return on NAN?

clamp() will not prevent NAN, since clamp is:

inline int clamp(int x, int a, int b) {
	return std::max(std::min(x, b), a);
}

and those std functions can return NAN.

I made my safety clamper inf and NAN proof like this:

static inline float clamp20V(float in) {
// meant to catch invalid values like -inf, +inf, NAN and strong overvoltages only.
	if (in >= -20.0f && in <= 20.0f) {
		return in;
	}
	return in > 20.0f ? 20.0f : -20.0f;
}

Comparisons to NAN always return false, so in my code above a NAN will return -20V.

4 Likes

I know it’s waste of CPU cycles but maybe Rack‘s clamp should protect against these values…

2 Likes

Which was the module? Where was it reported?

could be implemented in RACK code a mode “DETECT NAN mode and protect”

when the mode is on, all cables become BLACK and the CABLE bringing NAN YELLOW or ±inf RED

4 Likes

It was the issue with Incubus filters locking up after x minutes.

That would be a very neat debug option! :slight_smile:

To add more fun to this discussion:

2 Likes

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. :wink:

It is indeed Hora Drum in the patch I posted. Do they post here? I guess this is exactly the same problem with Rings.

8 posts were split to a new topic: Module From Hell (for testing things)

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:

image

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?