KVR Audio

Shiek927 · Post by **Shiek927** » Mon May 10, 2021 9:56 pm

xhunaudio wrote: ↑Mon May 10, 2021 6:41 pm 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

xhunaudio · Post by **xhunaudio** » Tue May 11, 2021 5:54 pm

Are you sure ? It's a great news and it makes much sense...

numerouno · Post by **numerouno** » Tue May 11, 2021 10:59 pm

Shiek927 wrote: ↑Mon May 10, 2021 9:56 pm
xhunaudio wrote: ↑Mon May 10, 2021 6:41 pm 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

Shiek927 · Post by **Shiek927** » Wed May 12, 2021 1:32 am

numerouno wrote: ↑Tue May 11, 2021 10:59 pm
Shiek927 wrote: ↑Mon May 10, 2021 9:56 pm
xhunaudio wrote: ↑Mon May 10, 2021 6:41 pm 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.

numerouno · Post by **numerouno** » Fri May 21, 2021 6:09 pm

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

rafa1981 · Post by **rafa1981** » Fri May 21, 2021 6:40 pm

Wow. A very clean one

anoise · Post by **anoise** » Fri May 21, 2021 7:26 pm

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 · Post by **AnX** » Fri May 21, 2021 7:31 pm

numerouno wrote: ↑Fri May 21, 2021 6:09 pm Update: We now have a beautiful looking GUI courtesy of “Hoverland”

good work

keel · Post by **keel** » Fri May 21, 2021 8:01 pm

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

EvilDragon · Post by **EvilDragon** » Fri May 21, 2021 9:17 pm

anoise wrote: ↑Fri May 21, 2021 7:26 pm 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.

Shiek927 · Post by **Shiek927** » Sat May 22, 2021 12:10 am

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

rafa1981 · Post by **rafa1981** » Sat May 22, 2021 2:50 pm

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.

EvilDragon · Post by **EvilDragon** » Sun May 23, 2021 9:23 pm

Shiek927 wrote: ↑Sat May 22, 2021 12:10 am 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).

mystran · Post by **mystran** » Mon May 24, 2021 7:08 am

EvilDragon wrote: ↑Sun May 23, 2021 9:23 pm
Shiek927 wrote: ↑Sat May 22, 2021 12:10 am 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?

EvilDragon · Post by **EvilDragon** » Mon May 24, 2021 9: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...

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