I've been doing more projects that involve digital control of analog circuits, and I found myself needing to generate ADSR envelopes in software, on an Arduino. I found some approaches that implement a digital filter to simulate the RC curve you get from a capacitor charging. This usually involves slow floating-point calculations that the Arduino isn't well-suited to crunching.
 |
| RC curve ADSR - AudioMulch |
Look up, it's a bird, it's a table
A classic way to avoid slow math is to precompute it, and store the results in a table. Then you just look up the result for your given input. Storing the result for every possible input can result in an excessively large table though, so maybe you want to store fewer results and estimate values between them. This is called interpolation, and there are multiple ways of doing it. We could use the continuous curves of splines to connect our points, but this would be slower than the actual calculation we're trying to avoid. Instead we'll use fast linear interpolation, that just draws straight lines.
 |
| An interpolated attack curve |
Usually you would store a series of x and y coordinates, and then calculate the line between each pair. We really only care about the lines though, so we might as well precompute those also. Thinking back to algebra 1, we just need to store the slope and y-intercept to define them.
It's not a phase, period
Now that we have a curve, we need to progress through it over time. A naive approach might be to march through every possible value, and simply do this as fast as needed. This is likely a waste of processing time, and we can instead strategically skip over some values to progress through the table more quickly. The Prophet 600 reportedly updates its envelopes at just 200Hz. It simply takes larger or smaller "steps" each update to change the length(period) of the stages.
Ain't no half‐steppin'
Another beginner trap is to only think in terms of whole numbers, since we're avoiding floating points. Let's say we have 10 possible output values, and our smallest step is 1. It then takes 10 steps to get through all outputs. If our next smallest step is 2, it only takes 5, and that's twice as fast. It'd be nice to have 1.5 as an option. We can do this by using fixed point numbers. We can use steps of 15, and count up to 100 to get the same effect as steps of 1.5 counting up to 10. We just need to divide by 10 at the end to get the correct output. If we use powers of 2, instead of 10, the division becomes bit-shifting, and that's very fast.
 |
| Bit shifting to divide by 2 - Wikipedia |
Non-canonical sections
We just saw that a step size of 2 is twice as fast as 1. This hints at the funny relationship between the step size and the period. It's just period = max count / step, but this results in a very uneven response. When the step size is small, a slight change results in a very different period length. When the step is large, even significant changes have very little impact on the period length.
 |
| period = max count / step size |
Algebra 1 strikes again; This curve is a conic section called a hyperbola. It comes from us having a function in the form of 1/x. We can't really help that we're dividing a constant by a variable, but we can control the variable. If we replace x with 1/x (the reciprocal), we effectively multiply by x instead of dividing by it. 10/(1/x) = 10 * x. Now we have a straight line.
 |
| period = max count / (1 / step size) |
This looks better, but it doesn't feel right when mapped to a control. This is because the period is being adjusted with the same granularity on slow attacks vs fast attacks. That ends up being too coarse at one end, and too fine at the other. We need a curve after all.
The epitome of hyperbola
The hyperbola we started with was too severe, and didn't pass through any particular points. What if we could fix those problems? Then a hyperbola might be a suitable curve.
1 / (x + 1) / (10 - x) will approach points 0,10 and 10,0. That's helpful. We can change the severity of the curve by multiplying x by a coefficient in the numerator. Here's 1 / (0.25x + 1) / (10 - x)
 |
| period = max count / ((0.25 * step size + 1) / (10 - step size)) |
By continuing to manipulate this formula, I landed on a new one that lets you adjust the maximum period without distorting the curve. I'm using 10 bits for the step size, so the number 1024 comes from the maximum step size. c sets the curve, and m sets the maximum period
 |
| period length in seconds |
c, m and the constants are all known at compile time, so this can be simplified in our program prior to execution. A c of 4976 and an m of 3 simplify to roughly:
 |
| c = 4976, m = 3 |
You can graph this function and adjust it in real time at this desmos link
Starting over
There's another snag, restarting the envelope. It's tempting to begin counting from 0, but that's not how analog envelopes typically work. They start the attack stage from whatever their output level currently is. That would be simple, but we progress through our stages linearly, while the output is the result of our lookup table. So we have to convert from an output level, back to a position in the attack stage (that yields the same output). I chose to use a second lookup table to convert outputs back to attack stage positions.
Release
The C++ source code is on my github here. The focus is really the ADSR library, but the project is a functional example. It uses an Arduino nano, four potentiometers plus a trigger for input, and an MPC4728 for 12-bit analog output.
Here's an incomplete prototype that I wrote in JavaScript. The gate is controlled in real time by mouse click. The red dots indicate the progress through each stage, and the black line is the actual output.
