Long time user of VCV Rack but this is my first post. While trying to use Trummor2 (Free) today I found that the noise filter wasn’t working at all. If the filter is set to either lowpass or bandpass no noise is generated by the module. But if it is set to highpass, all noise gets through whether the cutoff filter is set to full, zero or anything in between. I’ve tried opening and closing VCV Rack, unsubscribing and resubscribing to the module and using the external noise source. The effect is the same each time.
Hi,
I just tried it and it works for me. How do you have it set up? Can you share a patch\screenshot?
I’m testing in a blank patch with just a CLKD, Trummor2 and an Audio Output. Unfortunately there are no modulators affecting the patch.
I’ve also tried a couple of setups including stuff like mixers. But the problem seems to be that the module is not acting like it’s supposed to.
I’ve found the issue. Setting the Sample Rate to 24 kHz seems to have lowered the output from Trummer2 to below audio levels. Still confused about why this was happening but I’ve gotten a fix.
1 Like
I’ve noticed this happen a few times now - a situation where a particular user is experiencing odd behaviour or something not working, and where other users try it and report it is working as expected, that the reason is because the user reporting the problem was using a sample rate below 44.1kHz.
Sampling rates below 44.1 kHz were introduced with Rack 2. I assume, the questionable modules were not tested on that sampling rates while porting from Rack 1 to Rack 2.
1 Like
In general, none of the Vult modules are tested for sample rates less than 44.1 kHz. I do not have plans to support less than 44.1 kHz.
If you lower the sample rate expecting to consume less CPU, in most cases that will not be the case for Vult modules. Many filters become unstable at low sample rates, that requires me to implement internal over-sampling in order to keep the filters from failing. So, even when you set 24 kHz, the module will be running at 44.1 kHz and doing resampling in order to get a 24 kHz output. At the end, you will consume more CPU than simply running at 44.1 kHz.
The work of adding support for lower than 44.1 kHz in all modules is just too much for me and there’s no real benefit for users (since there will not be reduction of CPU consumption).
3 Likes
@modlfo Great argumentation! IMO going below 44.1 kHz only makes sense in CV-sequencing external hardware.
1 Like
I 100% support your choice to only support sample rates >= 44.1 kHz.
But I want to make sure I am not misunderstanding something, so I have a purely academic question - I’m not trying to argue that you should support < 44.1 kHz.
Suppose there is a patch with say 20 modules running at 24 kHz, 1 of which is a hypothetical Vult filter that is internally running at 44.1 kHz. Sure, the Vult module has to do extra work to resample back down to 24 kHz. But if the other 19 modules run natively at 24 kHz, wouldn’t there most likely be a net reduction in CPU usage for the patch as a whole? (compared to running Rack at 44.1 kHz)
Of course, it all depends on the modules you use. Many simple modules will have no issues and the performance scales linearly with the sampling rate. In some of my modules (or written by me) changing the sampling rate has very little effect on the performance. For example Hexaquark (Geodesics + Vult) is a complex module in which computations occur only when events happen (like the rise of a clock signal). In that case, the module will consumes so little that changing the sampling rate has a tiny impact.
If one wants to save CPU, because the computer cannot handle a moderately large patch, I would recommend instead using the lighter/simpler modules. For example, some of my filters are made for efficiency (for example Stabile) while others are full analog simulations.
2 Likes
Thank you for your responses. I was experimenting with lower sample rates and I can see that the results are negligible. I’ll stay away from going lower than the default sample rate as I can see why developers aren’t optimizing their modules for it.