Impromptu CLKD Wavers

shofb · March 20, 2021, 4:46pm

On occasion the clock slows down ever so slightly and then corrects itself. I have had this happen with other clock modules also but this is the one I am currently using. Has anyone else noticed this?

Squinky · March 20, 2021, 8:16pm

hey @marc_boule what do you think - is this possible? I did look at the source code for CLKD, and it does ignore the args argument in void process(const ProcessArgs &args) override. I plead guilty to this, too, some times.

I think that if the VCV engine gets behind then it can sometimes not call your process function, but when it finally does it will “make up for last time” by passing more than one sample of time in args.sampleTime.

My guess is that as programmers we should not assume that only one sample has elapsed between process calls. As a user I’d say use real time priority in you engine settings and don’t run other programs at the same time. See if it gets better.

marc_boule · March 20, 2021, 9:45pm

I’d be curious to know if the Rack engine can do that, if it can, then it would be good to perhaps do as you say, but we’d have to look at the code to see if that is possible in Rack. Interesting discussion!

carbon14 · March 20, 2021, 10:40pm

I don’t think it’s possible for VCVRack to do that. So many modules couldn’t function correctly if they didn’t have access to ‘missed’ samples.

Squinky · March 20, 2021, 10:42pm

oh, look at that code. yeah, that’s a good idea. I know that rack fundamentals tend to add in the sample time, but of course that could only be because it makes it super easy to respond to changing sample rates.

almostEric · March 20, 2021, 11:03pm

Does sampletime really vary from call to call? I just assumed it was shorthand for 1/sampleRate

marc_boule · March 20, 2021, 11:07pm

Agree with Eric, I don’t think it varies from call to call, if it did, Rack would have to continually call onSampleRateChange(), which I’m not sure I’ve ever seen it do.

Squinky · March 21, 2021, 6:12am

Why would it if it just dropped a sample? I wouldn’t.

marc_boule · March 21, 2021, 11:36am

In any case, from the looks of things, I believe that Rack will not dynamically “drop” samples nor adjust args.sampleTime from call to call.

github.com

VCVRack/Rack/blob/v1/src/engine/Engine.cpp#L422-L428


		// Set sample rate
		if (internal->sampleRate != settings::sampleRate) {
			internal->sampleRate = settings::sampleRate;
			internal->sampleTime = 1 / internal->sampleRate;
			for (Module* module : internal->modules) {
				module->onSampleRateChange();
			}

and

github.com

VCVRack/Rack/blob/v1/src/engine/Engine.cpp#L235-L237


	Module::ProcessArgs processArgs;
	processArgs.sampleRate = internal->sampleRate;
	processArgs.sampleTime = internal->sampleTime;

shofb · March 21, 2021, 11:36pm

Glad this was of interest to you. I will expand on what I am hearing. At times the whole thing seems to slow down a bit and then catch up. I have no real measurements or proof of this but I have been a drummer/percussionist for a long time *50+ years) and am very attuned to timing and such. I can not predict when and under what conditions this happens and so “catching” it is very difficult. What I didn’t hear in this thread was that other people have perceived this… am I the only one. I could just be crazy, I’ve been accused of that before so…

I haven’t looked at the code but it seems to be that the clock could be driven by a system timer so it in effect it’s time base is not dependant on what is happening internal to Rack but on the system timers. I know there are different timers with differing resolutions so… When I was programming I used timers a lot in that manner.

Squinky · March 21, 2021, 11:50pm

Usually in audio you want to drive everything from the audio clock, rather than the “wall clock”.

marc_boule · March 22, 2021, 1:36am

An interesting way to debug this would be to perhaps try to grab some video of the speed changes, both using OBS (or equivalent), and the VCV recorder. If the speed changes are in the OBS video and not in the VCV recorder result, then it would be safe to say it’s not a CLKD / Rack issue.

shofb · March 22, 2021, 3:04am

Yeah but as I said there is no way to predict when it happens or how to make it happen.

demcanulty · March 22, 2021, 6:33am

If you are able to capture what you’re hearing in an audio recording, it could be measured. But you might want to capture it with a microphone attached to a different device to make sure it matches what you’re hearing.

Just conjecturing, it seems like it could also be caused by a wandering samplerate clock on an audio device. But I don’t actually know if that would be possible or not. Things get confusing to me after they get up to the software level. But if everything is being driven by the hardware clock on the audio device, it seems like everything else would sync to it. And you’d only have to vary by a small percentage of samples per second for it to be noticeable.