Waldorf Micro Q Emulator (Vavra)

[aMUSEd]

Just made some custom graphics for Vavra. Available for free at the same place as the plugin itself.

This is cool! I downloaded it on the discord, but how do I install it?

I think you just make a folder called skins next to the plugin and put it there but not tried yet as I can't find my way round Discord it's a very confusing site

[frag]

I have not had any drop outs (windows), I wonder if it’s configuration dependent?

I don't think so, because Virus C runs perfectly.
There's something different about DLL, but I can't pinpoint what it is.

Anyway, with realtime CPU priority I can play it like $3000 hardware synth

[aMUSEd]

Just made some custom graphics for Vavra. Available for free at the same place as the plugin itself.

This is cool! I downloaded it on the discord, but how do I install it?

I think you just make a folder called skins next to the plugin and put it there but not tried yet as I can't find my way round Discord it's a very confusing site

Found it now - my guess was right. That's how you do it

btw I like this skin but the LED showing patchnames etc is very hard to read - would be better reversed imho

[PhaseTransition]

btw I like this skin but the LED showing patchnames etc is very hard to read - would be better reversed imho

Easy to edit via .json file. =)

[frag]

I have not had any drop outs (windows), I wonder if it’s configuration dependent?

I don't think so, because Virus C runs perfectly.
There's something different about DLL, but I can't pinpoint what it is.

Anyway, with realtime CPU priority I can play it like $3000 hardware synth

The difference between Osirus and Vavra performance is drastic in my system.
I can play Vavra without dropouts only with realtime CPU priority in VSTHost, and with the window focused (not doing anything else).
On the other hand, I can play Osirus without a single dropout under normal CPU priority while browsing Youtube - in a virtual machine!

That's HUGE difference, BMW vs. bicycle difference.
Everything else is same, ASIO latency, latency in plugin etc.

Perhaps developers could look into this? Which parts of code are different in Vavra? I would expect these plugins to perform identically.

Cubase, unfortunately, ignores realtime CPU setting. The one application which really benefits from realtime CPU priority, is not able to use it

EDIT
Perhaps it's multicore vs single core?
I remember when I tried Diva, multicore was glitchy and unstable, and single core much, much more stable (though not "perfect").
Is MicroQ using multicore performance by default?

When I look at FAQ, it's Motorola 56362 both in Virus C and Micro Q - the exact same version of DSP chip! Just like Nord 3. So this really puzzles me.

[robindrieghe]

Changelog

1.2.36 (2023.04.28)

* Imp: Added Arp Pattern Length parameter
* Imp: Plugin does not crash without OS but displays an error message instead
* Imp: Plugin can now load the initial state from .syx files, too
* Imp: Initial state is loaded even if the Device ID of a dump does not match
* Imp: Output gain can be boosted by +6 db or +12 db via context menu, this setting is saved per instance in a DAW project

* Fix: Patch Browser displayed broken text if a .mid/.syx contained other dumps than Singles
* Fix: Patches couldn't be loaded from Patch Browser if the device ID of the patch did not match the device ID of the emulated device
* Fix: Loading Global dumps from initial state is skipped because it might break editor to device communication
* Fix: Switching from Multi back to Single mode was problematic / did not work
* Fix: Sorting in Patch Browser may lead to a crash

Audio output appears to be more stable, now it's same as Virus C on my computer. There are no glitches. It feels like a real instrument. Fantastic! Output gain is very useful.
As far as I'm concerned, I would only make GUI smaller but with bigger fonts in browser. That's it.
Also, behavior on patch change is strange, particularly with patches using FX. Weird echoes happen, it's difficult to describe. Did hardware do that as well?

yes it does

[osiris]

I never had dropouts or any such problems, but when I set it to report real time CPU it jumped from 20% to 40. I don't really understand this feature and never switched it over in Osirus. I think Osirus is much less CPU crunch because I can run multiple instances of it with tons of Effects and envelopes going and it's been manageable.

[rasmusklump]

It always consumes much more cpu in the background than shown in the host but just doesn't report it correctly to the host when not set to report real time.

[frag]

I think Osirus is much less CPU crunch

It seems so. But it's more complicated than that.

I did some simple measurements with task manager and here are the results under identical conditions.

Virus C


Micro Q


Total CPU usage is not much higher in Micro Q, but we can see than one thread is constantly getting hammered. The spikes reach over 80%.
Most probably, this is the cause of glitching on my system.

I'm not sure if there's a way to fix this. Perhaps if usage was more evenly distributed across threads?
Waldorf code appears to be more demanding, even though it employed the same Motorola 56362 as Virus C.
I hope Nord Lead 3 is going to be lighter, no FX, less multitibrality, whatever.

For now, I can play it standalone with realtime priority wthout issues.
In DAW it's a bit glitchy but in the end, you simply export audio and everything is perfect.
We thought "in-the-box" would eliminate these audio issues, but nooooo

[sl1200mk2]

When I look at FAQ, it's Motorola 56362 both in Virus C and Micro Q - the exact same version of DSP chip! Just like Nord 3. So this really puzzles me.

I'm trying to relay information as best that I understand it, so there could (absolutely will) be mistakes. My understanding is that the DSP56300 team has a 'general' emulation of the Motorola DSP chip functions. What they're doing for each synth is optimizing how their compiler (JIT/dynarec) works for that synth based upon how it was programmed. While each synth might use the same exact hardware DSP, how the programmers of that synth chose to implement their code and what DSP functions they optimized for will be dramatically different.

What the DSP56300 team can't do is disassemble the ROM's of each synth to thoroughly evaluate the code and understand exactly what and how to optimize their compiler for on a given synth. They're reverse engineering this likely through analysis using whatever internal tools they have, making educated guesses and iterating the compiler based on those results. They're at a huge disadvantage not being able to dissect each rom.

This is why one synth might run much better/faster than another. The team was able to better optimize the compiler for how that particular synth has implemented the DSP. This is probably through some mixture of improving the compiler in general, but likely just spending more time on that particular synth (the Virus in this case) and gaining a better understanding of how it works. It's unlikely that they can devote that much time to each synth, so hopefully they can brute force things through better performance overall on the compiler and experience gained over time knowing what to look for.

If I'm wrong or off on any of this, please correct me. I'm not a dev and just interpreting their blogs/posts as best I can.

[frag]

When I look at FAQ, it's Motorola 56362 both in Virus C and Micro Q - the exact same version of DSP chip! Just like Nord 3. So this really puzzles me.

If I'm wrong or off on any of this, please correct me. I'm not a dev and just interpreting their blogs/posts as best I can.

Interesting points!
I'm not sure how it works - I'm just posting my findings.

It's important to understand the difference between CPU usage and audio buffer/ASIO usage.

Here's another comparison, this time with Spire. I used a horribly demanding 16-voice patch.
ASIO buffer - almost 90%. CPU usage - evenly distributed across threads, low on each thread.
Barely audiable crackles, almost completely clean sound.

Micro Q with full polyphony (also in miniature SAVIHost):
ASIO buffer - almost 70%. CPU usage - one thread with very high usage.
Occasional glitches, very audible!

Conclusion: Micro Q plugin would DEFINITELY benefit from CPU optimization.

And now comes the tricky part. If sl1200mk2 is right, then CPU optimization depends on modifications of Waldorf ROM code. In that case, we're f*****. The only way for improvement is to get CPU with better single thread performance.

On the other hand, if this optimization can be done at the level of VST/DLL, then it's certainly possible. According to the measurements I posted, both plugins appear to employ multithread processing, however, it's not working properly. Most of the work is done by single thread. To be honest, I don't believe that Waldorf code can employ multithread processing. But, since it runs within EMULATOR, perhaps this emulator could "trick" the code that it runs on single Motorola DSP, while in fact, it runs on multithread CPU. That's an idea.

To make things more complicated, during one test even Spire collapsed to single thread processing. Needless to say, heavy glitching immediately appeared. With Diva in Multicore mode, you can get 20% Asio usage + even thread usage, but - the sound is not clean. What a mess

So, I'm not sure. I can pinpoint the problem, but this is up to developers.

[muki]

btw I like this skin but the LED showing patchnames etc is very hard to read - would be better reversed imho

yes
+1

imho barely readable

[Uncle E]

On the other hand, if this optimization can be done at the level of VST/DLL, then it's certainly possible. According to the measurements I posted, both plugins appear to employ multithread processing, however, it's not working properly. Most of the work is done by single thread. To be honest, I don't believe that Waldorf code can employ multithread processing. But, since it runs within EMULATOR, perhaps this emulator could "trick" the code that it runs on single Motorola DSP, while in fact, it runs on multithread CPU. That's an idea.

They are working on multi thread now. It’s the next thing on their list. If they pull it off, they will try to implement the 75-voice Omega upgrade, and if they pull that off, they will try to do the full Q. At least that’s the plan that I’ve seen talked about on the Discord.

[frag]

On the other hand, if this optimization can be done at the level of VST/DLL, then it's certainly possible. According to the measurements I posted, both plugins appear to employ multithread processing, however, it's not working properly. Most of the work is done by single thread. To be honest, I don't believe that Waldorf code can employ multithread processing. But, since it runs within EMULATOR, perhaps this emulator could "trick" the code that it runs on single Motorola DSP, while in fact, it runs on multithread CPU. That's an idea.

They are working on multi thread now. It’s the next thing on their list. If they pull it off, they will try to implement the 75-voice Omega upgrade, and if they pull that off, they will try to do the full Q. At least that’s the plan that I’ve seen talked about on the Discord.

Wow, that's great news! I don't know anything about VST dll programming, but "intuition" tells me this could be pulled off.
Perhaps the solution they come up with, might be applied to all these emulator plugins.
Though, I point out once again - Virus C is incredibly stable.
It seems that Access ROM writers did much better job than Waldorf

[Uncle E]

Wow, that's great news! I don't know anything about VST dll programming, but "intuition" tells me this could be pulled off.
Perhaps the solution they come up with, might be applied to all these emulator plugins.
Though, I point out once again - Virus C is incredibly stable.
It seems that Access ROM writers did much better job than Waldorf

I think they said the solution will be particular to the Micro Q. Basically, they're implementing multi-threading similarly to how Waldorf did the Omega upgrade.