How to Get Sample Rate Engine?

Hello,

Just an easy one … how can I get the sample rate of the VCV Rack environment?

I developed a reverb, but its need the sample rate to be initialised.

I Hardcored just writing 48000, but in the case the user changes to 41000, the delay time of my filters will be ofset.

The args argument of your process function:

void process(const ProcessArgs& args) override {
  // args.sampleRate
  // args.sampleTime    (= 1/sampleRate)
}

It is easy enough to find this information yourself via the VCV Rack API guide

In the upper right corner is a search box. Simply enter samplerate and you will be presented with a list of options to get details.

Note - do NOT use rack::settings::sampleRate because that will be 0.f if the user has selected the Auto option.

2 Likes

There is also the onSampleRateChanged event sent to your module.

1 Like
// Sample rate change event handler.
void onSampleRateChange(const SampleRateChangeEvent& e) override {
	sampleRate = APP->engine->getSampleRate();
	if (sampleRate > 0.f)
		sampleTime = APP->engine->getSampleTime();
		else sampleTime = 3e37; // Huge value, but to avoid division by 0.
}

Also, anywhere inside your module’s constructor:

// Get engine sample rate.
sampleRate = APP->engine->getSampleRate();
// Sample time (sample duration, depending sample rate).
if (sampleRate > 0.f)
	sampleTime = APP->engine->getSampleTime();
	else sampleTime = 3e37; // Huge value, but to avoid division by 0.

Both sampleRate and sampleTime variables are float.

Hello Paul, I report a typo…

onSampleRateChange, instead :wink: as I’m using in mine sources (just above).

I’m on my phone – thanks for the correction. Instead of calling back to the engine, doesn’t the event contain the sample rate? Events usually contain all the relevant information for the event.

1 Like

Yes, the SampleRateChangeEvent event contains both sampleRate and sampleTime attributes

2 Likes

I’ve never used onSampleRateChange because pretty much all my modules that have sample rate dependent initialization also have user configurable over sampling, which also changes effective sample rate. I need my own code to detect over sample rate changes and I prefer to keep all the sample rate logic in one place - generally at the top of my process code.

I’ve been using onSampleRateChange to recalc any clock dividers. Is there any reason to calculate user interface values any faster just because someone wants a jigahertz sampling rate? Or is that an optimization that most people ignore?

1 Like

Don’t worry about typo, and… you’re welcome Paul. :wink:

By using call from module’s constructor (the second example I’ve mentioned), this avoid potential unintialized sampleRate / sampleTime on early DSP frames, it’s a kind of “guard” to prevent bugs (or possible module + Rack crash). Same about 3e37 insane value, in case the sameRate is… 0.f ! (I’ve already seen this scenario during debug session on Windows platform, but many months ago - perhaps this was fixed by most recent SDKs, but I’m not sure). Constructor is invoked once, so it’s more reliable and doesn’t impact module’s performance.

Also by changing AUDIO module settings this impact the DSP (at least for seconds).

Sample rate can be changed at any time, so just in the constructor isn’t enough. That’s why there’s an event.

1 Like

Yep of course, I agree!

Init from constructor, but changed anytime by onSampleRateChange event handler.