question of understanding s&h rate

Hey,

I’m currently playing with the VCV Random S&H module and I don’t understand why the rate samples two times per second when the rate is set to 1 Hz. Can anyone tell me the logic behind this? As far as I know, 1 Hz = 1/s, so only once per second?

You are right. That seems to be a bug if not intentional. But I don’t know why it should behave differently then a LFO or a clock. Are you going to report it? VCV - Support

Reminds me of a similar issue with the ADSR module, though in the opposite direction. The ADSR attack/decay/release rates are significantly slower than the value reported by the control. VCV Fundamental ADSR Timing does not match settings

I did not report that as a bug, though in my mind it could be considered one.

Does this have an effect on old projects opened in vcv 2?

I didn’t see a difference with the ADSR timing between V1 and V2. They were qualitatively the same to my ear, so I only bothered measuring on V1. But if you want to talk in more detail about the ADSR, maybe respond to that thread instead of this one. I did not want to hijack the topic, just wanted to draw attention to parallels between the issues.

1 Like

I watched a video from Jakub Ciupinski. He used Rack version 1 and the random module’s rate parameter behaved the same as it is now in version 2. So do you think a report will make sense or is just destroying a lot of patches who depend on this “bug”?

1 Like

Thanks for your reply. As long as you don’t depend on the exact values it’s no big deal. I calculated some values to get polyrhytms with a clever way of sampling a sequencer in combination with the clock’s tempo. So it gives a little bit of headache if you search for errors because you think the rates are what they show in the parameter label.

Yeah, that is kind of where I am with the ADSR - a minor irritation, but possible to work around. Seems like it ought to be possible to provide a context menu option to fix the timing to match the displayed values. The default could be to preserve the divergent timings. That way old patches will continue to work as before. Seems like that could apply to both modules.

1 Like

Yes, that could be possible. But I think a patch with some things running at half speed is not as important as the correct labeling. This modules are used in education from what I know, and imho the fundamentals should give correct values, when they were entered or set. I surely would say, that this is a very low priority bug, but it is one.

3 Likes

Thanks for that perspective Markus. I will apply that same reasoning to the ADSR issue and file a bug report on the ADSR.

1 Like

@DaveVenom @54lz Can you both raise your ticket at VCV - Support

1 Like

Yep, that is now my plan after reading the response from Markus.

Legend. Thanks @Markus for recommending.

1 Like

Done!

1 Like

I don’t really see any need for a fix to be patch breaking… It could just be a case of recalibrating the labels - so in this Random example where it is cycling twice per second at a rate of 1Hz, a saved patch that was reopened with a fixed version would still cycle twice per second, but now the rate would say 0.5Hz.

Why didn’t I think about this? That’s an elegant solution.

Agreed. I proposed a similar solution as one option for fixing the ADSR timing issues in my bug report. But in the case of the ADSR it would make the attack and decay/release scales asymmetric, as the current attack is significantly faster than the decay and release.