Slew limiter modulation - intended behavior?

xorxor
edited July 10 in Known issues

I was getting unreliable results dynamically modulating the slew limiter. Sometimes it would modulate fine other times it would appear to use the previous modulation amount. Then I accidentally discovered that if you set the rise/fall to 0.1ms (it was 0) then it always works. Is this intended?

Here’s a simple project: https://www.dropbox.com/s/b4cnxjk0gw1oh82/Slew%20limiter%20modulation.drproject?dl=0

And a video: https://youtu.be/VSvi4X4ADjE

Comments

  • Well, as usual, I was a bit premature in assuming that the slew limiter problem had a reliable workaround. 0.1 seems to work at 45bpm but doesn’t work at 30bpm. Seems like there’s just a bug in how the slew limiter reacts to modulation.

    @giku can you take a look?

  • Have you tried a longer rise/fall time, maybe 0.15 or 0.2 ms? I wonder if it needs to be some minimal fraction of the beat time. This might be a work-around until it's fixed properly.

  • Yep. I’ve tried 1, 2, 5, 10, 20. Some work at one bpm and fail at others. Some are unreliable, they work if you change them while the transport is running but fail when you reload.

    The only 100% reliable workaround is to use a feedback to drive the modulation. It’s a 10ms delay but a smooth ramp.

  • edited July 12

    A suggestion.

    Have you tried the 'cv glide' module instead of

    the 'slew limiter' until @giku has had a look at the issue?

  • Good idea, thanks. It almost works but the modulation is a step behind the input. The modules that do the +1 emulate how the midi-to-cv outputs overlapping gate signals. Here we have a free-running oscillator where the filter is modulated by the pitch value scaled to 0-1 with a ramp duration that should be the velocity of the new pitch. In the sequence the velocity is 1, 10, 20, 30, 40, 127. Ignoring the first cycle, the first step takes a long time to descend from 1 to 0, the second step is instantaneous, the rest are slightly longer than the one before. I would expect the behavior to be that the first step drops to 0 instantaneously because the velocity is 1 (very low/short) and the last step should take a long time to get to 1(127) because the velocity is 100 (very high/long).

    Seems that Drambo updates the modulation of the glide after it processes the new note and decides how long the glide will take. For this particular idea I need it to update the modulation before processing the note.


Sign In or Register to comment.