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

DSP, Plug-in and Host development discussion.
KVRian
685 posts since 14 May, 2014

Post Mon May 10, 2021 1:56 pm

xhunaudio wrote:
Mon May 10, 2021 10:41 am
Yes, I was just figuring (in the long term, with many people involved) something similar to MAME, a sort of "Multiple DSP Emulator"...

But this 563XX already is an amazing project, also without any further processor/coprocessor addition.
From my understanding, some of the MAME ppl are actually helping with this DSP563xx project as we speak haha

User avatar
KVRian
795 posts since 17 Feb, 2010

Post Tue May 11, 2021 9:54 am

Are you sure ? It's a great news and it makes much sense...
bruno @ Xhun Audio || www.xhun-audio.com || Twitter || Facebook || Instagram
Image

KVRer

Topic Starter

27 posts since 17 Jan, 2021

Post Tue May 11, 2021 2:59 pm

Shiek927 wrote:
Mon May 10, 2021 1:56 pm
xhunaudio wrote:
Mon May 10, 2021 10:41 am
Yes, I was just figuring (in the long term, with many people involved) something similar to MAME, a sort of "Multiple DSP Emulator"...

But this 563XX already is an amazing project, also without any further processor/coprocessor addition.
From my understanding, some of the MAME ppl are actually helping with this DSP563xx project as we speak haha
This is incorrect, we dont have anybody from the MAME team working with us

KVRian
685 posts since 14 May, 2014

Post Tue May 11, 2021 5:32 pm

numerouno wrote:
Tue May 11, 2021 2:59 pm
Shiek927 wrote:
Mon May 10, 2021 1:56 pm
xhunaudio wrote:
Mon May 10, 2021 10:41 am
Yes, I was just figuring (in the long term, with many people involved) something similar to MAME, a sort of "Multiple DSP Emulator"...

But this 563XX already is an amazing project, also without any further processor/coprocessor addition.
From my understanding, some of the MAME ppl are actually helping with this DSP563xx project as we speak haha
This is incorrect, we dont have anybody from the MAME team working with us
Ahh! my apologies and thank you for clarifying. I must have misremembered something.

KVRer

Topic Starter

27 posts since 17 Jan, 2021

Post Fri May 21, 2021 10:09 am

Update: We now have a beautiful looking GUI courtesy of “Hoverland”

Image

Image

Image

Image

Image
Last edited by numerouno on Fri May 21, 2021 11:06 am, edited 1 time in total.

KVRist
409 posts since 4 Jan, 2007

Post Fri May 21, 2021 10:40 am

Wow. A very clean one

KVRist
382 posts since 1 Jul, 2009

Post Fri May 21, 2021 11:26 am

WOW, if this works smoothly, without killing the CPU, this will be BIG. End of the virus clones. This here, is the real deal.

AnX
KVRAF
9387 posts since 17 Nov, 2015

Post Fri May 21, 2021 11:31 am

numerouno wrote:
Fri May 21, 2021 10:09 am
Update: We now have a beautiful looking GUI courtesy of “Hoverland”
good work

KVRian
863 posts since 27 Oct, 2004 from Inside the kick drum

Post Fri May 21, 2021 12:01 pm

Wow, this is superb! I keep following. Congrats and good luck with this project :)

User avatar
KVRAF
21589 posts since 7 Jan, 2009 from Croatia

Post Fri May 21, 2021 1:17 pm

anoise wrote:
Fri May 21, 2021 11:26 am
WOW, if this works smoothly, without killing the CPU, this will be BIG. End of the virus clones. This here, is the real deal.
It's not going to be super cheap on the CPU, since it's converting 24-bit DSP instructions to a 64-bit CPU. There are overheads for each and every instruction that needs to be executed.

The team is working hard on making it as fast as possible, but don't expect miracles.

KVRian
685 posts since 14 May, 2014

Post Fri May 21, 2021 4:10 pm

This is complete speculation, but given that there is no analog filtering, component-level modeling, etc, and all the things that make the best-sounding plugins so CPU-intensive, I don't think it will be the heaviest things around. Not super CPU-friendly because it's not as if they are explicitly made for that, but certainly not beefy tanks either.

As ever, I'm infinitely grateful this project even exists and many of my favorite synths that have always sonically inspired me have a chance at becoming plugins. Upgrading the CPU/ram of your home computers is a small price to a pay to have them, but that's just me :)

KVRist
409 posts since 4 Jan, 2007

Post Sat May 22, 2021 6:50 am

I haven't look at your interpreter in depth, but this article about writing a tail-call based interpreter (instead of switch based) seems interesting:

https://blog.reverberate.org/2021/04/21 ... eters.html

As the musttail attribute is Clang's, the code can still compile for for Windows (clang-cl), Linux and OSX.

User avatar
KVRAF
21589 posts since 7 Jan, 2009 from Croatia

Post Sun May 23, 2021 1:23 pm

Shiek927 wrote:
Fri May 21, 2021 4:10 pm
This is complete speculation, but given that there is no analog filtering, component-level modeling, etc, and all the things that make the best-sounding plugins so CPU-intensive, I don't think it will be the heaviest things around. Not super CPU-friendly because it's not as if they are explicitly made for that, but certainly not beefy tanks either.
I would expect around Diva levels of CPU usage (without the option to multicore because that's not how the DSP chip operates). Doesn't matter that there's no component-level modeling - the biggest issue is we're dealing with 24-bit to 64-bit conversion.

Also, note that these devices mostly worked at 44.1k. Forget about upsampling them for "better sound". Actually, there will have to be some resampling done on the fly to support running the plugin at other sample rates - and this will also incur a small latency and a bit more CPU overhead (if you want a good/great quality resampler).

KVRAF
6368 posts since 12 Feb, 2006 from Helsinki, Finland

Post Sun May 23, 2021 11:08 pm

EvilDragon wrote:
Sun May 23, 2021 1:23 pm
Shiek927 wrote:
Fri May 21, 2021 4:10 pm
This is complete speculation, but given that there is no analog filtering, component-level modeling, etc, and all the things that make the best-sounding plugins so CPU-intensive, I don't think it will be the heaviest things around. Not super CPU-friendly because it's not as if they are explicitly made for that, but certainly not beefy tanks either.
I would expect around Diva levels of CPU usage (without the option to multicore because that's not how the DSP chip operates). Doesn't matter that there's no component-level modeling - the biggest issue is we're dealing with 24-bit to 64-bit conversion.
I'm curious (and I have no idea how this particular DSP works, please educate), what's the source of the overhead here? It would seem that for most arithmetic operations one could just use wider registers with just right-shifts and divisions requiring pre-masking/sign-extension?

Does the DSP store 24-bit values as 3-bytes in memory? Is that what's causing the slowdowns?

edit: I took a look at the source code, it looks like it's translating each op separately? I can certainly see why one would do that (simplicity), but that kind of translation is likely to result in quite a bit of overhead with things like updating flags even where they might be overwritten by the next instruction. The alternative (ie. reconstruct suitable compiler IR, optimize said IR, then generate code from that) is a lot more complicated though, so I don't know. Even if one doesn't go for a full compiler, it might make sense to construct at least a basic dependency graph on the level of basic blocks or something in order to peephole some of the overhead? :shrug:
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

User avatar
KVRAF
21589 posts since 7 Jan, 2009 from Croatia

Post Mon May 24, 2021 1:09 am

I don't know the details, but yeah the latest emulator version could achieve 120 MIPS (and Virus C is overclocked to 130 MHz, so 130 MIPS) by using up a whole core of an i7-4790K, and even that wasn't 100% realtime. That's quite a lot. So they are now moving towards an asmjit solution, but the trick is they cannot tell how the performance will be until all instructions are ported...

Return to “DSP and Plug-in Development”