ADSR envelopes

[cme]

Having done some profiling of Hydrogen's audio processing, the current implementation of attack-decay-sustain-release calculation is surprisingly expensive.

For the most part, at least with the kits that ship with Hydrogen, the instruments are configured without any envelope shaping so the processing time for this can be almost eliminated. But whenever ADSR is used, the processing time gets really unnecessarily expensive.

The current implementation uses a couple of lookup tables, which sounds like it should be fast but actually isn't due to the way the code is structured implying multiple divisions per frame, and the tables themselves occupying a cache-busting 32kb of memory.

There's some improvement that can be made to indexing those tables, but they are large and inefficient, and don't lend themselves well to vectorisation. By contrast, actually computing a real exponential curve for applying ADSR is very, very cheap on modern hardware (particularly if you write it in a vectorisable way) so I set about reverse-engineering the contents of concave_exponant_table and concave_exponant_table to try and do this without any functional change.

After scratching my head a bit and wondering if the curve-fitter I'd just written was somehow buggy, I eventually realised that these tables are not exponentials, despite the name (and ADSR being typically thought of as an exponential function). They're actually polynomials (x^2.71828 or so) closely approximating an exponential curve!

So, to come eventually to my point. I would like to propose changing the ADSR envelope to exponential functions, which will result in a slightly different envelope. The audible difference should be barely noticable, and in return the CPU processing requirements for any songs that actually use ADSR will reduce significantly.

Does anyone have any opinions on this?

[theGreatWhiteShark]

They're actually polynomials (x^2.71828 or so) closely approximating an exponential curve!

That's totally strange. Can you think of a reason it could have been designed that way? Maybe a buggy implementation of the exponential/logarithmic function in the language used to create these tables? But on the other hand, these are amongst the very basics of any language at least partially concerned with math.

I would like to propose changing the ADSR envelope to exponential functions, which will result in a slightly different envelope. The audible difference should be barely noticable, and in return the CPU processing requirements for any songs that actually use ADSR will reduce significantly.

Sounds good.

Nice find by the way.

[cme]

That's totally strange. Can you think of a reason it could have been designed that way? Maybe a buggy implementation of the exponential/logarithmic function in the language used to create these tables? But on the other hand, these are amongst the very basics of any language at least partially concerned with math.

I actually had to have someone else point out that 2.71828 is in fact.... e. I just didn't notice. 🤣

I think perhaps when ADSR was implemented here that there was a misunderstanding about what 'exponential' should mean in the context of attack/decay/release curves, as this basic x^e table (and an x^(1/e) table) is further manipulated to give it the right general shape. I think because there was an intermediate process of "making the function fit the desired shape" the fact that the table it started from was the wrong sort of function got lost along the way and it didn't matter.

[theGreatWhiteShark]

Oh boy. x^e instead of e^x? Someone slept through their complex analysis lecture. But, well, things happen and I'm impressive it still somehow worked "as expected".

P.S. the whole idea of a per instrument ADSR feels kinda archaic next to the layer-based SampleEditor

[cme]

P.S. the whole idea of a per instrument ADSR feels kinda archaic next to the layer-based SampleEditor

It's also kinda buggy at the moment since we can play multiple notes concurrently on the same instrument, but each new note resets the envelope's tick, because it's stored in the per-instrument ADSR object. So say we have a sample with a bunch of noise at the end:

|,-'-.-'.-'-xxxxxxx|

and an ADSR envelope with some attack and decay and zero sustain:

  __
|/  ''-.._________|

Normally the noise is inaudible because the decay to zero masks it. But if we play two notes on the same instrument after each other:

  __       __
|/  ''-.._/  ''-.._________| ADSR
|,-'-.-'.-'-XXXXXX|          Note A
          ,-'-.-'.-'-XXXXXX| Note B

|,-'-.-'.-,-XXXxxx---------| Result

This is an easy fix (move the tick to some other state) but it does indicate the design is a bit crufty. It does at least have the advantage though that it's dynamic, doesn't need to save any samples, and the Release time is dynamic with the length of the note.

[theGreatWhiteShark]

we can play multiple notes concurrently on the same instrument

Plus, there are 1-32 components for each instrument. Seems like another place where things did grew too naturally. :)

The Instrument class also features left and right peak levels as well as some stuff concerned with the resonance filter. Maybe they suffer the same problem.

[theGreatWhiteShark]

The Instrument class also features left and right peak levels as well as some stuff concerned with the resonance filter. Maybe they suffer the same problem.

The stuff concerning the filter looks fine. But it seems the peak value displayed in the Mixer is the one of the last Note of that instrument processed by the Sampler. If multiple notes are present, their levels sum and the peak value is wrong.

[cme]

So, actually it turns out there is a fast way to approximate this curve that's only a bit more expensive than doing an exponential decay, but my googling didn't find it, I had to sit down and think it through. I need to check the accuracy is okay, but if it is, I'll use that rather than exponential decay for the sake of keeping things as-they-are. There will be some differences in the calculated waveforms, but way smaller than those for a different envelope shape.

[cme]

After some investigation, the approximation method necessary for the attack phase is still very expensive. But also, having looked at the envelope, I don't think the current profile's attack is particularly close to what most people would expect or want, as it peaks sharply and instantaneously before decaying, so I've come to the conclusion that a more classical exponential function isn't just quicker to calculate, it's also more desirable.

With some curve fitting to find parameters that give something close to the current envelope shape, I have an implementation that gives this envelope shape ("new.data") in comparison with the old one ("old.data"):

Benchmarking just the ADSR time for non-trivial ADSR calculations, on an M1 Macbook Pro (and enabling -ffast-math for that routine), we get:

Benchmark old ADSR method:
ADSR time:  "64.61us (63.3958M frames/sec) +/- 0.295%"
Benchmark new ADSR method:
ADSR time:  "1.98us (2068.69M frames/sec) +/- 2.671%"

x86 doesn't scale quite as well, being only about 5x as fast on my x86 machines, but might do better on something more modern.

[theGreatWhiteShark]

NIce! Yeah, I don't think anybody will every notice. Plus, having an exponential is probably what people would have expected in the first place.

[elpescado]

Fun fact: our ASDR implementation used to be... funny. When I migrated our unit tests to CppUnit, I wrote tests for ADSR and it turned out that our envelopes looked like this:

;)

[cme]

Oh dearie me.

I think it's probbaly safe to say, these have almost certainly never been used much 😆