Running a huge patch (Planet Rungler) without sample dropouts!

This post concerns the Planet Rungler patch that @MinorNoise posted in my Venom Announcements thread over 1 year ago.

The patch is really cool, but it is huge and is a CPU hog with 16 independent voices. It does not run well live - the CPU usage consistently goes above 100% if run at a reasonable sample rate like 48 kHz.

But most of the time, only a few of the voices are playing at once. I figured there must be some way to get Planet Rungler to run at 48 kHz at well less than 100% CPU. I didn’t quite succeed on my Windows machine, but I have it working great on my M1 MacBook Air!

PlanetRungler with Bypass.vcv (108.2 KB)

I used my Venom Bypass module to bypass each voice. This was fairly easy because the voices were already separated from each other with a large enough gap for a 3hp bypass per voice, still leaving a gap between them. I configure the Bypass to disable the target and all neighbors to the left and right and patched the Bypass output to one of the unused inputs in the voice. Bypass is set to inverted gate mode so the voice is enabled when the gate is high, and bypassed when the gate is low.

There was already a polyphonic cable where each high gate represents a voice that is currently on. I split out the channels to individually gate the Bypass modules. The 16th voice is special in that it only turns on when all others are off. A Count Modula logic module was used to NOR the 15 channels. I substituted a Grande Logic module (much smaller), to first OR the 15 channels and then NOT that result to get the NOR result. That is then merged with the original 15 channels using a Grande Poly Merge to get a control gate for all 16 voices on one poly cable.

I assumed at least some of the voices continue to ring out after they have been turned off. So I want to bypass each voice 6 seconds after it is turned off. So instead of using the control gates directly, I pass the poly voice gates into the Gate input of the Venom AD/ASR. I set the rise time to a minimum value, and the Fall time to 6 seconds. I then use the sum of the Rise, Sustain, and Fall gates to gate the Bypass modules. The fall time gives me the additional 6 seconds.

But there was still one issue - sometimes when a voice is bypassed, there is a significant pop. So I needed to mute the mixer channel before the voice is bypassed. So I took another copy of the voice gates into a second AD/ASR module and this time set the Fall time to 5 seconds. The sum of the rise, sustain and fall gates is inverted and then used to mute the mixer channels.

The end result is a voice is only enabled (not bypassed), and the mixer channel open when its control gate is high. 5 seconds after the control gate goes low, the mixer channel is muted, and 1 second later the voice is bypassed.

On my Windows machine (4 threads) at 24 kHz the instant CPU usage is typically in the mid 40% range, but the Max occasionally strays above 50%, so if I double the sample rate to 48 kHz it exceeds 100% and I get pops.

But on the M1 MacBook Air at 48 kHz (1 thread) the instant CPU usage is in the low to mid 40% range, and the max rarely goes above 50%! It is a joy to run the patch at a good sample rate and not drop any audio samples!

5 Likes

Fantastic work! I have the patch just running on Windows (6 threads, 48 kHz, and max zoomed into a corner of the rack so that no module is visible (saves about 10% CPU for me)). The avg. CPU is just below 100% most of the time, with spikes sometimes above 100% if many voices are active. I still have very rare pops if modules are bypassed or un-bypassed but it’s almost not disturbing (the patch is quite noisy anyway…).

Definitely a huge improvement over the old patch that I couldn’t run on 48 kHz without constant crackling, no matter how many voices had been active!

Interesting that Mac excels so clearly here!

One thing I don’t understand: If only one or very few voices are active, many modules are bypassed, in fact so many that the summed CPU usage of all remaining non-bypassed modules is far less than VCV Rack displays as average CPU load. I never have less than 85%.

What does that mean? Are bypassed modules still consuming CPU, even though the performance meter (F3) shows nothing? Well, I wouldn’t expect 0% for bypassed modules (at least visual rendering needs some CPU, I guess), but 85% in a patch with mostly bypassed modules feels a lot. (I made a quick test: I can get to about 40% if I just delete all bypassed modules from the patch.)

Is there maybe a difference between Windows and Mac in that on Mac bypassed modules indeed consume almost 0% CPU but on Windows it’s significantly more, which would explain why Mac performs so much better with the patch? (I’m totally speculating…)

1 Like

Apple Silicon (M) processors are heavily optimized for single-threaded performance.

When comparing performance, you need to be factoring in CPU generation, cache sizes, clock rate. If trying to compare Mac vs Windows, fair comparison is comparing Intel Mac with Intel Windows. We can’t compare Mac ARM with Windows ARM because VCV Rack is not available for Windows ARM.

Some differences are because for Windows, Rack is built for ancient CPU and OS baselines, whereas on Mac it is more current. This leaves some performance on the table for Windows builds.

This from reading Rack source code:

The module CPU meters don’t include any measure of UI performance. It is only measuring time spent in the module process() calls.

There is no OS difference in the module bypass logic in Rack.

2 Likes

Yes, and even when bypassed, there is some processing time because there are voltage pass through operations that must be performed and virtually transmitted through the myriad cables. I imagine there is additional hidden bookkeeping consuming resources.

I am thinking the window CPU usage in the upper right measures total CPU usage, including UI?

That is great!

I think I was getting loud pops when certain voices were un-bypassed. So I modified the activation process a bit. A voice is now un-bypassed, and then 0.5 seconds later the mixer voice is unmuted and the voice activated.

I isolated the Audio output, and added a VCV VIZ to monitor the active voice gates (after inclusion of voice 16, but before timing operations). I also added a PatchMaster to remotely trigger the Reset, Clear and Start buttons in the patch.

Now I can run the patch at 48kHz on my Windows machine with 4 threads, and very rarely get any pops! (I make sure my web browser is closed)

The patch is saved in an already stopped state, ready to start immediately.

PlanetRungler with Bypass.vcv (109.4 KB)

1 Like

Thank you for the details! Very useful to know, especially this:

That’s right – it’s counted completely independently of the module meters.

1 Like

Same for me, at least once it was very loud, with master volume meters getting full red in the mixer :exploding_head:

Anyway, thanks for the patch improvement, I will try it later!

Wonderful! I didn’t get any pops at all after running the patch for 20 minutes! Just a slightly more performant Windows notebook, and the patch would run flawlessly, I guess! Or a decent Mac… :slightly_smiling_face:

Thanks for the whole patch improvement! I didn’t expect to ever look into this old patch again.

1 Like

Also important to note that even for Intel Windows vs Intel Mac, the Windows and Mac builds are made with different compilers (Windows uses GCC and Mac uses clang).
In my experience, clang usually produces better optimized builds, which could skew results a lot towards the Mac too.

2 Likes