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?
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
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.
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!
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.
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.
Does sampletime really vary from call to call? I just assumed it was shorthand for 1/sampleRate
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.
Why would it if it just dropped a sample? I wouldn’t.
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.
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.
Usually in audio you want to drive everything from the audio clock, rather than the “wall clock”.
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.
Yeah but as I said there is no way to predict when it happens or how to make it happen.
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.