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

[Shiek927]

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]

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

[numerouno]

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]

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]

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

[rafa1981]

Wow. A very clean one

[anoise]

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]

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

good work

[keel]

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

[EvilDragon]

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]

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]

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]

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]

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]

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...