Q: What is this project all about?
A: The goal of this project is to emulate hardware synthesizers that use(d) the Motorola DSP56300 series of DSPs, below is a full list of the synths we are looking to emulate in the future
| Synthesizer | DSP | Quantity |
|---|---|---|
| Waldorf MW2/XT | Motorola 56303 | x1 |
| Waldorf microQ | Motorola 56303 | x1 |
| Waldorf Q | Motorola 56303 (2x synth engine, 1x fx unit) | x3 |
| Clavia Micro Modular | Motorola 56303 | x1 |
| Clavia Nord Modular | Motorola 56303 | x4 |
| Clavia Nord Lead 3 | Motorola 56362 | x6 |
| Novation SuperNova | Motorola 56303 | x8 |
| Novation Nova | 5x Motorola 56362 (synth engine), and 1x Motorola 56303 (fx unit) | x6 |
| Korg MS2000 | Motorola 56362 | x1 |
| Korg Microkorg | Motorola 56362 | x1 |
| Access Virus A | Motorola 56303 | x1 |
| Access Virus B | 1st rev “S” uses Motorola 56303, 2nd rev “T” a Motorola 56311 | x1 |
| Access Virus C | Motorola 56362 | x1 |
| Access Virus TI Snow | Freescale 56367 | x1 |
| Access Virus TI | Freescale 56367 | x2 |
| Access Virus TI2 | Freescale 56367. Later models used 56321 | x2 |
Q: Isn’t it illegal what you are doing?
A: The emulation itself is not illegal. Sharing of the hardware ROMs is illegal though. What this means is that a user will need to provide the ROM file of a synthesizer that it wants to emulate. It works similar to game console emulators, where the emulator itself cannot execute any game until you provide a ROM of it.
Q: When are you going to release the VST plugin?
A: We can’t give any ETA right now. This project is driven by team members that do this completely in their spare time. ETA depends on the amount of time that team members can/are willing to spend on this project and on a lot of research / reverse engineering that can’t be estimated upfront.
Q: What is the current state of the project?
A: We are able to load & run the Access Virus B and C ROMs as VST2 plugins on Win64, Mac & Linux. Virus B ROM is realtime capable on a Core i7 4790k, Virus C ROM is very close to realtime, needs a slightly faster CPU.
The current VST is headless / without UI. Presets can be browsed by sending MIDI Program Change / Bank Select. Editing is possible with controllers such as VirusHC.
Q: Is this emulation CPU hungry?
A: The emulation uses plenty of CPU resources indeed, but is realtime capable on mid range CPUs, high end CPUs will be able to run multiple instances even.
Q: Will this project be open source?
A: Yes, once we have reached a state that we are happy with, the whole project will be released publicly on GitHub. As the project is still in its early stages and some contributors want to stay anonymous, parts of the project are private for now.
Q: Why not the “real” Waldorf Q? What about Virus TI?
A: These synthesizers use multiple DSPs and will be more complex to emulate. Right now we focus on synthesizers that have one DSP only due to simplicity.
Furthermore, we don’t want to emulate gear that is still being sold and this is the case for the Virus TI.
Q. Can’t the 563xx emulator use multiple cores to increase emulation speed?
A: As the DSP only has one core, the emulation can use only one core to emulate one DSP. However, multiple instances will be able to run on multiple cores of the host system.
Q: How is this emulation done?
A: The emulator used to be an interpreter. The current version uses a technique called JIT/dynarec.
Q. What is a JIT and a JIT Block exactly?
A. JIT stands for Just-In-Time compilation, sometimes also called dynamic recompilation and means that DSP instructions are translated to host CPU instructions at runtime. An in-depth explanation can be found on Wikipedia.
A JIT block is basically one cached portion of DSP code that has been translated to host CPU code previously and is reused if it is executed again. A JIT block usually consists of several DSP instructions that are executed linearly.
Q. Is the DSP 563XX series (and the 563XX emulator too) natively compatible with the 56001,56002,… (the first generation of 56k)
A: The DSP 56000 series is an older generation of DSPs. Compared to the 56300 series, some registers are not as wide, for example the address generation registers are 16 bit only, compared to 24 bit on the 56300 series. The hardware stack is smaller, too. Some registers do not exist at all on the older DSP series. While the DSP 56000 series could be treated as a subset of the 56300 series, support for the 56000 series would require a large rewrite of the existing code base.
Q: Why is the emulator so CPU hungry? CPUs as of today with several GHz of processing power should be able to emulate a DSP which runs at 60MHz to 150Mhz clock speed
A: Emulation always adds a large amount of overhead due to the nature of interpreted emulation. Furthermore, the DSP 563xx has several features that are not available on standard CPUs such as 56 bit fixed point accumulator registers, modulo addressing or hardware loops.
Q: What about optimizations to make the emulation faster, such as inlining, profiling etc?
A: The emulator in its current state has been profiled & optimized for many weeks with VTune already. Optimizations are constantly being made still, but do not expect that it will magically double it’s execution speed in the near future.
Q: Why don’t you use static recompilation to reduce CPU usage and increase emulation speed? Isn’t that easier than development of a JIT/dynamic recompiler?
A: Due to legal issues, we are not allowed to recompile an existing ROM and redistribute it, as a recompilation is a derivative work of the ROM, which is copyrighted. Furthermore, parts of the DSP code are self-modifying so static recompilation does not even work at all.
Q. Will the emulator have native Apple M1 support?
A: The DSP uses dynamic recompilation of DSP to x64 code, therefore, Rosetta is required to run the emulator. Native support for ARM-based devices is planned, but not very high on the priority list. We confirmed though, that the emulator runs just fine on an M1.