nanV issue

Unregularly I see nanV outputs from modules. I don’t see what’s going on. Usually the issue disappears after restarting VCV Rack.

Has any of you seen similar cases? What can it be the reason?

… and more Hora:

The Hora plug-ins (drums) give me NANs every now and then sometimes loading a project with one Hora plug-in in it starts with a NAN output. The Groovebox has not yet given me NANs.

1 Like

I would also love to know. Restarting Rack does not help me though. Could it somehow be linked to frame rate? because I use a very low frame rate, other than that everything’s standard.

Usually it’s a bug in the individual module that makes it output a NaN.

3 Likes

deebugger, step through that code and see what causes the output to get corrupted in some way.

Hora Hi Hat does this on my system too. Occurred mostly when I first add the module and patch the output to a mixer. Confuses me cause I always think I patched something wrong for a sec.

2 Likes

Hora Hi Hat does this on my system too.

@Raph?

Groove Box V2.19 solved the problem of nanV for me. But yes Hora hihat does give problems sometimes. Mostly when I close a patch and open it again. But the I just delete the module and insert it again. Have to set it up again though.

An unexpected catch:

Interesting. log a bug with active repo, if you would like. I wonder if Fundamental VCO1 1.0 had that problem, too? Anyway, @robert.kock maintains these now, and that github is at: GitHub - kockie69/SquinkyVCV-main

1 Like

NANs when first connecting a module is a sign that that module doesn’t initialize it’s variables/buffers properly. This is a tragically common coding error in C++, trivial to fix when known, and costs very little to do. I just found an example in Rack itself (which either already fixed or fixed immediately). Some other more recent languages like Rust et al. having learned from C/C++ make this error difficult or impossible to make.

Once up and running, NANs likely point to other issues with the code. Some programmers don’t care if their floating point math goes crazy sometimes. Preventing NANs and Infinities comes at a cost and can be very difficult to do.

A module can protect itself by defensively handling NANs on input, but like any additional code, comes with a cost.

uh, yeah, I do know how to program. But in case I didn’t, thanks for the tip!

I know you know, but others in the thread were wanting to know where it comes from, and perhaps letting other visitors know where to look for solutions if there is an issue, and new developers some things to watch out for.

2 Likes

I remember a while back there was a lot of NaN issues floating around, and Andrew was mumbling about implementing blocking of NaN in the cables. Does anyone know if he got around to that?

Ugh … I’m still on VCV Rack Free 2.1.2

It may have been resolved completely then… :flushed:

Although I can’t identify it in the changelog.

Was added in V2.0.0.

Doesn’t stop modules from generating them, just stops them from propagating through cables.

4 Likes

Whereas NaN may be blocked by cables, it still happens quite often that some module outputs some gigantic millions of “volts” number. That usually seems to be due to uninitialized variables, in my experience. But, it is good to hear that NaN is blocked by cables. I haven’t seen one of those in a long time now.

1 Like

I know someone named Nan. She never knew why her iPhone kept changing her name to NaN. Until I told her.

2 Likes

She could count on you, because she couldn’t count on herself :grin:

4 Likes

Nan is unaccountable.