I’ve discovered Befaco’s Slew has admirably extended times for my usage, but since the sliders are calibrated in abstract 0-1.0 increments, I have no idea how to dial in exact slew times other than by tedious trial and error.
BogAudio’s Slew only goes to 10 seconds, unfortunately. I’m looking in the range of 10-60 seconds.
Thanks for your help.
Look carefully at the faceplate, and read the documentation. The slow button slows it down by a factor of 10. So with slow enabled it takes 100 seconds to go from 0 to 10 volts
Also, the VCV Fundamental PROCESS maxes out at 10,000 ms / V, which also equates to 100 seconds for 10 volts, though I’m not sure how accurate the timing is. I believe it is reproducible, but may not be exact. I did a rough test, and it seemed to take ~110 seconds to reach 10V.
Ouch! I just tested the Bogaudio SLEW on my MacBook Air, and it seems to struggle at the extreme slow settings if the voltage is at or near 0 or 10 volts - it stalls 
If I reduce the time to say 5 (50 seconds / 10V), then it starts moving, and then I can increase the rate. Well that will not work.
So it looks to me like VCV PROCESS is a better bet.
Did you try setting all the way to 10 in slow mode? That is where I ran into the problem. I think the 6 (60 seconds) is working for me as well.
Noticed something similar while working on my latest patch :
This is with 16-voice polyphony for a 45 second linear slope (from 0V to 10V). Well, almost 45 seconds with the Befaco module because, like the OP stated, there’s some tedious trial and error to be had.
Befaco keeps a steady CPU consumption below 1% whereas BGA Slew fluctuates aplenty but seems to average around 5%.
So when I’m working on patches hovering above 80%, these are the kinds of economy I’m looking for 
I figured out the problem! It fails at 10 (100s) for me as well on my Windows machine.
But I am running both at 96kHz.
If I set the VCV sample rate to 48kHz or lower, then all is well with Bogaudio. But if I set the sample rate to 192kHZ then Bogaudio doesn’t even work a 5 (50s). When I get a moment I will try to look at the code to see if I can find a limitation inherent to the algorithm and/or data types he is using.
so 176.4khz
so you are reporting it doesn’t work, or you are asking @DaveVenom to test it for you? btw, @matt is extremely responsive to bug reports, at least in the past. so by all mean log one.
@DaveVenom talk about code but this post doesn’t talk about code
Errata: @DaveVenom is the coder
I must go to sleep
This is a good general reminder to test my own modules at higher sample rates!
and test with changing rates. I’ve often made that mistake of not responding correctly. That’s why under likes to use that number that’s passed into process - sample time, is it?
