Understood ; anything that saves CPU is good for me, so even if it’s not the full feature set, as long as I can save these precious 3/4% per synth voice, it’s already great to have access to such a module.
About Host, I still don’t have it and don’t feel I need it yet. Bought Pro version tho, to use VCV as a VST, but the +2500 modules usually take great care of my ideas. But yeah I suppose I’ll buy it sooner or later !
Big news! My crash source has been identified by the plugin developer I have been working on for the past week or so and will be fixed in the next release. I am not naming the plugin since I am apparently the only one to ever run into or at least report the crash.
The problem was an out of range array index that could happen when the problem modules received a reset while running in a particular mode. The end result was that the output ports channel count would be set to garbage values outside of the 1-16 range.
I have been working on this since February, so I am celebrating!
With permission from Count Modula, here are the details on this crash which was fixed within a week of me sending the last crashing minimal patch and the fix has been submitted to the library review queue;
The crash was occurring whenever I used the CM 8To1 or 16To1 sequential switches if the switches were set to “reverse” direction and I sent a reset to the module. As mentioned above, the root problem was an out of bounds array index that only showed up after reset in the reverse direction (or possibly random direction). This had to do with the input and output ports number of channels such that the output port channels would be set to anything between 0 and 76 during my tests. This also seemed to cause problems with downstream modules when they received input cables set to 0 or > 16 channels (or perhaps other values) as well as some NaN voltages.
There is an issue on this in the Count Modula Github repository.
The fix for this (and a couple other issues) has been submitted to the library team for inclusion in the next update.
now, imagine there are thousands of VCV modules, and these are some of the best. Then what is the probability that your patch will crash if it has 50 modules in it?
From my own experience, the actual number of crashes is very low, unless the crash originates in one of my favorite modules that I use in almost every patch and is something that will crash 100% of the time under certain usages.
I view this particular topic as a positive story of collaboration and persistence and logical analysis of a problem. As you know, several developers helped with trying to track down this particular crash, developers I greatly respect, as I respect Count Modula. This was a tough nut to crack and took over 5 months to pin down after I first posted this topic in April.
This type of out of bounds array index induced crash would probably be difficult for programs like Asan (address sanitizer) to catch since it only shows up if the sequencer is running in reverse direction.
I’m happy to go back to making music with patches with > 50 modules in them. Thank you everyone involved in tracking down this crash source and especially thanks to Count Modula for fixing it so quickly.
Edit: One last thing; this crash was extra difficult to track down because in most cases the crash of Rack prevented the stack trace-back from logging anything, as if it never was executed.
I just want to share that my tests with Count Modula 2.2.0 that released today do confirm that the Rack crashes were fixed in this release.