Density mkII – reworking the audio engine

While working on the Density overall re-design I was working extensively on the audio engine as well but just for one single reason: The one thing I was missing in the original design was to have some more “responsive” gain riding possibilities but without the usual tradeoff of introducing more distortion or compromising the transparency. And (unsurprisingly) that turned out to be not that easy.

Developers friend: the oscilloscope

Fortunately, there are a couple of gadgets in the audio developers toolbox which can tremendously help in getting the things right or to avoid (time consuming) audio listening tests in the early development stage. The oscilloscope e.g. is a good tool to investigate a certain attack and release curve behaviour or to perform tests with automatic leveling circuits just to name the two. This is mostly performed on periodic input signals like raw basic waveforms. While re-designing the audio core of Density I did a lot of experiments with that and even checked some weird and funny approaches to compression which had lead to some interesting insights here and there while working towards the final circuit.

A CPU cycle measurement tool

At the end of the day not everything which looks promising in the oscillator actually does sound necessarily good or, in other cases, the computational costs of that algorithm is simply way off. The latter one can easily checked with CPU cycle sort of tools which provides instant feedback on how many CPU cycles a certain algorithm actually consumes or which performance optimzation gains more speed. I’ve used such tools and methods quiet a lot during the technical design of the mkII version and that way I was able to introduce some new algorithms with higher precision and resolution but at lower computational costs (compared to the original design). In general this is better already been finished during the design phase opposed to upon the end of development where this can cause more impact (overall redesign or so) and therefore potentially can waste a lot of development time. Further Assembler code tuning on the other side is better be done to the end of development for the sake of programmers efficiency.

A pure second order harmonic in the analyzer

Christian Buddes audio plug-in analyzer is another excellent tool when you already have managed to get your algorithms compiled into a VST dll-file. It’s really usefull on judging frequency or harmonic spectrum issues like intermodulation distortion or the compressors transfer curve and things alike. However, it cannot see all things and sometimes even weird stuff or nothing is showing up though it normally should do so. This can be the case when e.g. measured algorithms just work on or behind transients, on mid/side encoded signals or just works differently along the entire frequency spectrum. In the plot above everything is ok and it shows an algorithms effect where just a pure second order harmonic is produced (oversampled). In DensitymkII the compression algorithm itself is capable of generating a pleasant second order harmonic during the compression duty cycle. This replaces the “phat” mode of the previous Density version and is inherently active.

10kHz sinus signal pre and post compressor

If the developed plug-in now properly loads into a host, another common technique for measuring the dynamic behaviour of such an audio plug-in is to load the compiled plug-in into it so someone can apply special test signals on it. Continous sinus based signals at different frequencies (e.g. 3kHz, 10kHz or even rather low frequencies for measuring bass response) at different levels over time are typically used. The outcoming overall curves are then compared to the original test signals or to some reference curves of other devices or so. This was a lifesaver during the beta test stage of DensitymkII where some subtle discontinuities in the release curve were spotted (caused by a malfunctioning program dependency) and so it could be finally tracked down. The way program dependency in the mkII is actually implemented now is a major part of the unobtrusive compression action and it offers both now: strict peak compression and relaxed and punchy sound.

An audio wave player

Normally, one would increase the number of audio listening tests along the progress of development over time and therefore switch over to separate testbeds to do so. In the development framework I’m currently using, one is able to just load audio files into a wave player and to hear it passing through that algorithm which is currently under developement. Thanks to instant re-compile there is no real lag when re-triggering audio and so you can hear and judge the code changes instantaneously during development – what a time saver!

Credits

Many thanks to the Synthmaker community and Christian B. for providing all those usefull tools!

References

the compressors sidechain: filtering

soft-knee compression and beyond

compressor gain control principles

in the lab – audio listening tests

Density mkII – reworking the usage concept