Rise and fall segments

[qiemem]

Stages ramp segments are notably not slew limiter rise and fall segments, even though they can feel similar to DUSG-style function generator slopes. They take a fixed time to go from start to end, even if, for instance, start and end are the same value. This means that, for instance, you can't have independent rise and fall slew times.

Another way to imagine ramp-like segments working is for them to move from start to end at a given rate. Once it reaches the end value, it moves on to the next segment. This could be used for:

• Independent rise and fall slew rates: rise-hold-fall-hold in loop, mult signal to both holds
• Envelope follower (a la Maths) with short rise and high fall in above
• Slope detector
• Adaptive attack and decay times (though I suppose you can fake this right now by multing the signal to the time of a ramp)

Proposed implementation:

Obviously, these are very related to ramps. Currently, button+slider is not used on ramp segments, except for LFOs. Thus, could make a rise segment by button+slider to the top and fall by button+slider to the bottom. Indicating rise and fall segments is difficult: perhaps rising and falling type LED, but that could be confusing with looping.

A rise (fall) segment would:

• Sample its start value and track its end value
• Rise (fall) at rate defined by slider, with shape defined by pot; rate = rate of attack (decay) segment going between 0 and 8 volts
• End when value is equal to or greater than end value

Unfortunately, these segments would require passing extra information between modules, and we're at the max right now. Might have to add another stage of module communication.

[jb0000]

I had an alternative idea that would solve at least some of those use cases: It involves the non-gated, non-looping, single green segment which could slew incoming cv with

• rise rate set by the knob
• fall rate set by slider

This would give us:

• [X] Independent rise and fall slew rates
• [X] Envelope follower (a la Maths)
• [x] Slope detector ? (not sure could also use a yellow segment to slew instead? but how do you compare within stages?)
• [x] Adaptive attack and decay times (wait isn't that just a exponential response? I don't understand that feature)

plus:

• ASR envelope in single Segment
• Weird sample rate reduced filter for audio signals
• Different envelope heights with different trigger/gate lengths (when rise slew is long enough (is that adaptive times?))
• Does not need further visualization
• No need to pass on extra information for second stages

Cons:

• no cv over rise and fall-time
• no direct exponential/logarithm response control (could be done via button + knob / slider)

It should still be free to use since the offset/attenuate suggestion was done with the yellow looping segment.

What do you think?

[qiemem]

Great idea! Just threw it together and it works great. I had been considering something like this a while ago, but think I dismissed it since you wouldn't have shape control or cv over times. Playing with it now, it works well despite these limitations.

I implemented using the same slew functionality as yellow segments, just with the slider controlling a fall slew and the pot controlling rise slew. This means the resulting function has an RC curve ("log" attack and "exponential" decay), which I think works okay since that's generally the most useful when used as a audio envelope (assuming the VCA is linear...)

Slope detector ? (not sure could also use a yellow segment to slew instead? but how do you compare within stages?)

Not sure this works I'm afraid. Having rise/fall segments usable in groups would mean that the stage gate tells you whether you're rising or falling. But as a single segment, not sure how this could work. No big deal though; slope detectors are pretty niche, and you can get a lot of the same effects by just using the signal/inverted signal to trigger gates.

Adaptive attack and decay times (wait isn't that just a exponential response? I don't understand that feature)

Ya kinda. Just meant the time to decay and attack depends on the distance. This is compared with normal ramp segments which have a set time and adjust slope to compensate.

no direct exponential/logarithm response control (could be done via button + knob / slider)

I think it might be okay just leaving it as an RC curve? RC is the easiest and most natural to implement (though linear is also super easy of course).

One thing I had been working on several weeks ago is removing the "click" you get when using decay envelopes into a VCA by softening the attack a bit. The downside of my approach was that there are cases when you want an attack of literally 0 (which is what decay segments are in stock). The nice thing here is that this gives you another single segment way of producing an envelope that's useful for VCAs controlling audio without compromising the attack of decay segments. So I can revert that change, which makes me happy.

Thanks again for the great feedback!

[qiemem]

Closing as the new single NGNL ramp behavior is good enough for now. Might revisit later though.