Can I change the internal sample rate of a module?

Development
1

Hey :slight_smile:

I am working on a sequencer, which I feel is getting to a point where I am pretty happy with it.

But I am thinking I’d like to try, if possible to lower the update/sample rate of the module, cause I don’t think it really needs pr sample precision.

On the Axoloti DSP board you have to different types of rates. You have Sample rate, which obviously runs at sample rate and then you have k-rate, which updates16 times slower than sample rate. So if sample rate is 48000, the K-rate is 8000.

I never had any issues with sequencers in Axoloti running at 8k, so I’d like to see if it’s the same with VCV Rack2, to save some cpu.

I know the sample rate is passed through args, but how do I, if possible, change the sample rate for this specific module only and not the overall sample rate of VCV2?

Any tips appreciated!

2

Of course you can do that. just be careful that the effect is really what you want. If you introduce a semi-random delay on the clock input there can be bad effects.

My old “LFN” generates random cv by filtering noise at a 400 Hz sampling rate!

This technique in mentioned in my “class” paper on writing efficient plugings. That repo also has a simple oversampling clipper to show how to do that for audio signals. For you application, though, it doesn’t sound like you need to worry about that.

Here’s my “demo” repo. Hopefully something in the TOC will pique your interest. It’s here

1 Like
3

Thanks, I’ll look into the the demo repo.

Yeah, I just wanrt to try it and see if it will work out. Hopefully it will :slight_smile:

1 Like
4

A simple way for cv is to keep an internal counter and have process do

If (counter++ == 8) Counter = 0 Else Return

At the top or a million other things really!

Just watch out for people sending you short triggers and stuff but yeah a control rate and associated latency is absolutely fine for many many things

5

I tried using sampleTime for this:

int sampleTimeInt = static_cast<int>(args.sampleTime);
void process(const ProcessArgs& args) override {

   if (sampleTimeInt % 16 == 0) {
   // All process code here....
   }
}

But I didn’t really notice a lot of difference on the performance meters. But yeah, those meters, I am not 100% sure how precise they are. Are they precise?

So maybe this is not my issue why my module uses a bit more cpu than wanted. Guess i have to do a bit more research… :slight_smile:

6

So turned out it was actually a “bug” in my preset system, which I seem to have fixed now, so now the modules cpu usage is completely acceptable :slight_smile:

So happy I finally found the culprit.

Still going to do this sample rate trick later on, if it’s necessary, but for now I don’t even think I need to add it to my code.

1 Like
7

the CPU meters are pretty good. It can depend on you sound hardware. With my ancient m-audio card (20 years old?) they were pretty bad. with my current UR-22C they are pretty good.

Here is yet another article on the perf meters: Demo/docs/cpu-meters.md at main · squinkylabs/Demo · GitHub

8

I am mostly just using my M1 Macbooks own speaker or headphones out.

But I managed to get the cpu usage way down for my modules. They were using like 5% each… But now they are down to 1% each, with just the update in the preset system. So thats really great. I think I can wait a bit longer wither further optimisation for now :slight_smile:

About the meter, yeah it was probably just me being annoyed the modules using too much CPU… :innocent:

I have a RME Fireface 400, but actually never used it with VCV and usually just record everything internal in VCV, using the Recorder module.