Can the release of an adsr influence a clock (bug) ?

I was trying some sequencers, and I just noticed that when I set the adsr release to zero, the clock beat goes down. I don’t know exactly how much but it can be divided by two. I tried with two clocks and all the sequencers you see in the picture and the behaviour is the same. Is this a bug, or normal behaviour? If so can someone explain what is going on?

I’ll show you a screenshot in case I do something wrong (beginner here)

I’m not sure what you mean by ‘beat goes down’ or ‘divided by to’. But…the ADSR does not affect the clock. It’s a one way street from clock, via sequencer to ADSR. I assume you are referring to the total envelope time?

Most sequencers just ‘forward’ the incoming clockpulse (some can generate a gate of fixed or variable length on an incoming trigger, or even generate multiple triggers/pulses for each clock pulse).

A very short clockpulse might then trigger the Attack (here, set to minimimum), might not even reach Decay/Sustain, and will then fall back during Release (here, also set to minimum).

Depending on pulsewidth (of the clock pulse) and the minimum Attack and Release times, this might generate a very short envelope.

Then the amp would also open and close real quick. Might just produce a bit of a click, if clockpulse is short, and envelope and amp are fast enough.

Seems to be a bug of the vcv ADSR module as it’s not happen with befaco or Instruo ADSR.

The tempo really slows down. On the picture you can see that the tempo is 120, but when the release is zero the tempo drops to about 60 (it still shows 120). And if the release is very low it’s about 90. very strange. But in the meantime I tried with other ADSRs and it’s ok. It really looks like a bug

Thanks anyway to try help :slight_smile:

I tried to reproduce your patch. With the ADSR release set to 1ms (I’m assuming that’s what you mean by zero?), I still get clicks at 120bpm… Perhaps you could upload your patch?

Here it is. Just just try to decrease the release at min, and the tempo should slow down (not the display wich will stay at 120), whatever the clock module. Sequencers tests.vcv (2.5 KB)

I am not able to reproduce what you are reporting on Windows 10 running VCV 2.0.6

What are you running on?

Not all undesirable/unexpected functionality is a bug. It might all work as designed and intended, just not as expected by the user (in this case: you). Might also work differently from other implementation of similar functionality (in this case: Befaco/Instruo).

Also…there could be all sorts of obvious or less obvious factors at play here.

Reading this it seems not all triggers lead to audible/visible results. In that case some triggers would be skipped. Very suspicious that the various 'tempo’s you mention are always at some integer ratio of the clock frequency.

120 → 90 = 4:3 120 → 60 = 2:1

It pretty puzzling to me…

Sort of off-topic…

As far as I know, the Befaco and Instruo attack and release times are pretty fast/snappy and go down to linear zero (0 ms, immediate). The VCV ADSR has slower minimum attack and release rates.

Might also have different sensitivity to Trigger amplitude/width. This is not as standardized as you might think.

EDIT: The VCV Rack Voltage Standard for Trigger/Gate signals is 10 V (where triggers last for 1 ms). But thresholds might vary at input of various modules.

The Befaco envelopes are really fast. The envelopes (AD) can even be used to generate audiorate signals (e.g. when looping) or do stuff like waveshaping (when triggered at pitched audiorate).

Same here. Can’t reproduce.


Have you hooked up a Scope yet? To SEE if any signals are generated at the outputs of the various modules you have hooked up?

@DaveVenom I run on vcv 2.0.6 on Mac OSX el Capitan. Pretty old OS may be the problem.

@kwurqx As there is no backward connexion between the ADSR and the clock it’s not seem to be an expected functionnality. various tempo I mention are approximative… and not fixed. it’s like in low value the release act as a controller for the clock rate. But if some can’t reproduce this behavior with my patch it’s defintively a bug. By the way intersting “Sort of off topic” :slight_smile:

Thank’s to you guy’s

Good idea. Because I’m still curious about what’s going on

if I mute the signal or disconnect just one entry on the audio8, the clock frequency behave normaly again.

Same thing if I choose the simple Audio module instead of the Audio8 module. I think I find my woraround Haha.

Thank you all

Nice community by the way.

Uh…I can’t follow that logic…

Just because others can’t reproduce your findings does not make your findings a bug.

A bug is a proven discrepency between intended/defined/promised/contractual behaviour and actual observed behaviour (in this case of some piece of software).

I guess in this case we can at least pretty safely assume that there is no actual bug involved…

First Computer Bug, 1945


Definitely not a bug with the software. Could it be that what the OP is hearing has something to do with audio buffering. Which explains why it appears to slow down when there is less constant audio. Otherways it is truly a mystery.

All realtime factors (like buffer underruns and such) can relatively simply be bypassed by non-realtime rendering/recording to disk, thus possibly excluding/pinpointing possible causes.

As far as I know VCV Recorder is non-realtime. But if not, there might be non-realtime alternatives within the VCV Rack universe…

VCV Recorder

1 Like

Then this can only mean one thing. There is a moth stuck in the release slider of adsr module. :crazy_face:

And the winner is… auretvh Or in all case you’re close.

Im’ run vcv on an old macPro bi-Xeon. Today when I’m start my session I’ve set engine thread on 12 (16 available). In addition to the above-mentioned weird behavior I’m notice a really high CPU usage and some cracks.

Now setting <=8 and all is fine. May be VCV don’t really manage the two CPUs, or something like this.

1 Like

Great. I’m glad it’s working. I noticed that alot of people allocate alot if threads to Rack immediately because they have them available, but the rule of thumb is, start with one thread, and as your patch grows, add more threads if you experience any glitches. Enjoy.


Generally (with VCV Rack) keep the amount of threads as low as possible. Generally from 1 to 4 (as my VCV Rack GUI shows/advises for max performance/modules).

I’m on Wintel, but assuming similar advise goes for Mac as well…

You will find multiple threads with questions and answers on maximizing performance on Wintel, Mac and other platforms.

1 Like

No, actually the vcv specifications for triggers is very well specified. But you do need to read it.

1 Like