[BUG] Pan LFO uses lots of CPU

[steveb]

Describe the bug DAW and ChowMatrix becomes unresponsive when multiple nodes have pan LFO enabled, with multiple ChowMatrix plugins running

To Reproduce Steps to reproduce the behavior:

1. In a DAW session create multiple ChowMatrix plugins
2. Create multiple nodes in those plugins
3. Enable LFO panning in those nodes
4. DAW becomes unresponsive, ChowMatrix text entry boxes become unresponsive so it is difficult to turn panning off

Expected behavior Panning LFO would ideally cause minimal load, so I can have many plugin instances with much LFO panning.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Fedora Linux
• DAW Ardour-6.8.0
• Version ChowMatrix VST binary 1.2.0

Additional context I love this plugin and want to use it everywhere all the time

[jatinchowdhury18]

Thanks for reporting this issue! I have a decent guess that the issue has to do with the UI re-painting. I had a similar issue on Linux with the Insanity visualization, which led to the introduction of the "UI throttling" option.

One way to test this would be to assign the pan LFO parameters to a global parameter target, and then try changing those parameters with the UI closed (not sure if that's possible in Ardour). Would it be possible to try testing this on your system? I have a couple other optimisations to try out in the meantime.

Thanks, Jatin

[steveb]

I've just set up a small torture test in Ardour with multiple ChowMatrix VST plugins in series. The CPU seems to rise for every LFO that is set above 0Hz, and it doesn't seem to be related to whether the ChowMatrix UI is open or closed.

21% CPU, 4 plugins, 2 nodes, no LFO panning, UI open
21% CPU, 4 plugins, 2 nodes, no LFO panning, UI closed
106% CPU, 4 plugins, 2 nodes, all LFO panning, UI open 106% CPU, 4 plugins, 2 nodes, all LFO panning, UI closed 140% CPU, 8 plugins, 2 nodes, all LFO panning, UI closed (ardour and chowmatrix UIs unresponsive)

Thanks

[jatinchowdhury18]

Okay, this is awesome data, thanks for sharing! I definitely know where to look now for improving this.

A tiny bit more information that will help: could you share your session sample rate and buffer size, as well as the CPU that you're running on?

[jatinchowdhury18]

So I had a chance to look at the pan modulation code this evening and noticed a bunch of "mistakes" that I made when programming it originally, including:

• accessing two atomic parameter values every sample
• calling sqrtf() three times per sample via processor.setPan()
• running the modulation sine wave at a much higher sample rate than was necessary.

Anyway, I've made a branch with some optimisations. @steveb if you're comfortable building the plugin yourself, would you mind testing out these changes? If not, I can try to make some builds for your system.

Thanks, Jatin

[steveb]

My session rate is 48kHz, 128 sample buffer, Intel® Core™ i7-8665U CPU @ 1.90GHz × 8

I built the pan-mod branch and I think there is a small improvement. Ardour has a Plugin DSP Load screen, here each ChowMatrix instance has one more node with modulated pan. Here is a master branch build: and a pan-mod build: But the UI still periodically gets very laggy and unresponsive. Bypassing every ChowMatrix plugin allows it to recover, then it is fine for a while when they are re-enabled until it happens again. Here is the plugin load spread after this has happened:

[jatinchowdhury18]

Good to see that there is some improvement! I spent some more time this evening trying to re-create the spikes like you noticed and performance profile to see where the spikes were coming from. Unfortunately, I haven't been successful, but will keep trying. In the meantime, would you be equipped to try profiling the plugin locally on your machine? This may be easier with the standalone plugin, than profiling it in Ardour. Speaking of which, do the CPU spikes occur with the standalone plugin also?

Thanks, Jatin

[jatinchowdhury18]

Since the change mentioned above does show improvement, and because it's just better code, I'm going to go ahead and merge it (#99). I'll keep this issue open to keep working on this issue in general.