Venom v2.6 released

Announcements
8

Thanks for the report. Do you have a patch you can share? I haven’t run across that yet.

I’m curious if you are modulating anything with external signals? By external I mean coming from some other module. And do you notice a difference with oversampling engaged or not?

I have seen my Poly S&H ASR occasionally generate NANs (floating point Not A Number), and then the patch needs to be shut down and restarted. I haven’t yet determined if the NANs are originating from my module, or introduced by external inputs.

9

I think some module filter out NaN on inputs. Have to confess I never did
 If a module might go bonkers from seeing a NaN, then it’s probably a good idea, now that I think about it.

10

Yeah - I can see arguments for both options. But I certainly don’t want my module to generate NaN on its own! Hopefully I can track down whether I am at fault. Or maybe the problem has nothing to do with NaN. Time will tell.

1 Like
11

I modulated using its own outputs. I believe im usually using mid to high oversampling

12

Afk but ill keep experimenting

13

That’s strange, I though @Vortico introduced NaN protection in cables for Rack2


“Add infinity and NaN protection to cables, so they won’t propagate non-finite values from badly behaving modules.”

1 Like
14

That just means that the NaN will not propagate from the module that outputs it.

15

Isn’t that what Dave means when he says

Poly S&H ASR occasionally generate NANs

? I mean what the module is doing internally isn’t that interesting, what runs through (propagates) the cables is, and there NaN should be blocked by Rack itself.

16

that is correct

17

Thanks Lars. The full quote from the development blog was:

So I was curious whether that actually made it to production. I ran a quick test (coded a module to intentionally output NaN and inf). Indeed, the module output (cable input) showed NaN or inf. But at the cable destination it shows as 0. So the blocking by the cable truly is occurring.

Unfortunately for me, that means my S&H module must have been producing the invalid output on its own :frowning: So I have a bug to track down, but now I can’t seem to reproduce the problem. Argh.

I guess I am past due for an inscrutable bug in my Venom plugin. As a fairly new plugin developer, I’m a bit surprised I haven’t run into something like this before.

So please - if anyone runs across invalid output from any of my modules, please let me know. Especially if you can reliably reproduce the problem, please post a message with a patch and instructions on how to force the problem. That would be a huge help!

2 Likes
18

I could be misremembering, but, last year when I worked for months to track down a crash caused by on open source plugin module, I saw cable voltages in the millions and these would overflow modules such as Voltmeter and others. So, it may not always be a NaN that causes problems. That problem last year was an uninitialized variable when a sequencer was run in reverse, I think.

19

It’s been a while, but didn’t you find that address sanitizer was useful for finding uninitialized variables and such?

I wonder also, it enabling floating point exceptions in a debug build might make it easier to find errors. It’s something I used to do with the microsoft compiler, but have never tried with gcc. for example: gcc option: about -fsignaling nans : how does it work ?

1 Like
20

You ran asan for me at that time, but we did not find the source of the crashes. We did learn some about the apparent value in explicit initialization of everything that is not initialized implicitly by the construction of the variable (array).

All I was able to do was to eventually find an example patch that crashed Rack upon every launch. The developer very quickly tracked down how the crash could occur when the sequencer was running backwards and gets back to an array index of 0 or -1 (?) or something like that.

That bug implicated so many modules in the crash log that were in fact innocent.

2 Likes
21

Thankfully my plugin is not crashing anything (at least to my knowledge). I just experienced some NaN outputs that could only be fixed by relaunching the patch. I thought I knew what module within which patch was generating NaN, but now I am not sure - I cannot reproduce the behaviour.

1 Like
22

it seems to me it happens when you patch pwm to chaos. these settings consistently kill the module for me

Screen Shot 2024-02-20 at 12.24.16 AM
Screen Shot 2024-02-20 at 12.24.16 AM1044×1740 153 KB

1 Like
23

Chaos is a switch that changes the feedback path of the shift register right? I can imagine that flipping this switch at audio rates (pwm can go really high) might cause glitches and freaking out the shift register at best


1 Like
24

Congrats on this release! Also thanks for introducing me to the world of benjolins :robot:

1 Like
25

Thanks! I got excited because that is something I had never tested, so I thought maybe I would get lucky and be able to reproduce the problem. But I just tested on Windows and ARM Mac (both x64 and ARM versions), and could not trigger any problem. All manner of weird sounds, but no freeze. So maybe the problem is specific to the Intel Mac, which I don’t have access to :frowning:

I will take a look at the code involving the Chaos switch, see if I can spot anything suspicious.

1 Like
26

We like all manner of weird sounds :slight_smile:

27

There is a good chance I have fixed the problem, but hard to be sure. I too was able to sporadically get loss of output. Looking at the code I noticed that I was supposed to be limiting the minimum frequency to ~0.03 Hz. I did the computation, but forgot to set the variable - Ugh! More importantly I think, I was not constraining the upper frequency. In some development code I clamp the frequency to ~0.03 Hz - ~12.5 kHz, and so far it is behaving better.

This fix will be in the next release, but I have no idea when that will be.

1 Like