In our post about the first prototypes we mentioned a "two brain" concept of synthesizer design. But as we make progress towards our first instrument, we have decided instead on a "three brain" design. Each main area of our synth will have its own CPU:
- the generator of the TCD control signals
- the audio engine
- the user interface for sound editing and preset management
At first sight, three processors for one synthesizer might seem to be somewhat over-engineered, but after reading through the requirements we enumerate below, you might agree that this approach makes sense.
About ARM Processors
Before we begin, it might be a good idea to provide a brief overview of the "ARM Cortex" processor family. The company name ARM could also be read as an acronym for Application, Real-time and Microcontroller - describing three sorts of processors. ‘Cortex’ is the label of the newest ARM processor architecture. The following are typical processors of the three groups:
- A5, A8, A9, A15 - for small computers with an OS, e.g. smartphones
- R4 - typically used in the automotive sector
- M0, M3, M4 - controlling devices like home appliances or consumer electronics
All current models are 32-bit processors. They cover a wide range of CPU performance. The clock frequencies go from 50 MHz to 2 GHz and the number of CPUs vary from single core to quad core. And what is also important: many of them are available at amazingly low prices.
ARM Cortex M3 - for the TCD Generator
Nonlinear Labs' claim is "expressive instruments for performing musicians"; expressiveness is one of the central qualities that we aim for in our instruments. But what does "expressiveness" mean from a technical point of view?
There are essentially two requirements regarding expressiveness: the range and resolution of control parameters and their time quantization. For a better understanding let us to take a closer look on how a digital keyboard instrument works.
In the digital world a key has to be checked regularly for its state. Let’s imagine we have a very slow processor that can scan the keys only once per second. In such a case, when you hit a key it would take up to a second until you hear the sound coming out of the speakers. If we scan the keyboard every 500 ms (milliseconds) we cut the maximum latency in half by doubling the sample rate — which is another word for time resolution.
For a good response, the latency should not exceed 10 ms. Therefore, the sampling rate must be higher than 100 Hz. But for dynamic playing on a keyboard, the scanning mechanism is also used to detect the velocity of keys, which reflects how fast they are pressed or released.
This is accomplished by measuring the time between two positions of the key on its way down or up. When hitting the key hard, this time can get as short as 2 ms. For a sufficient resolution of such times we decided to scan the key contacts every 125 us (microseconds) — in other words, 8000 times per second.
Such a high resolution is a real technical challenge. It means that after scanning the keyboard we have about 100 us remaining to carry out the TCD calculations — which is quite a short time for this job. This also means that we have no time left for the user interface and the preset handling without disrupting the keyboard scanning and the TCD generation. This would cause serious glitches in the sound.
In order to guarantee a high degree of expressiveness and sound quality, we decided for a dedicated processor for the "play interface", which includes the scanning of the keyboard and other sensors like pedals, wheels, ribbons, and the generation of the TCD signals.
The ARM Cortex M3 and M4 are well-suited for this purpose. We have developed an efficient real-time framework for this platform and are now implementing all the tasks that are translating the musician's playing into TCD. The microcontroller's USB 2.0 interface is used as a high-speed connection to the audio engine on the embedded PC.
Intel i3 - for the Audio Engine
Like in our "two brains" approach, the second processor is dedicated to the TCD rendering and the audio engine. Different approaches for creating an audio engine have been discussed here: Choosing an Audio Engine.
As you might already know (and can read in the article), we decided to use Reaktor both as our development platform and as the audio engine for our synth. Reaktor is purely dedicated to audio processing - we are not using the functions of its user interface and therefore the software stays “invisible”.
As a platform for Reaktor, we will integrate a very compact PC mainboard into our instrument. It is equipped with an Intel i3 processor running Windows Embedded 8. The processor is optimized for notebook computers and delivers high performance with low power consumption. For the cooling we don't need a fan and since the harddisk is a SSD there will be no mechanically sensistive or noise emitting components.
ARM Cortex A8 - for the User Interface
The user interface of our instrument is based on our own hardware design. The dedicated processor’s job is to read in buttons and knobs and to control LEDs and displays. It also will handle mass storage devices like USB sticks and provide a wireless communication to mobile devices for extended functionality.
The user will be able to save and load, tag, and search through presets. In addition, all user interactions can be recorded, so that the user can go back through the last few hours of playing the keyboard and manipulating parameters, for example. In the end, this is quite a bit of data manipulation and management.
For these tasks a Linux system is the most appropriate. With Linux, we get a comfortable high-level programming environment that is supported by a large selection of drivers and software libraries covering most of the functionality we need. Further benefits are:
- free and open OS
- huge community and support
- runs on a wide range of hardware platforms and processors
- very scalable (allows a very small footprint)
In the future, our sound engine might also run on a Linux system — we are now gaining experience for such a possibility.
Within the ARM Cortex family, the application processors (A-series) fits best to run a Linux system. For our prototype, we use the BeagleBone, a small computer module that is equipped with an ARM Cortex A8 processor. It is — similar to the popular Raspberry Pi — a powerful device at a surprisingly low price.
A New Prototype PCB
When we redefined the requirements for the computer systems of our instrument we also designed a new prototype PCB (printed circuit board). It integrates our custom-designed carrier board for the ARM Cortex M3 and the BeagleBone together with power supply circuits, adapters, and connectors for all the necessary links to other parts of the instrument.
Three Brains - Collaborating
Our experience with the first designs and prototypes has shown that with the currently available processor technology the requirements of our instrument are fullfilled best by three separate CPUs. Of course, it requires well-designed interfaces between the three systems.
This approach also has given us additional flexibility in:
- choosing the right development tools, programming languages and libraries
- assigning development tasks to external collaborators
Because the prices of ARM processors have fallen to very low levels, the new components do not significantly affect hardware costs. "Three brians" might have seemed a bit over-engineered at first, but - as you can see - it is the best way for us to attain a high degree of expressiveness and sound quality, as well as to provide an advanced user experience.
By the way: Maybe you would like to give us some feedback on this article (or earlier articles). We would like to know how understandable and interesting you find it, or what else you would like to read about. Please send your comments to email@example.com.