Choosing the right audio engine is one of the most important decisions for anyone who builds synthesizers. In many ways, the audio engine determines the quality and character of the sound, but it also affects development and design. CPU efficiency, licensing, and overall flexibility also come into play. But just what are the criteria we have used in deciding?
Stability. It is absolutely essential that our synthesizers are rock-solid. This is achieved by hardware design as much as it is by the software which runs inside the instrument.
Sound. Excellent sound quality is an obvious requirement, but the quality (and variety) of synthesis algorithms which can be implemented with the engine is also very important.
Flexibility. We want to be able to build engines based on a variety of different synthesis methods, including modal and additive synthesis, physical modeling, FM, and hybrid methods.
Connectivity. The engine needs to provide an interface with a sufficient bandwidth and timing precision to receive and process our TCD control messages.
Prototyping. It is very important for us to be able to quickly and easily build proof-of-concept models and full prototypes in order to explore our synthesis concepts. Also, an engine capable of "evolutionary development" - which allows us to continuously develop and modify a particular synthesizer - is crucial.
For the signal processing hardware we have considered two approaches:
Dedicated DSP hardware. DSPs can be very powerful and efficient for audio signal processing. But using a DSP board means programming with specialized development tools on a relatively low level. This is not the most flexible and fastest way to prototype a synth engine.
General-purpose computer boards. It is obvious to any observer of current technological trends that general-purpose computer boards have continued to significantly improve in terms of power, efficiency, and affordability over the past few years. Within this category, two major possibilities have emerged: embedded PCs and ARM-based systems (such as the Raspberry Pi).
In terms of CPU power, the Intel i3/i5 processors are still the leaders. A high-powered CPU is necessary for more advanced synthesis engine designs and so we have chosen to go this route.
Next comes the choice of an operating system. Besides the inherent qualities of an operating system, we also need to take into account whether or not our preferred software application would run on it. Of the three most widespread operating systems - and therefore with the largest development communities - only two would be possible for us. Mac OS X is obviously out of the question because the system is not sold without the Apple hardware. Embedding a Mac Mini into one of our synthesizers would make our products more costly than necessary.
Another choice would be to use a Linux-based system. In general, we prefer open source solutions over proprietary ones, unless there is a compelling reason to use the proprietary systems. This is not only for cost reasons, but also to avoid being "locked in" to a system and a company. The third OS possibility would be the Embedded version of Windows 7 or 8.
Audio Engine Application
The code which implements the audio algorithms is the heart of everything. Here we have the following choices:
C/C++. This would mean building the synth "from scratch". Building in C has the advantage of (potentially) very efficient code, but the time spent developing and testing can be very long. Even putting together playable prototypes can take quite a while. It remains an option, but for the first version of our synth we prefer a faster way of development, testing and debugging.
Visual programming environments. Pure Data (Pd) could be a good choice in this category. It is open source, very flexible and runs on Mac OS X, Windows, and Linux systems. But we believe that Reaktor is even better-suited for us. First of all, it is something that we at Nonlinear Labs are very familiar with. After all, I started Native Instruments more than 16 years ago with a single product: Reaktor (it was then called Generator).
But my familiarity with the environment is not the only factor. Reaktor has a community of active developers, is a mature application which continues to be developed, and can process OSC, MIDI, and automation data. Ever since Reaktor 5, efficient low-level audio DSP structures can be quickly built, tested, and implemented, making Reaktor very flexible. In fact, you can build just about any kind of synthesizer engine with Reaktor.
We will use Reaktor as a signal processing engine but will not apply its graphic user interface or the preset management system ("Snapshots"). All control functions will be driven by the TCD engine in the second "brain" of our synthesizers: an ARM-based processor. Leaving aside both graphics and presets means that all CPU resources required by Reaktor will be used to make sound. Theoretically, this means that our Reaktor-based engines will have more audio-power and perform more stable than when the software is using its user interface features.
Over the longer term, we will continue to look into cost-optimized solutions (ARM systems, Linux, C-coded audio engines, etc.). As the performance of ARM processors increases, this solution will become more attractive to us.
Besides the costs, the size and power consumption (or need of cooling) of the audio engine is an important factor. ARM systems can be very small and efficient, but Intel is catching up fast.
Our current prototyping is based on the decision to use an Embedded PC platform optimized for running Reaktor as the synthesis engine.
Reaktor's instrument developers constitute a vibrant community of musically-minded individuals who have created some very impressive synthesizers (with Reaktor) over the years. We have already began to work with some of them for developing specialized synth engines for Nonlinear Labs.
Although there are disadvantages (proprietary systems: both the Embedded Windows and Reaktor will mean that we have to pay licensing fees), we believe that for the near future, the advantages outweigh them. Nevertheless we will remain open for other possibilities.