Congrats on the fix!
I think Option 2 is fine: IMO people working in 16-poly know what they’re getting into 
and <= 8 the difference doesn’t seem significant.
If you did Option 1 (which would be fine too) I’d suggest putting a negative qualifier on 2x–i.e. call the options something like “2x (may break with extreme modulation)” and “4x (any modulation OK)”
I would ship with option 2, less likely to NAN and break. Nan is just bad luck. I stop using modules that break during patching .
We are all on the same page so far 
I would prefer Option 2 as well 
I would choose option 2.
I think you should go for this option, given those CPU numbers. Put the option in the context menu and let 2x be the default. This is provided that it’s an edge case that triggers the NaN’s, and that you only estimate say max. 10% of uses would be extreme like that. If on the other hand you estimate that 50% of the uses of the module would trigger the NaN’s, then you probably have to bite the bullet and let 4x be the default, but still give the option, and maybe try and persue some more optimizations.
What happens if you reduce the sampling frequency of the mod input to every other process and interpolate? This seems cheap. It would split any instant changes over 2 samples, so maybe that is enough to prevent NaNs?
I think frequency would probably be at least an order of magnitude rarer, like 1% or less. If I were only creating this for myself or someone like you (whatever that means), then yeah, I would go for having options. It was my first instinct. But when I think of the general VCV populace that does not read documentation, then I get nervous, and feel like option 2 is the logical choice.
I hear you. It’s always a concern when to treat people like children and when to treat them like adults. I feel like your modules are “adult modules” and if those 1% can’t be bothered to right-click and see the context menu then f.. them (or something more polite). Don’t let the 99% suffer the 1%. I’m mentally gearing up for making modules, when I get around to it, and my weighing will at least be “don’t let the 80% suffer the 20%”.
Interesting idea. I wouldn’t do exactly that, but I may investigate application of a low pass filter on the CV input, with a cutoff somewhere between 12 and 15 kHz. In theory that might have little to no effect on “reasonable” CV, but prevent the NANs. If it works I could enable the high pass filter by default, and offer a context menu option to disable it.
Unfortunately, I perceive that the ratios are actually in reverse. I think the vast majority of users do not read documentation. So from their perspective, 80% are suffering the “nerd” tendencies of the 20% (or maybe even worse than that!)
And your work is truly too good to leave an active known bug. A bug is a big turn off, when I got excited for the DocB pulsar ( like one ripple in Sophia) it became dismay as many patches would deliver NaN. Sigh…. so much for my pulsar train oscillator ( well there are some now). But really, not everyone hangs about here catching all the gory details, make it very patch friendly and it only expand your fame and fortune ( I wish you both)
I went ahead and implemented option 2 for the filter - always use 4x oversampling for audio rate processing to eliminate the possibility of NAN outputs, at the expense of higher CPU usage. I pushed my Blippoo Box emulation really hard, and never got a NAN
I have also made some enhancements to the SLEW module. @fractalgee reported some odd behavior with the gate outputs when oversampling is enabled. To address the issue I added a context menu option to set the slope detector sensitivity when oversampling is enabled.
I also added a polarity switch for the Slew gate outputs.
Below demonstrates the effect of the slope sensitivity when processing an audio signal, plus the new polarity option.
The top scope shows the results using the original sensitivity, and unipolar gate outputs.
The bottom scope shows the results using the new default minimum slope sensitivity, and bipolar gate outputs.
Red = slewed output
Yellow = rising gate
Green = falling gate
Blue = flat gate
The new 2.14.0dev2 binaries are available on github below for those with a free user account:
I finally wrote the Multimode Filter documentation
I am happy with the module layout, but there are a lot of interrelated concepts that made the documentation difficult to write. Let me know if I need to if I need to make changes to the document.
I just had a quick look at the document and think it’s quite good.
In my opinion, nothing needs to be changed.
I submitted Venom v2.14.0 to the library with the new Multimode Filter plus enhancements to XM-OP and Slew
Congratulations! Wonderful news!
I added a Glacial speed to AD/ASR that supports stage lengths up to 48 minutes!
I bumped up the next release version number to 2.14.1 and modified my library submission.
For anyone that is impatient, you can get the new binaries below.
Within days of v2.14.1 hitting the library, of course I got a request for an enhancement - and it was a good one.
Well I couldn’t fit more controls/inputs on the panel, but I could enhance the Morph capabilities, and that spawned a round of improvements and a bug fix. I’ve got a new v2.14.2dev beta version for testing with the following changes:
The documentation has been updated
The beta binaries are available to anyone with a free github user account:
I’d love to get some people to test the modifications and make sure I don’t need to tweak anything. I hope to release these changes to the library within a week or so.
Hi Dave,
I tried the new version a bit,
I couldn’t find any bugs yet,
I like the new morph mode very much
all seems to work as expected here.
I will test more tomorrow.
