In the VANDAL cabinet simulation, we divide the process into speaker and enclosure, and model both parts seperately. This is a flexible approach that lets the user choose even untypical combinations of both components.
But this calls for all kinds of interaction and is asking for trouble, as we will see.
The virtual speaker
Whether you treat the cabinet as at least 2 discrete components or not, a speaker’s frequency response curve would always have a great impact on the resulting sound. So, you would have to answer yourself at least these questions:
Where do I take a speaker’s response curve from? What does affect the response?
Finding proper answers is a tough thing.
Many people in this business would take measurements of an actual speaker/enclosure combination here and feed the result directly into an FFT-based filter algorithm. The good thing is, by taking care of a sufficient FFT size, you can come up with a pretty accurate frequency response curve. So the matching part would be perfect.
But… wait a minute.
By declaring such measurements directly as a ‘speaker’ component, we’re running into a few, significant, problems:
- We take measurements using a specific microphone, with its specific frequency/phase response, its specific directional pattern.
- We’re recording at a specific position on the membrane. The sound changes dramatically when we move the mic just a little.
- We don’t have a chance to measure the speaker without the enclosure. But the latter has a huge impact on the speaker response, especially in the lower registers.
- We don’t have an idea about nonlinearities, break-ups and such. We would have to measure at numerous sound pressure levels to get to know this. Even then, the problem of frequency-dependent nonlinear behaviour still persists.
So, we are measuring the whole system and already include an unknown and most probably unlimited amount of degrees of freedom. I don’t think it’s any good to start further attempts for modelling from here on. There’s already too much processing involved.
What else can we do?
The inital idea was to treat the speaker as discrete compononents as well: a coil and a membrane.
Simulating the membrane using a technique called waveguide mesh is something found quite often these days, although more in the field of sound systhesis (such as Drums), but – as research on reverb effects already told us – this is far too expensive, CPU-wise, for our task. We have to keep in mind, we want VANDAL to be run on ordinary musicians’ computers, not on a render farm of distributed systems… 😉
So we tried a very simple thing first: using an ‘interactive filter bank’. Although it doesn’t appear as ambitious as the waveguide thing, it should turn out as at least a good compromise in terms of CPU consumption and sonic results.
Our virtual speaker consists of a complex filter network, with nonlinearities and feedback paths involved. So this models all internal components at once; the coil, the membrane and the chassis. So we basically treat the filters as a function of the voice coil travelling back & forth (originally a mass-spring system), where the nonlinearities are dependent on the coil parameters as well as the membrane. Truely, any attempt in modelling this complex behaviour as a multiple-filter system is a great over-simplification. Plus, a lot of parameters have to be tuned mainly by ear.
Anyway, let’s try it.
So, when a signal is fed onto our virtual speaker, it gets filtered in some way as a function of the pre-stored eq/filter network parameters. Stored where, how?
In order to get an initial frequency response curve, we’re using official specs & plots from known guitar & bass speaker manufacturers and studied them. Apparently, different diameters, materials etc. have an impact on the overall behaviour. There are also similarities between speakers sharing similar parameters, even if they are from different manufacturers.
There’s an important thing to notice here: usually, these specs and plots were obtained by mounting the speaker on an open baffle. This means that the membrane can travel quite freely because no enclosure is affecting it from the back, taking energy from the mass/spring system or causing resonance effects.
If you were to put such a speaker in an enclosure, it would certainly change its sound somehow. We’re aware that our model has certain deficits here. Perhaps this evens things out a bit when we’ve managed to model the enclosure…
So we basically feed our filter bank with a dedicated response curve. Other parameters also need to be addressed, like for instance (frequency-dependent) distortion or the impedance curve, which – just like the filter network – is a feedback system. This means it lets the signal travel back onto itself and partly back into the previous stage. Both feedback paths have non-linearities involved and depend on various external parameters. As an example, the signal feeds back into the modelled output transformer of the power amplifier.
When sound leaves our virtual speaker, it does the same as its ‘real’ counterpart: it travels forwards to the listener and also backwards, right into the enclosure (with inverse polarity). The back-side signal already differs a lot from the front signal in terms of frequency spectrum and phase information, but our main point of interest is what happens now, as the sound waves travel through the enclosure: we get reflection patterns, echos, resonance buildups, peaks & dips in the spectrum etc.
Inside the cabinet, the audio gets messed up completely. Should this be the beauty of tone? 🙂
In order to simulate that system, we chose to apply something called a feedback delay network. Easy put, it’s an algorithm to produce artificial reverberation, by feeding a number of dicrete echoes onto one another. The echo pattern gets more complex over time. Yes, there’s indeed reverb in the enclosure. The main difference between the Taj Mahal and a 4×12″ is size 😀
So what we basically do is to take the physical dimensions of a real enclosure and let our model calculate with that. The actual dimensions have a direct impact on the reflection pattern and the resonances.
From reverbs, we know a couple of important parameters, such as decay time and cutoff frequency. Both are a function of room/cabinet damping. Whether you fill up your cab with damping wool or not, or how much, an enclosure truly would sound pretty different. Our enclosure model should take that into account and even let the user adjust that.
The virtual microphones
We want the user to choose from different microphones that ‘pick up’ the virtual cabinet’s sound. Just like in the real world, our mics should be freely positionable. This means users should be able to do close micing as well as having a seperate room mic, perhaps panning the two opposite-sides. Therefore, having 2 microphones appears mandatory for us.
For the mics, we planned to apply a similar filter bank design as with the speaker model above. We’ve also got to take internal distortion into account here, as well as the proximity effect which is prominent with some mic designs.
So, our virtual mics should behave as close as possible to their real counterparts when you put them close to the cabinet front, as well as becoming thinner, but also cleaner, when you move them away.
Of course, the room ambience should become more audible as soon as you increase the distance from the cabinet. For this effect, we put the mics into a reverb model, a one that allows for free positioning in the diffuse field. This is currently achieved by a feedback delay network similar to the one in the cabinet, although this one uses multiple output taps. On these, we apply some sort of weighting function (a gaussian bell curve) to the taps. Don’t know if this stays that way, but for the moment, it works surprisingly realistic. Sounds at least better than this cheap allpass-based impulse smearing many people still seem to be doing…
Right now, only 2 microphone models are implemented yet (classic dynamic and large-diaphragm condensor). Perhaps 1 or 2 mics will follow, but I don’t think many more are needed. I’m sure the flexibility of the whole cab sim is already huge.
It should be clear that using a cabinet model like ours is far from being the real deal. We get confronted with so many aspects that we can’t address all in detail. A lot has to be adjusted by ear and checked against actual measurements on real-world equipment, leaving sort of a bad taste; are we still doing modelling here?
But at least we are about to do doing something very important: We’re breathing life into our thing.