Motorola DSP563xx Emulator (BETA) (Access Virus, Nord Lead, Waldorf MW...)

[xhunaudio]

Every time I come across this project, I'm blown away by its beauty and complexity...

Anyway, I don't see any conflict here.

There is (#1) a DSP563XX emulator with overhead, which meticously replicate every HW routine of the DSP. Companies are not interested in this because they (legitimately) know that the average user (also in this case, legitimately) doesn't understand and doesn't really care about the inner technology involved in a synth, but just want to play a synth and access to 100 instances of it in real-time.

And there is (#2) a derivative of the emulator above, giving priority to specific DSP563XX HW routines (depending on the emulated device) with the corresponding modification of the original firmware (while maintaining a bit-perfect output). It would be a rights violation for the DSP563XX Team to release this on their own, but the "official companies" may be intersted in this, as official synths reissues or as an endorsement to a new (3rd party) company releasing them - they'll decide the best.

I think both projects (#1) and (#2) could peacefully cohexist, since the approach (#1) - while extremely valuable - has no commercial meaning for the "official companies" (because of the overhead). An official micro Q (#2) could cohexist beside an overheaded "vanilla" DSP563XX emulator (#1) running the original micro Q firmware and a Q GUI frontend. I don't think they overlap, commercially speaking.

So, it's not a "stop" for the DSP563XX project, in any case - and I would take it as a good news. Again, my best wishes to the DSP563XX Dev Team.

[xhunaudio]

A bit off-topic,

but alongside the vastly more complex DSP563XX project, it would be great if someone would also resurrect the (similar) AMAME project :

https://github.com/jariseon/amame

[v1o]

Sony licensed the PCSX-Reloaded open source emulator for their Playstation Classic re-release. And its been rumoured that UAD is using software emulation of the Sharc DSP chip for their natives plugins.

It's not entirely unfeasible that a company like Kemper may in future use a fork of DSP563XX to release their own commercial software instruments. The deal breaker at the moment is the low efficiency and performance of the emulator.

[cnt]

Journalists have a knack for getting even basic facts wrong.
It's just what happens when people with a degree in creative writing pretend to be experts on all things.

Correction: Some people that calls themselfs journalists.
Now, anyone can call themselfs journalists, but not everyone has gone to the university and actually studied the topics. Journalism isn't about creative writing.

[sl1200mk2]

I would think that Access would be more positive towards it given that they already had a Virus port on the TC Powercore platform, so it's not unheard of for them to do something of that nature. Waldorf is a harder sell I think given that they already have their own inhouse soft synths.

My .2c is to approach Access since you can't burn that bridge having already released the emulator, but based on that outcome, I'd proceed on releasing something else like the Nord or Supernova, but like you did with the Virus. Getting it working, well-polished and out there. With two proven releases and a larger userbase it might make it easier for Waldorf to get on board if they're still on the fence. To me, that seems to make more sense rather than spending an inordinate amount of time on one manufacturer who may never approve or condone the project in any way.

I've donated and would encourage everyone else who's using the emulator to do so as well even if it's a small amount. I know the dev's have stated that they aren't in it for the money, but it helps. More so than the actual dollar amount, it shows them the community appreciates their work and hopefully keeps them motivated. Even as is, the emulator is brilliant IMO and I'm hugely grateful and appreciative for it.

[psycho45039]

I just discovered this and all I can say is thank you. My thirst for a virus is quenched. At lest for the time being. Keep up the great work. It runs flawlessly on an ancient Mac Pro 6,1 up until around 7 notes of polyphony then it starts to stutter but that in itself os mighty impressive. I'll have to give it a try on my 5,1 and see how it fairs.

[v1o]

https://www.youtube.com/watch?v=AqCLDkjdBH0

Way ahead of its time.

[PAK]

I would think that Access would be more positive towards it given that they already had a Virus port on the TC Powercore platform, so it's not unheard of for them to do something of that nature. Waldorf is a harder sell I think given that they already have their own inhouse soft synths.

Not quite a "port", as such, since the Powercore runs native Motorola DSP code, as did Protools TDM. They only provided a front end interface for their existing synth code. BTW Access worked with TC and DigiDesign to serve their own hardware integration goals, since they froze those plugins at Virus B functionality and went on to use the experience gained to create the Virus Control plugin for the Virus TI..

For an emulator project the issue is, and will remain, the amount of CPU usage required once you add emulation of the Motorola DSP. As Waldorf have just demonstrated, with Streichfett, they also retain the capability to port their hardware code to native plugin formats.

If they thought the sales numbers were there then, unless the performance could be brought a lot closer to native code, they would probably rather create their own true ports which would use a lot less CPU. They're in the market, so it's wise to presume they have a decent grasp of these matters and the likely sales numbers etc. Even sanctioned ROM sales aren't that straight-forward since it could involve things like lawyer expenses etc..

[v1o]

For an emulator project the issue is, and will remain, the amount of CPU usage required once you add emulation of the Motorola DSP. As Waldorf have just demonstrated, with Streichfett, they also retain the capability to port their hardware code to native plugin formats.

The Waldorf situation is not like the Virus one. I think they had it much easier porting over the Streichfett. We can assume that was coded in a high programming level language and used modern dev tools. The Virus was written in low level assembler code, so moving that to C and producing identical output to the hardware will be difficult. The Korg Prophecy VST for example doesn't sound identical to the hardware.

[rafa1981]

The Waldorf situation is not like the Virus one. I think they had it much easier porting over the Streichfett. We can assume that was coded in a high programming level language and used modern dev tools...

Indeed, and most probably we can also assume Linux on an ARM chip instead of bare metal...

[chk071]

I watched an interview with Wolfram Franke from Waldorf once where he said that porting over the algorithms 1:1 isn't that much of an issue, apart from the obvious differences, like, using C++ instead of C which they used on the hardware (in that case Blofeld vs. Largo), GUI programming, different plugin formats etc. Porting the DSP shouldn't be a problem.

What's much more important is the target market, I guess. I would guess that, first of all, hardware and plugins is a different market for the most part, with hardware people not buying too many plugins, and vice versa. And then, you have to consider the impact of selling the same synth in software on the hardware sales. Or, even making people go in-the-box, because they realize the comfort of doing so.

Anyway, I can totally understand Waldorf's stance regarding the CPU usage. It's a major issue when you compete with "native" plugins.

[PAK]

The Virus was written in low level assembler code, so moving that to C and producing identical output to the hardware will be difficult. The Korg Prophecy VST for example doesn't sound identical to the hardware.

Access might've hand-written certain bits of DSP, but all of it?! Hmm Unlikely. (Motorola had a C compiler for the 56k). Well documented code would help any port though. Otherwise an experienced coder would know how to translate things, like the fixed point 24 bit DSP, in order to maintain the sound.

In the case of the Prophecy, Jerry Kovarsky (Head of Korg USA at the time) commented that new products, based on the Prophecy/Z1 code, would be "difficult" because the original developer passed away and apparently the source code was not so documented. So it was a surprise to those, aware of that, that they managed a Legacy Collection version at all (nearly 20 years after those comments though! )

As said, the issue is and remains the amount of CPU required to emulate the DSP itself. The Access Virus is one of the better cases here, in terms of DSP resources. EG The Nord Lead 3 used SIX of the Virus C's DSP. Nice to have? Sure. But how many people would be prepared to hand over most of their 13900k etc to the task?

[v1o]

Virus TI emulation

https://www.youtube.com/watch?v=EtESA3Qp39E

[gentleclockdivider]

I'd rather see them doing the waldorf xt or nord modular g1 .
I have the Nord mod. G1 hardware but an additional 1:1 emulation would be awesome

[EvilDragon]

In the case of the Prophecy, Jerry Kovarsky (Head of Korg USA at the time) commented that new products, based on the Prophecy/Z1 code, would be "difficult" because the original developer passed away

In fact it ended up not being true. Z1/Prophecy DSP developer is still alive and well (and I think actually still even works for Korg). ISTR Dan Phillips mentioned this in one post at GS, can't find it now...

Otherwise an experienced coder would know how to translate things, like the fixed point 24 bit DSP, in order to maintain the sound.

Now THIS is not at all as easy as it sounds, and it's the reason why the emulator is so CPU intensive. it's not that much about 24- vs 64-bit difference, but it's about the instruction set that the DSP has that your x86 or ARM CPU doesn't have, so you need to port over those instructions, often at a pretty significant performance hit.