How to build eQuality (technical angle)

Some of you might find it interesting to know what goes into making a product.
What I mean by that is, I think it’s interesting, so I’m going to tell you. 🙂

Starting at the bottom, working up:
1) Steinberg’s VST SDK.
Can’t really make a VST without this one…
2) My own VST->AU wrapper layer.
Since it’s compiled-in code, (and due to some other detail) this makes building an AU really fast and efficient.
The first version of this was built for the original TBK… a looong time ago! 🙂
Since then it’s grown, so that it handles most things automatically. AU ports of my own code take about 5 minutes.
3) Plugin Baseclass
Most plugins have the same essential functionality – things like handling presets, automating things, synchronising
with the UI, converting parameter values to display text/values and back again. I have a base class that does all the legwork for this.
4) cJSON + PluginJSON baseclass
This is pretty geeky, but I’m very proud of it. Most plugins I’ve worked on have needed to gain a parameter here or there through their life.
Generally this means problems with sessions, but a while ago, as a programming exercise, I built a JSON library in plain C, called cJSON. JSON is a simple, stable format for storing data; it’s been described as “fat-free XML”. Some things make sense stored in XML, but most things do really well as JSON. JSON is almost the X in AJAX. Now, I have a class that saves presets and preset banks as JSON, which means that as I add features, there’s no breakage of old sessions!
5) VSTGUI, ezXML and my automatic UI system.
A lot of developers have strongly criticized VSTGUI; my friend Angus (FXpansion) is particularly vocal on it.
VSTGUI is not without its flaws, but I’ve concluded that VSTGUI is the right way forwards for two reasons:
– The flaws can be overcome
and
– EVERY SINGLE HOST is tested to support VSTGUI.
That last point is really the killer. With some work, you can get VSTGUI under control, and I think I’ve done this.
The sourcecode for the eQuality UI is 3 pages long. To put that in context, SV517mk2 had about 9 pages, and SV517mk1 had 60.
eQuality UI is more feature rich than 517mk2, which is more feature rich than 517mk1 (which was not my code).
This is thanks to the UI system I’ve built, that allows me to describe the UI using XML, using one line of text per control, formatted to reflect the onscreen hierarchy of the controls. It’s very similar to the mechanism I used in StudioDevil AMP, which has an extraordinary amount of UI functionality. To parse the XML I use a library called ezXML, which compiles very very small, and does a great job!
6) UI controls
The stock VSTGUI controls are great, but it’s usual to need to extend the functionality a little. I have a library with a raytracer built in, that re-raytraces the knobs as you turn them… fast! Admittedly that probably won’t make it into the finished product (to save CPU while you use it), but we’ll see! 🙂
You also need a chunk of code to build an EQ graph that’s draggable, shows the EQ curves, draws the spectrum analyser, etc.
7) FFTs, Convolvers and Spectral processors
I use the Ooura FFT. One day I’ll have enough money (it’s VERY expensive) to get the Intel Performance libraries. When I do, you’ll all get a CPU saving! 😀
There’s a library that converts responses to minimum phase (joint effort with Marc / StudioDevil),
an impulse windowing library, and a fast FFT-based zero-latency convolver (Marc discusses these extensively in his PhD thesis! He helped me out a lot!).
8) EQ code
This is the real meat of the DSP.
I have a library that has all the analogue prototypes (used for linear/minimum/analogue phase modes, and for designing the digital EQs),
and, because I collect these things, implementations of all the common digital prototypes that people use (RBJ, Orfanidis, etc). Nice to have them at least 😉 Don’t worry… anything unused gets stripped out at link time. 🙂
This also handles the “music” (gain-q) stuff, and drives the FFT/Spectral stuff.
It also drives the new digital design mechanism, that I’m going to post about in the coming weeks, which makes eQuality sound so smooth and sweet! 🙂
9) The special EQ design stuff.
… more to come…
10) The plugin code itself!
Finally, with all the hard stuff handled by a bunch of libraries its built on, 6 pages of code declare all the parameters, handle the special stuff, like Range and Shift, control all the EQ code, and trigger the DSP, handling the logging of samples for the spec-analyser, the VUs, the M/S pre/post-processing.

And that’s how it’s made! Easy as 3.14159265358979323846 😉

Dave.