Ever wondered how plug-in companies recreate classic outboard gear in your DAW? We take a peek into Softube's modelling lab to find out.

For every real Pultec equaliser or Fairchild compressor sitting in a studio rack, millions of virtual examples occupy DAW insert points. Almost every classic piece of studio hardware ever made has inspired plug-in versions, ready to be patched in at the click of a mouse; and the same goes for guitar amps, effect pedals and even microphones. Among the market leaders when it comes to authentic recreations of hardware devices are Softube.

The company have always been based in the Swedish city of Linköping, where, in the early years of this century, an engineering student needed to come up with a final-year degree project. Unimpressed with the digital guitar amps that were then available, Oscar Öberg and a friend decided to develop their own amp-modelling system. "I'm very stubborn!" laughs the man who is now Softube's President. "So when we started initially trying to model stuff, we had the explicit goal of doing it better than everyone had done it before. We really, really kept trying until we got it. And I think that stubbornness kind of got embedded into the company culture."

After lengthy negotiations, the resulting technology was licensed to Marshall in 2007, and Softube soon found their skills in demand by other companies too. The first native plug-in to be released as a Softube product was 2007's Vintage Amp Room; since then, they have built up a catalogue of more than 50 plug-ins, and in 2014, they launched their first product with a hardware component, the innovative Console 1 controller.

To celebrate the 15th anniversary of Softube's foundation, I visited Linköping to get a sneak preview of some upcoming products, and to find out more about the techniques that are employed in creating software models of hardware devices.

## Soft Schemes

The first step in the modelling process, naturally, is to get hold of the hardware device being modelled, and the Softube offices are strewn with guitar amps, rack units and synth modules that have been acquired for the purpose. Ideally, you might think, the goal would be to measure multiple examples of each unit, but as Arvid Rosén, Softube's VP R&D, explains, this isn't necessarily helpful. "Individual variation between units can be quite significant, but it's easier to just have one and try to match that. Otherwise, you are never done tweaking if you have two. It's usually just one, but we try to make sure it's a good one."

The next step is to ascertain how the hardware unit actually works. "It's crucial to have schematics, and they need to be correct," insists Arvid. "This is not trivial, even for modern products. Even if we work together with a company and the people actually designing them, there are usually variations on schematics, and there are different versions. There's a lot of room for errors, so you always need to develop scepticism about what is correct and what is not, because that will save you time later.

"It's usually worth a lot to spend time just looking at it and trying to understand. What is this? How does it work? What's the main building blocks in the design? Have we seen them before? Sometimes, it's super useful to talk to the people designing it, because you can ask 'What is going on here? Why did you do this? I don't get it,' and they'll say, 'Oh, it's just to avoid AM radio emission here. It shouldn't matter.'"

Understanding how the hardware works and why it sounds the way it does isn't purely a paper exercise. Measurement is vital, and the schematic can help determine what Softube's engineers should measure. Arvid: "We have special equipment to measure the stuff we need to measure. Guitar amps have very high voltages inside, for example, so they're not super easy to work with. We have a lot of different tests and signals that are created to expose different aspects of our circuit, which is a very important part of the whole modelling process, to understand: What is the desired effect here? What part of the circuit creates it, and what signal can I use to expose that behaviour?

"That's an important job: to understand what are we looking for, what signals will expose exactly that phenomenon and nothing else, and where in the circuit should I inject the signal? Where can I measure without disrupting the working of the circuit? This is not always trivial, because the measurement probes you hook up to the thing might add some capacitance that was not there before, so if it's a passive EQ, that can change the response, and so on.

"What you usually want to achieve is to isolate some sort of phenomenon. A sine wave is good because it only contains one frequency, so if you send in a sine, and you see other frequencies in the output, you know that distortion happened. That's a good way of detecting non-linear behaviours — but a sine sweep is terrible for looking for linear effects like EQ, because you'll only be exposing on one amplitude or one frequency. So then you have to use something else, like noise, for example. That contains all frequencies at the same time, but noise is very difficult if you have distortion, because it's not easy to tell whether the noise that you measured at the output is distorted or not, because it will still look like noise, more or less. Then, you have some signals that can be difficult for other reasons. For example, if you measure on something like tape where the speed varies a little bit, it can be difficult to track, and you have a delay."

## Start The Engines

Once Softube's engineers are certain that they have a correct schematic and that they understand how it works, they try to divide that schematic up into functional blocks and create a mathematical model of the behaviour of each block. "Modelling in general is a very well-known mathematical process," says Niklas Odelholm, Softube's VP Products. "I mean, Newton modelled how an apple falls from a tree. At CERN, they model how hadrons collide in a particle accelerator. The math is well-known, but the equations get infinitely harder the more accurate you want it to be.

"From the schematic, we have an engine that — with some input from us — can create a mathematical model of the thing. This model is a continuous-time representation, which means you cannot run it in computer code, because that has discrete time [in other words, audio is represented digitally as a sequence of discrete samples, rather than as a continuous waveform]. So we have to go through another step that makes it into discrete time."

## Continuity Errors

As Niklas explains, however, adapting a mathematical model based on continuous time to a discrete-time environment is not without its pitfalls. "One difficult thing that can happen is that if you have something that is happening very high up in frequency, it might not be possible to represent it in discrete time. Then you have to choose where you want to put the errors. If you do a shitload of oversampling, you're just putting errors in a different place than if you didn't do anything at all. If you spend a lot of time with the high-frequency stuff, then in discrete time you get problems with low-frequency stuff. So, there's really no 'correct' way of doing it. We just try to make it sound as good as possible, as similar to the original as possible.

"We built an engine that converts the model from continuous time into discrete time, and when we have the discrete-time model, we can create computer code out of it. What we've done means the discrete-time model can be represented by different building blocks or containers. For each of the building blocks or containers, we've written a counterpart in C. So, when we get this mathematical model in discrete time, we can create a representation in C code.

"It's really cool because that means we can start with a mathematical model, and if you want it to run on an iPhone or a TDM chip or a 386 processor, it's the same mathematical model: we can just exchange the part of the C code that's different between those platforms. What it means in practice is that we can take this mathematical model, press a button and then get a lot of code that is tailored for a specific target. It could be UA, SHARC platform, TDM, whatever. All of those are highly optimised by hand, for each target.

"That is the main core in the model building, and we probably spend 10 years perfecting that. Then, whenever we encounter something that we didn't encounter before, we need to create a new way of representing it in discrete time, you know, building onto this big model."

Over the past 15 years, Softube have built up a huge library of these 'building blocks', any of which can be plumbed into their code generator to produce code for any destination platform. Thus, models that were originally created a decade ago for, say, the now-defunct Creamware Scope can still be used to generate useful code today.

## The Moment Of Truth

Only once Softube have turned a schematic into a model, and the model into functioning C code, are they in a position to discover whether their recreation actually sounds like the original. In a few cases, models that Softube created directly from the schematic have turned out to be sonically indistinguishable from the real thing. Perhaps surprisingly, this is more often the case with complex modern designs. These are built to high standards, components are used well within their expected tolerances and the different parts of the circuit don't mutually interact in unpredictable ways.

By contrast, passive equalisers are very challenging to model, as Arvid explains. "If you look at, say, the Tube‑Tech PE 1C, you have five or six knobs just going to one big network. There are very many combinations of particular settings if you have six knobs, so you have to understand the circuit, and you have to use some math that will actually calculate the correct filter for every setting."

And it's not only the static properties of any given setting that need to be recreated accurately. Just as important is that the plug-in responds correctly when controls are moved in real time. Arvid: "For some EQs, and especially when you approach synth stuff, it's also important that you get not only the right filter response but also the right behaviour when you change the filters while running. With something like the [Mutronics] Mutator filter we did some years ago, you can turn the resonance up so you have a really resonant filter, and you sweep it up and down. The math behind all this makes it so that you can achieve exactly the same filter response in many different ways, but if you just take random ways that have the right response and then try to quickly change between them, then the current state of the filter will not transfer from one setting to another in a correct way."

The open-endedness of the patchable synth environment recreated in Softube's Modular proved a particular challenge to model accurately, because it had to be possible to create feedback loops and other signal flows that are not usual in digital environments. "You just do things that you wouldn't do with other systems," says Oscar. "Take wave-folders: that process is very uncommon in other types of system because it's so aggressive. Take a sawtooth, you rectify it, and you clip it, and you put it through a filter that's distorting and then you put that through the wave-folder, and the amount that can happen in a process like that is enormous. So every piece of the chain, every input, every output, everything has to be really, really thought through."