Performance Issues

[TheGarnet]

Why has no one mentioned the Module Designer sub-forum? That's exactly a forum for developers.

Reid

Thank you for that.... There are certainly a lot of subforums to explore here!

Here is a link directly to that forum: viewforum.php?f=9

BTW, I made my first module today! My son, who normally is not into electronic instruments, and likes building his own guitars out of cigar boxes, and is into minimalism, was impressed when I showed him my VM music piece.

And I showed him debugging my first module, which was just an in jack, and an out jack, connected by one line of code. He immediately saw how modules are similar to guitar pedals. He was so excited, he said he had been trying to figure out how to explain to his wife what I do. This was perfect example to tell his wife, "This is what my dad does".

He wants to sit around with me and invent new ideas for modules.

[ColinP]

Hi TheGarnet,

Thanks for the CPU info - so it's a 24 GFLOP CPU. Which is not bad for a four year old machine.

I think you mentioned it being able to run a 44 module patch containing 3 monophonic and 3 polyphonic sub-patches. That's about what one would expect on a CPU of that power.

By the way CA have recently added a page discussing CPU performance tuning on their website but it's a bit hidden away...

https://cherryaudio.kayako.com/article/ ... o-products

Congrats on getting your first module running. That first step is the biggest hurdle. Now if you need some simple but highly specific function that you can't find in an existing module you can knock it up yourself.

[ColinP]

Are you saying you want non-module developers to be excluded from discussions by module developers?

No, Colinp mentioned not wanting to bother non-low level code people with tech talk about low level CPU capabilities and how programmers need to be concerned about performance.

Yeah, that was me sliding off on the metering thread. As we'd been discussing VCV Rack and I'd brought up SIMD I thought it useful to provide a link to show just how ugly C++ can get doing SIMD programming. It wasn't worth starting a thread elsewhere on the topic so I was apologizing for going off topic.

[Steve W]

Why has no one mentioned the Module Designer sub-forum? That's exactly a forum for developers.

That was in the first draft of my reply to The Garnet. However, I felt that the discussion points raised could easily be of interest people who choose not to develop modules and I didn't want to encourage tech talk to be syphoned off.

Until module developers get their own subforum here, I guess discussing these things here for regular VM users to enjoy, is the best we can do!

While discussions of ideas, tips, and techniques on how to design modules necessarily involves tech talk, I think it is a mistake to assume that "regular VM users" have no interest in tech talk.

[Steve W]

Are you saying you want non-module developers to be excluded from discussions by module developers?

No, Colinp mentioned not wanting to bother non-low level code people with tech talk about low level CPU capabilities and how programmers need to be concerned about performance.

Yeah, that was me sliding off on the metering thread. As we'd been discussing VCV Rack and I'd brought up SIMD I thought it useful to provide a link to show just how ugly C++ can get doing SIMD programming. It wasn't worth starting a thread elsewhere on the topic so I was apologizing for going off topic.

Thanks for the clarifications.

[Steve W]

Since yesterday I have tested the Messed-Up Massive Miniverse [MUMM] Demo patch several times. Apologies for not writing up all the details and results along the way, but based on my most recent test I am finding the noise / glitching / auditory instability in the audio output that is not being recorded internally by VM.

While this might be idiosyncratic (unique to my PC and my test process), there is a chance that others might get similar results. For that reason, I share the following. Maybe others will get similar results, maybe not.

A condensed sum total step-by-step process (plus some of the results of my various tests) amounts to something like this:

• (1) Begin with the MUMM Demo patch that TheGarnet was kind enough to construct and share.
  (2) Using basic, sustained tones, reduce the density of the patch audio so that the audio is reasonably stable with absolutely no mouse movement but which gets more unstable with increased mouse movement.
  (3) Start VM's internal recording.
  (4) Minimize VM.
  (5) Grab and Drag one edge of any open window on the desktop (I used Task Manager) and move it to generate sonic instability.
  (6) Pause the dragging mouse motion while holding onto the edge to periodically let the sound stabilize.

• Note: Part on my sonic instability included a downward, across the board pitch drop on the sustained tones in addition to lots of crackling that returned upward once the edge dragging stopped.

• (7) Return to VM, stop the recording, find the audio file, listen to it.

On my recording there was no discernable audio instability. I would be interested to know if this is similar on other computer. If not, I will take steps to further fine tune my audio PC. But if others get similar results, I am hoping this will help the developers to isolate the issue.

Thanks for your help.

PS: Later today or tomorrow, I will try to duplicate this simultaneously recording both internal and outputted audio.

[HowlingMod]

i did test the patch, on my laptop, a I7-9750H, high performance mode...

with my Focusrite Solo, that i bought as third soundcard, when... o well... second hand, i saw it somewhere.

terrible, inefficient soundinterface by the way. the one i had before, UMC204HD, performed much better, but i sold it, cheap, because that person, well.. does not matter...

but it is terrible inefficient, yes a soundinterface/driver has an impact, and can have a lot of impact on performance.

but at 512 samples (which in reality is 1024, double buffer), and threads up to 12, the max of cores including virtual ones, it works, with playing the screen keyboard with mouse going wildly....

i used the standalone mode.

turning off loggin can help, and indeed, thread count.

if needed, and perhaps for pure curiosity, i shall check it also on my desktop, which is more recent built (built it myself, the laptop; not...), and outperformances my laptop, with, well, 12 real cores + per core high IPC, even if all are being used, also because of the RME interface (with PCI... bridged).

[Steve W]

Update on previous observations re: audio from the VM's audio output v. audio from VM's built-in recorder:

Using the same modified Messed-Up Massive Miniverse [MUMM] Demo patch I described above I added Nrgzr78's new, free CPU Load module.

• The module consistently tracked approx. 5-10% lower than the VM CPU % reported by Task Manager.

• The audio from the audio outputs had instabilities including noise garbage and pitch dropping with increased mouse movement.

• The audio that was recorded by VM had very little noise garbage and no discernable pitch dropping.

[HowlingMod]

and if it is interesting; about my findings; @Steve W; with MUMM, you mean the patch in the first page of this thread, i assume, well the names are differrent, but yours is very descriptive.

tested in standalone & in Cubase 11 Pro..

at 256 sample buffer...

played without dropouts, even in Cubase 11 Pro (in a DAW i must set the thread count lower, which is not strange, set to 6, normally at 12).

system specs in signature. o yes; soundinterface, a much overlooked device for performance, a RME Hammerfall DSP Multiface. quite old, but still one of the best, within a certain price range, and certainly for performance.

didn't use the Nzgrz 78 module; in Cubase 11 Pro, sample buffer load is very high, but stable, which is quite normal for such a patch i believe.

there are many factors, as always; a seperate video card, can mostly unload a CPU, a good interface, gives you more performance, and as 1 core is really used for the audio thread; IPC per core (of course or else you wouldn't call it IPC).
and luck..

and in most cases, or all?, a desktop will always outperform a laptop.

[Steve W]

and if it is interesting; about my findings; @Steve W; with MUMM, you mean the patch in the first page of this thread, i assume, well the names are differrent, but yours is very descriptive.

Yes, initially I started with this one (sorry if my "descriptive" name was confusing):

If you have Miniverse, you can see where it falls over for me. It looks like 6 miniverse patches, which is 3 with poly modules, 3 with non-poly, is the tipping point for me.


With four Miniverses, (about 44 modules), it plays pretty well. But moving the mouse in front the VM window will cause audio glitches.

and then reduced the density of the patch to the point where I didn't get nasty distortion. That variation is what led to the mouse activity testing and then to compare record v. output.

Thanks for your observations and comments. I agree that hardware/resources will make difference. I will have to try the modified patch on a slightly older PC with a number of different settings. I am also hoping I can find an old hard drive that has an older version of Windows that worked with a sound card that was tremendously powerful and flexible (before Windows upgrades made the software/drivers non-working).

It is odd, though, that I have had my PC running with considerably higher overall CPU usage with all sorts of software running and didn't have the issues I had with this patch. I just tried all different buffer sizes, and all of them have the horrible noise. Oddly enough 480 and 960 samples have a lower rate of glitching.

Again, thanks for your thoughts. I might just have to avoid all these newer modules.