this is some sort of PSA, sample rate matters, let me explain: I am frequently surprised about how much a higher sample rate impacts the sound in vcvrack. going from my audio interface default of 48khz to 96 then 192 then 384khz almost always improves the sound of an oscillator or whole patch when anything mildly interesting is happening in your patch (osc sync, FM, crossmod) etc. so far I have not checked filters but filter fm likely yields way better results with higher sample rates. as I said I am a bit baffled how much this affects the sound, probably due to the fact that in audio, noise is summed but distortion multiplies, if I remember my engineering tutor correctly.
this makes me wonder: is any cpu capable of running moderately complex patches using 768khz yet, m4 mac anyone? I wonder if there is a noticeable improvement over 384khz, but my m1 mac craps out at 768khz even for simple patches. so far most of the tests I did show a significant improvement from 192khz to 384khz, so I guess 768khz will be another significant improvement in sound delivery for complex patches with lots of compounding (stacked) audio-rate modulations going on. my advice: try it if your cpu can handle it.
I noticed that expert sleepers modules do not work correctly at anything higher than 48khz, which is a bane for my setup, as I would like to run vcv oscs at high samplerates to run them into analog filters, cause I have not yet heard any convincing digital emulation of an analog filter not sounding awkwardly sterile to my ears.
high sample rates only make bad modules sound a little bit better sometimes. Good modules should not make those distortions, unless they specifically say “super retro 80’s digital grunge sound” or something like that.
This video talks about this. I think ppl like this video - it’s linked a lot.
This might be true for “zero-time” feedback loops. But for me personally, it doesn’t matter that much because of complete hear-loss above 15 kHz.
On the other hand, a lot of modules for VCV are not so accurate recreations of analog gear, most modules inside the rack could not be built as analog gear. We have 16-time polyphony, we have more DAW-like sequencers, and so on.
So when making music (for me, that’s the purpos in the end) I want my patch running smoothly, so 44.1 kHz does the job well enough.
If I were on the “high-quality-sound-club”, I would go for an analog modular setup with real knobs and real (only mono) cables an a real high amount of money to spend on
Sure, but even us people with bad hearing can hear the artifacts of imperfect dsp. Those artifacts are at frequencies much lower than 20k. Weren’t you one of the devs who changed your sample rate conversion to something that sounded better?
oh, for sure. dsp done well has very few artifacts below 20k, and it is unproven whether any of these artifacts are audible to any human. I don’t have a strong opinion on this, other than that I’m pretty sure I can’t hear them ATM.
But, for people who can hear this, or for people who want to use DSP that does have significant distortion below the Nyquist theorem, there are higher rates available. 768k is probably higher than practical, but there are ppl wo use 96k or oven 192k.
If your Expert Sleepers modules are ADAT, then what you’re encountering is probably the limitation of ADAT transfer rates. To send 8 channels over ADAT the sample rate can be a maximum of 48kHz, or to send 4 channels the sample rate can be a maximum of 96kHz.
In general I don’t think you would need all of Rack to be running at such a high rate, though, but rather that analog modeled modules should be internally oversampled.
The only “solution” I see here is to run different cables at different sample rates, but this is actually not possible. And I don’t think it will be possible soon, because from my perspective it would require changes in every module with more than one port.
even though moore’s law does not apply anymore, cpus get faster and faster each iteration, so one day we may run everything at 768khz and not think about it further. the point of making this thread was merely to share my recent observations on how much of an impact different sample-rates have on vcvrack, and how many people agree or disagree on this. I like to harvest the extremes when doing sound-design, and while digital artifacts can be charming or even evoke justified nostalgia, I try to stick with the core principle of what digital audio is trying to do in the first place, i.e. simulating/emulating analog audio. so, more precision should always lead to better results, regardless of taste. thanks for the replies so far, they have been rather valuable
I tried this and I do get a buzz at 48kHz and below that isn’t present at higher sample rates. But I do think this might just be due to some aliasing within the module, and not due to the latency introduced by the cable per se.
listen the demo or try playing around with the patch
it’s a sequence recorded on 48, 96, 192, and then 384khz, every step seems to first unveil errors in the high end, and the next one seems to fix them. with some patch settings at 48khz I found that errors in the high end might also “reflect” back into the low end (sideband distortion? ok more likely to be called intermodulation distortion), higher samplerates fix this as well, but it’s not in the audio demo…
@cornucopia Now I downloaded the patch and played around with it by eliminating everything but the module Ouros:
This module seems to have aliasing issues at some settings. Maybe report this to the developer. If the developer has fixed it, you don’t need to go up to 768 kHz anymore.
One thing to be mindful of if running at such large sample rates is that some modules additionally oversample by default, up to x16 sometimes. You normally can disable, but I could imagine you may start to get weird things happening at 16 x 768kHz.
Just throwing this out there without any evidence one way or another: if you’re chasing this demon it may be interesting to play with the resampling that goes on from Rack to the device driver. If you look at the Rack source for Audio.cpp that’s where the code is that resamples from Rack’s sample rate to the device driver. There’s a quality factor that can be set from 0 to 10 for the speex resampler, it’s set to 6. One could toy with this.
Additionally, I don’t think there is any check that the resampler is bypassed if the engine sample rate is the same as the audio device sample rate. Someone would have to dig into speex to see what happens with this, if it’s just pass through or actually manipulating the stream. Or just bypass it in Audio.cpp to play around.
