posted 22 February 2014 16:17            

envelopeshaper.kym

To apply an envelope to a signal, we usually multiply the signal by the envelope. But this time, let's cancel out the signal's original envelope before applying the new one. We can do that by multiplying the signal by (newEnv / origEnv). Dividing by the original envelope should make the amplitude envelope of our new signal always equal 1. Then multiplying by the new envelope will apply the new envelope shape to the signal. If we take the log of each envelope, we can subtract instead of dividing:

newEnv twoLog - origEnv twoLog

The new, desired envelope can be a cross between a log envelope with a sharp attack and one with a slow attack with a cross control called !ScaleAtk:

((1 - !ScaleAtk) * fastEnv + (!ScaleAtk * slowEnv) - origEnv

If we assume that a fast envelope follower is one that gives a good estimate for the original envelope, this becomes

((1 - !ScaleAtk) * fastEnv + (!ScaleAtk * slowEnv) - fastEnv

which simplifies to:

!ScaleAtk * (slowEnv - fastEnv)

Now we have a control over the admixture of slow and fast attack. To control the speed of the release, we use a similar expression (again using the logs of the envelopes):

(slowSustain - fastSustain) * !ScaleRelease

Since we are still in log space, we can add this to the other envelope (since this is the same as multiplying in linear space).
As a last step we turn it back into a linear amplitude using twoExp. Since this amplitude scale can grow aribtrarily large, we take the minimum of this amplitude and a !GainMax control.

Note that subtracting the log of the fast envelope(s) is like dividing by the ampltiude envelope of the input signal. This is a form of automatic gain control; when the amplitude of the signal goes down, the gain on that signal goes up (and vice versa).

posted 24 May 2014 13:16            

AttackDecayModule.kym

I've just put an AttackDecay module together that may help out in this transient designer as an alternative to the peak detector.

The problem with the peak detector is that it has an odd curve that assumes that the signal will reach + or - 1. If it doesn't the curve shape will be different, i.e lower level signals will have a faster attack and slower release than high level signals and hence the resulting level is not representative of the input level. If you was to try to use this in a normal compressor certain levels would act like an expander and it would be virtually impossible to control of the signals dynamic range. In this project it may not be a problem as the intention is to play about with the dynamic range (not control it).

Instead I've made an AttackDecay module that is based on the feedback pair (which also forms the needed one sample delay) and a sample rate up down detector. The detector is a comparator between the input and the feed back, which is made from a minus module and an equality module (which is acting as a sample rate asLogicValue module). This is switching between two different input/feedback interpolators to control the up and down change rates. I've encapsulated the module but if you want to see it opened up , look at Attack Decay Test bed.
I've not put an absolute module inside the encapsulation as this restricts the uses, and can easily be added after.

In the attached I've included the "Peak Detection compare" sound to see the differences in the way the two modules work. It uses a pulse train as a square wave into a scale and offset as a form of test input. First you can see that the shapes are very similar but not the same. Turning the scale down and moving the offset up and down will show that the different methods used.

with the offset back at zero, if the input is set to scale 1 you would expect the output to average around 0.5 as long as the attack and decay are the same values. By hovering the mouse over the scopes you can read out the value in the top right of the scope. If the input scale is set to 0.5, you would expect the average output to be 0.25. Here you will see that the two are quite different. This is clearer if you set the frequency to 1000 hz and/or set the attack and decay to 50 ms. Also altering the frequency will change the average level ever so slightly in one but not the other. This is more noticeable with attack and decay set to 1.5 ms.

The test jig can also be used to check the timings. With a scale of 1, a decay of 0s and freq of 100 hz the output should reach a peak of 0.5 if the attack is set to 5 ms. The decay time can be checked by putting the attack to 0 s and seeing and the peak dip reach 0.5 at the various frequencies and decays i.e 1000 hz should equate to 0.5 ms.

I was going to try it out in the transient designer but I forgot that the feedback names have to be unique if more than one module is used, (which they are not in the encapsulated sound), and I can't remember the formula to automatically make the names unique yet match.

Any help here would be appreciated.

Thanks

Pete

BTW The AttackDecay module won't work on a Capybara as the feedback module doesn't go down to 1 sample delay, but I have a Pete's DSP Code version if needed.

posted 01 October 2015 04:22            

AttackDecayModule.kym

Somehow I overlooked this - very interesting stuff!

I've made some adjustments:
- used UniqueMemoryWriterRecordingNames and CancelUniqueMemoryWriterRecordingNames to solve the problem with the naming of the feedbackloop
- replaced the equality with a threshold for more efficiency (threshold: 0, hysteresis: 0 works as a "sign gate")
- tweaked the calculation of the up/downRate to this:

code:

---

| NoOfSamps |
NoOfSamps := (((SignalProcessor sampleRate) * (?Attack s removeUnits)) vmax: 1).
1 / ((1 / NoOfSamps) twoExp) 

---

I'm already working on a version which can process framed data the same way