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

[muki]

i think we are spoiled by all those 68k emulations
where you can run your favourite c64 game at thousand-times-speed

making us believe (and wishing) we can run hundreds of virus' in one core...

[codeblackmedia]

Yes I understand that this is something new.
All what I try to say is that the cpu spikes are not a problem of my computer.
It's because nobody has look at this , 4 ghz don't show you the truth.
The emulator work fine and use 10 % sometimes 15 % when you playing 10 voices.
Why it goes crazy for the next 10 voices 90% ?
No matter if you use the Rom of Virus B-C it is the same cpu spikes.

You absolutely don't get it at all.
Your computer has many cores, maybe its 8 cores, maybe 16.
As soon as one of these cores is totally used up, your whole system will be dead and you wont be able to have any music in any daw function without buffer overrides.
Thankfully this is normally not the case as your daw will move plugins around on different cores to spread the load.
Also there are many plugins that can also use multicore.

This emu does not use multicore, it sits on 1 core, as the original design of the virus c & b sat on 1 dsp core with no multicore ability.

If you have too slow of a computer and this emulation makes 1 of your core's hit 100% saturation point, then you can expect your system to be struggling and dying because of this patch or the amount of voices you are playing.

Once again, i have 0 issues with this emulation because i have more than enough cpu power to run the heaviest virus c patch without saturating 1 core of my cpu setup, so then i can repeat this with many more EMU's.

Once again, you need a faster computer.

Please keep in mind that extra voices from the release tails of the last notes will stack up on top of each other and create more cpu power needed as these voices are stacking, if you dont have enough power, say bye.

[chk071]

The DAW CPU meter is kind of weird for this plugin though... It either shows very little usage, like, 8 to 15%, of it shows 100%, and it crackles. A typical VSTi plugin would show 30 to 50 to 70 %, and then sometimes begin to crackle with too many voices. The emulator can even crackle with a single voice, and allegedly very little workload before it freaks out, and gets to 100%, at least according to the CPU meter in Studio One. I don't know, seems to behave differently than your "average Joe" VST plugin.

[OrionAlpha101]

The cpu meter lies that's nobody say before.
I have found away to put the release on some patches a bit down and on some arp patches you need to bring the poly mod to mono so you can play the emulator without problem.The only sounds you can't play are Pads but the Virus has not so many good pads.What I have to say is that if you save a patch in Logic and you recall it there are problems and the first patch of the bank comes back sometimes.Also the parameter are not there.

[numerouno]

The DAW CPU meter is kind of weird for this plugin though... It either shows very little usage, like, 8 to 15%, of it shows 100%, and it crackles. A typical VSTi plugin would show 30 to 50 to 70 %, and then sometimes begin to crackle with too many voices. The emulator can even crackle with a single voice, and allegedly very little workload before it freaks out, and gets to 100%, at least according to the CPU meter in Studio One. I don't know, seems to behave differently than your "average Joe" VST plugin.

Yes this is correct and addressed on page 29 of this thread (see below)
Eventually we will add a meter to the GUI to display the true numbers

Everyone who claims their CPU usage is very low, should look in the operating systems task manager for the real CPU usage. The DAW CPU/Buffer readouts are wrong in this case. When 1 of the CPU cores hits maximum, audio interruptions occur and it happens very often here. This emulator is very CPU heavy. High polyphonic patches with a long release are pretty much unusable without bouncing to audio on my system (i7-4771) and that, with just one instance in single mode, with the Virus C.

You are 100% correct, the spikes are there because the DSP is running in a high priority backgroud thread. If the DSP is fast enough, the DAW will report a very low CPU consumption, even though this is not really true. If the DSP is too slow, it will report 100% instantly

[muki]

wishlist: a panic button

[muki]

wishlist 2:

FX?

are there plans to also have dsp563xx as a fx plugin ?

like:
afaik the virus has EXT in and can be used as fx box

and afaik there has been other effect boxes with the 56k ?

[numerouno]

afaik the virus has EXT in and can be used as fx box

This can already be utilised as shown in our blog posts

https://dsp56300.wordpress.com/blog/

[muki]

afaik the virus has EXT in and can be used as fx box

This can already be utilised as shown in our blog posts

https://dsp56300.wordpress.com/blog/

oh yes! cool! thanks!
and is even quite easy on the cpu

[Introspective]

Stupid question, sorry. Is this emulating a Motorola 56303 specifically? Or the whole 56K family?

[numerouno]

Stupid question, sorry. Is this emulating a Motorola 56303 specifically? Or the whole 56K family?

The 56300 family instruction set is emulated, so the 56362, 56367, 56321, 56303 etc etc

[rafa1981]

With regards to the CPU spikes.

This emulator is (JIT) compiling the code from the ROM as playing. This is a non-deterministic processnot suitable for soft-realtime (audio) . When the JIT compiling hits it may causes CPU spikes. When it runs the compiled code it is mostly stable. They did it like that because it wasn't possible to run at a reasonable CPU cost otherwise.

AsmJIT can emit C code if I remember correctly. I asked and it seems that they can't do a total static pre-compilation on the ROM while loading because the Virus code is self-modifying. If it weren't self modifying bundling a competent multiplatform C compiler (e.g. Zig) could make this fly CPU-wise I guess. I don't know if all DSP56300 rely on self modified code.

[audiojunkie]

The Virus emulation don't need much cpu that is logical.
And the Emulator also don't need that much power.
So work it out right or leave it.

It's not a Virus emulation.

This plugin doesn't produce any sound as such, it makes your computer implement the code which was originally written for an entirely different kind of devices. So you can't really compare it to "emulation" synth plugins like Repro, Obsession etc in terms of the efficiency, it does something entirely different.

An actual Virus emulation plugin does exist and it doesn't take that much CPU.

Agreed. It is closer to imagine trying to run an OS designed for X86-64 on an ARM architecture. Sure, you can emulate it, but you are going to need a lot of power to do so.

[vata44]

Any ETA on a GUI? I’m obsessed

[Buckster]

Would this "emulation" work in Unify ?

Just if was set to monophonic but let Unify create polyphonic using midibox and say 4 or 8 instances I thought I heard that Unify assigns each instance of a VST tona different core ? Just a thought