June 23, 2017 • Synth Morph • access virus

This is a speculation type of post, using some specifics gathered and trying to deduce a conclusion about the future of the Access Virus. Only time will tell what will be realized, and anyone can think of what can be or can not be expected in view of these facts. So take it as much seriously as you want, call it a gossip, rumour, whatever… so read it like this… or skip!

The origins

First we should talk a bit about the special computing chip, the heart of every Virus synthesizer, a certain version of the Motorola 56k DSP (digital signal processors). The origin of the DSP 56000 series came from Motorola's requests to the U.S. Music Industries as to which DSP architecture features they would need to produce synthesizers and other keyboards. This happened in the mid 1980s when the Japanese music industry introduced digital keyboards using ASICs (Application Specific Intergrated ICs), and started dominating this field previously exclusive to US manufacturers. Yamaha, Korg, Roland and others started to outdate Moog, ARP, Oberheim and Sequential Circuits. The result of this request was the birth of the first Motorola 56000 digital signal processor (DSP) generation in 1986. These 56k chips were used widespread also in the audio industry since the mid 90s, not just in hardware synthesizers and effect processors, but appeared as an auxiliary digital signal processor for audio functions in some high-end multimedia computers, like the NeXT, the Atari Falcon or the Silicon Graphics Indigo workstations.

The DSP bloodline is breaking

drastically changed: the car hi-fi systems are being replaced by multi-media dashboards, the significance of DVD players and Blue-Ray is constantly decreasing in the age of streaming/download and even the MPEG/Dolby audio decoding is handled by more powerful and different processor architectures. The traditional DSP's are here to stay for some Fast forward to 2017, today the main domain of the 56k use has: the car hi-fi systems are being replaced by multi-media dashboards, the significance of DVD players and Blue-Ray is constantly decreasing in the age of streaming/download and even the MPEG/Dolby audio decoding is handled by. The traditional DSP's are here to stay for some embedded systems , designed for longer life cycles, like telecommunication devices (sonars, radars, transponders, decoders, etc), different devices in avionics, naval, military, medical or automotive industry, where the life cycle of devices is naturally much longer compared to consumer electronic devices.

As you certainly know, Virus is a digital synthesizer, with a 56k DSP running software code to generate and modify all aspects of the sounds, these are the exact models:

1997 Virus A - 1 x Motorola DSP 56303

1999 Virus B - 1 x Motorola DSP 56311

2002 Virus C - 1 x Freescale DSP 56362

2005 Virus TI - 2 x Freescale DSP 56367 - 2x150 MHz

2009 Virus TI2 - 2 x Freescale DSP 56367 - 2x275 MHz

(Motorola first renamed its chip division to Freescale, later Freescale has been acquired by NXP, and NXP recently by Qualcomm, hence only the brands change.) Products of Kemper Music (the other brand of the Virus creator Christoph Kemper), the Kempler Amplifier series also use an NXP chip, the DSP 56720 running at 2x200 MHz. This newest and probably the last 56k DSP is part of the Symphony series DSPs, where the main difference to its predecessors is that they are dual core chips.

However, the days of the 56k platform are numbered: according to the official End of Life (EOL) policy of NXP they provide supplies for 15 years from the original release date, so the chip used in Virus TI2, the DSP 56321 is available until 2020, the one in Kemper Amp DSP 56720 ends in 2023 and there is no new 56k DSP in NXP roadmap anymore. As mentioned above, companies manufacturing traditional DSP chips target growing industries with the more modern technology, and audio is not in the focus anymore, also the type of processors being used have changed to low consumption ARM, FPGA and MCU chips. So the Motorola / Freescale / NXP / Qualcomm DSP as a computing platform will become much less relevant in some years and eventually will vanish.

product end of life details from NXP website

A rhetorical question: however it is possible to transfer the Virus Assembly code from single core to the latest dual core Symphony DSPs, Access would certainly not choose a soon-to-be obsolete and unsafe chip platform for their next iteration of Virus, not even in the case of increased potential performance.

code migration considerations from single core DSP to the dual core DSP in NXP documentation

Compiler is the application that translates the code written by programmer to a hardware specific machine code, whereas a high-level language, like C++ provides a higher level of abstraction when coding, resulting in a simpler development and more understandable and easier to read code, compared to a low-level language like Assembly. See examples: a flanger written in 56k architecture has not been designed to run a machine code compiled from a high-level source, like C++, this architecture was specifically made for special audio tasks, like oscillators, convolution, filters, FFT etc. programmed in low-level Assembly language - and this is what the Virus is being built upon. Unfortunately you can not use the concept of future-proof when it comes to technological advancements, but some newer processors used in hardware devices (like Analog Devices SHARC or Texas Instrument C6000 DSPs, or ARM CPUs) has been developed with a decent C++ compiler. (is the application that translates the code written by programmer to a hardware specific machine code, whereas a, likeprovides a higher level of abstraction when coding, resulting in a simpler development and more understandable and easier to read code, compared to alike: awritten in 56k Assembly and in C++ for ARM ). It means that the code describing the algorithms are being created on a universal language, as opposed to the low-level assembly code written for platform and manufacturer dependent DSP platforms. Thehas not been designed to run a machine code compiled from a high-level source, like C++, this architecture was specifically made, like oscillators, convolution, filters, FFT etc. programmed in low-level Assembly language - and this is what the Virus is being built upon.

re-write its code in a high-level programming language (C/C++). There is a C++ compiler ( Tasking ) for the 56k DSP, but it has some issues and it certainly would not be efficient enough for real-time audio compared to Assembly... but the main point is that there is likely no existing C++ code describing the Virus algorithms, as it was always developed using 56k specific Assembly. It means that in order to run the Virus algorithms in a new, long-term and similarly powerful computing platform (like ARM) would require to

This is one of the reason (but probably not the most important one, see below) that we hardly see anything new from synthesizer companies previously utilizing the 56k DSP platform. With the exception of DSP 56311 and DSP 56321 the rest of the chips of the old platform are "not recommended for new design" and there is no new 56k chip beyond Symphony DSPs. It is pointless to develop a new product using the same old chips (software updates are great, but no companies do it seriously, except Access), so the only chance for some manufacturers is to extend the availability of their DSP-based product: selling as much as they can. Anyway, real analog is the name of the game today and experimentation with new CPU architectures brought some smaller results up to now, e.g. the Waldorf Rocket and Streichfett using a Cortex-M series ARM CPU. All in all, it is pointless to build any future plan on the 56k, also the future of the SHARC and the TI DSP platforms are uncertain, so probably ARM is the only way to go due to its collective knowledge base for modern mobile chips.

No question: the latest 56k DSP architecture would still fit the best in the audio niche, its performance is still quite good even today. Even if FPGA / MCU cores adopted many of DSP architectural features (like saturation arithmetics, Harward Architecture, Multiply-Accumulate instructions), there are still components unique and tailored for 56k-based DSP algorithms (the extended dual-bus Harward architecture, zero overhead looping, dedicated addressing modes, hardware-based modulo addressing, bit reversed addressing, as well as fractional number representation).

Cab Maker and the Rig Manager librarian for the Kemper Amp and the Virus Control for the Virus TI. Access / Kemper Music are an expert in algorithms with special musicality in mind, with ongoing developments for 20 years, but all was realized in the 56k DSP platform using optimized Assembly, which is already a dead end, at least in case of any future Virus synthesizer. However there is a C++ oriented job offer on the Kemper website for years, this is presumably more connected to the development of the software parts of their products, namely theand thelibrarian for the Kemper Amp and thefor the Virus TI. Access / Kemper Music are an expert in algorithms with special musicality in mind, with ongoing developments for 20 years, but all was realized in the 56k DSP platform using optimized Assembly, which is already a dead end, at least in case of any future Virus synthesizer.

Purely transferring the Virus algorithms to a C++ is certainly possible but:

it requires to document all algorithms with all its qualitative / quantitative attributes which could then be transformed into any high level language (e.g. C++ code) and prototyping on a newer CPU developer board using the specific compiler.

with all its qualitative / quantitative attributes which could then be transformed into any high level language (e.g. C++ code) and prototyping on a newer CPU developer board using the specific compiler. However there are tools for automatic / semi-automatic code generation, like Matlab's Embedded Coder and DSP Concept's Audio Weaver, both are expensive Matlab-based code generators, this would be still more likely a huge and confidential manual task, rewriting those from the scratch in C/C++ to provide maximum portability and the ability to scale with newer generation of hardware platforms.

ARM is the new keyword when it comes to low-latency real-time audio for hardware devices (just mentioning also the latest Bare-metal programming refers to the case when no operating system (in the sense of some distribution of Linux or any other OS) is used, your application is accessing the silicon chip directly without any intermediary, like an OS that could reduce the performance significantly. is the new keyword when it comes to low-latency real-time audio for hardware devices (just mentioning also the latest FPGA and MCU chips with DSP functions). You do not need bare-metal programming on these new generation of chips, they are not designed for that, but more for use in a high-level language environment.refers to the case when no operating system (in the sense of some distribution of Linux or any other OS) is used, your application is accessing the silicon chip directly without any intermediary, like an OS that could reduce the performance significantly.

This approach influenced the generations of 56k DSP developers. People are really proud having developed hand-optimised code but the question is: is this really efficient? Or just use a stronger CPU with a good compiler and focus on the task, not on the CPU. Today portability and future-proof code is probably more important than efficiency.

Of course only the Virus makers can accomplish performance test on any new CPU architecture selected after re-creating the Virus algorithms in C++ . Other CPUs, like x64 is out of question for real-time hardware, pure standalone software versions in VST / AU / iOS also have a zero chance, due to the fact that they are a hardware company and of course the possible piracy concerns. They show sophisticated cache-architectures to be handled by operating systems that degrade predictable real-time performance. Anyway it would be possible to use a dedicated real-time operating system but this would rise the overall system cost even more.

What may the future bring? Pros and cons for a new Virus…

Pros

high profitability

20 years of classic heritage and achieved a legendary status, characteristic and unmatched sound (especially with the TI). After 20 years, any Virus model is still a good choice to add some unique flavour to your songs.

(especially with the TI). After 20 years, any Virus model is still a good choice to add some unique flavour to your songs. A premium brand that deserves innovation instead of abandoning it forever

that deserves innovation instead of abandoning it forever their real asset is in their unique know-how and experience with advanced and ear-pleasing musical algorithms

Virus still seems to be selling at measurable quantity (just look at the public sales rank at some major on-line instrument stores)

Thomann sales rank in June 2017

lack of groundbreaking innovation in the digital hardware synthesizer market, there is probably a place for a new digital synthesizer embracing the know-how emerged during the Kemper Amp developments

in the digital hardware synthesizer market, there is probably a place for a new digital synthesizer emerged during the there is an evergreen market of live musicians. Virus always looked cool and performed reliable on stage. You do not have to take a computer (laptop), soundcard, a display, midi keyboard, controller, mouse, cables, etc. All you need is the synthesizer with its own user interface and it looks way cooler anyway.

Cons

based on a powerful and audio-specific yet soon-to-be- obsolete DSP platform

very competitive market taken over by the efficient, affordable, feature-rich and easy to use, quality VST/AU based software synthesizers . Some of them aims to mimic certain sound attributes of the Virus. Some more advanced ones even surpassed Virus in terms of usability / user experience (especially in studio environment) and in average sound quality, but there is not one fully achieving its unique character.

. Some of them aims to mimic certain sound attributes of the Virus. Some more advanced ones even surpassed Virus in terms of usability / user experience (especially in studio environment) and in average sound quality, but there is not one fully achieving its unique character. after so many years, it would be worthless to release something without a real and useful innovation, just a slightly updated "me-too" Virus. It should contain at least one or two revolutionary features, or something extremely distinctive in this very competitive field, like

in this very competitive field, like using more direct interfaces (virtual reality, brain-to-computer interfaces, touchscreen integration, or just the knobs we know with a much bigger and informative display, etc.)

(virtual reality, brain-to-computer interfaces, touchscreen integration, or just the knobs we know with a much bigger and informative display, etc.)

application of high resolution control signals beyond the MIDI resolution (will it ever happen? Unfortunately there is still no visible wide-spread progression in this, except some promising upcoming technologies like MIDI-CI and MPE MIDI)

beyond the MIDI resolution (will it ever happen? Unfortunately there is still no visible wide-spread progression in this, except some promising upcoming technologies like MIDI-CI and MPE MIDI)

applying digital / analog hybrid elements in one synthesizer (I doubt it, Virus provides great results with modeling and this should stay in focus)



improved and reliable total integration (this is a basic requirement)

total integration (this is a basic requirement)

or any item of the improvement list below (only they know if there are something like those in their plans / pool of knowledge)

(only they know if there are something like those in their plans / pool of knowledge) unless they have a full documentation on Virus algorithms, it is still a gargantuan task to start re-writing from scratch in C++. But this is the only way to create a portable , reusable and maintainable code . So a high-level language implementation with a decent compiler on a modern hardware platform is the way to go even if that's a huge work.

to start re-writing from scratch in C++. But this is the only way to create a , and . So a high-level language implementation with a decent compiler on a modern hardware platform is the way to go even if that's a huge work. as the unique and high-quality Kemper Amplifier for guitarists occupies a considerably larger niche than synthesizer users, this product brings the main source of their stable income on the long-term, so no need to rush with a new Virus...

A TI3 or… something?

This is a deliberate list of feature requests below of a future Virus for consideration. Access Music always followed the path of the incremental feature development, so some of these could be additions next to the current features. However, due to the radical and potential platform change this is the chance to update internal components and leave backward compatibility behind, starting everything from a higher level.

Things to be improved in the next (?) Virus:

Most important: a huge increase of nominal polyphony (to 2-300 voices) just to get around 100 real voices and to be able to use the 16 parts real in multi-mode even when using heavy unison, effects, 3rd oscillator, etc. This has always been the most annoying bottleneck of any Virus in studio environment.

(to 2-300 voices) just to get around 100 voices and to be able to use the 16 parts real in multi-mode even when using heavy unison, effects, 3rd oscillator, etc. This has always been the most annoying bottleneck of any Virus in studio environment. new synthesis methods and updated components like:

importing samples for a new granular and current wave-table synthesis

for a new and current wave-table synthesis

improved FM synthesis with real FM operators and free routing instead of the fixed algorithms (like in FM8)

synthesis with real FM operators and free routing instead of the fixed algorithms (like in FM8)

LFOs running at audio rate



cross modulation between oscillators

between oscillators

filter FM



some new tech from Kemper Amps :

:

new delay / reverb effects





parameter morphing





the usage of their profiling technology , e.g. for synthesizers waveforms / filter characteristics, whatever it may fit for…

, e.g. for synthesizers waveforms / filter characteristics, whatever it may fit for… Virus Control may go way beyond what a hardware UI can offer :

may go way beyond what a hardware UI can offer : USB-C / USB 3.x connection - realtime audio streaming on all channels.

realtime audio streaming on all channels.

drag and drop modulation of virtually every parameter as destination: this provides a game changer user experience (especially when combined with real-time visual feedback of parameter movements) already taking place in the latest software synthesizers. Sure, this requires to increase the number of mod matrix sources and destination slots to a much higher number again…

of virtually every parameter as destination: this provides a game changer user experience (especially when combined with real-time visual feedback of parameter movements) already taking place in the latest software synthesizers. Sure, this requires to increase the number of mod matrix sources and destination slots to a much higher number again…

step arpeggiator with curved steps , not just boxed shapes

, not just boxed shapes

multi segment envelopes with adjustable slopes (no need for recursive modulation)

(no need for recursive modulation)

LFO Contour changes should be visible on-the-fly in Virus Control

in Virus Control

editable multi-segment keyfollow , the range of the keyfollow / tracking effect should be scalable and be able to restrict to a defined keyboard range only, not just the full MIDI keyboard range

, the range of the keyfollow / tracking effect should be scalable and be able to restrict to a defined keyboard range only, not just the full MIDI keyboard range

save / load multi / layer set-ups in the Virus Control (it is possible to save with DAW projects, but this is not independent from the host)

in the Virus Control (it is possible to save with DAW projects, but this is not independent from the host)

saving multi patches with embedded and independent preset copies, without limitations (not just for the first 16 multi sound)

with embedded and independent preset copies, (not just for the first 16 multi sound)

resizable GUI to adapt to high dpi resolutions

Conclusion

If the team of Access developers commit the inevitable re-write, add some radical functional improvements that give the other hardware and software makers run for their money (the Access / Kemper team has the potential to accomplish this!) and they can make the whole premium package attractive for the prospects, then it is not impossible that one day we will meet with the reincarnation of the Virus synthesizer.

Thanks for the kind help of Christian Langen for the valuable technical background information.