docB padsynth crashes VCV VST

Running Bitwig 4.1.2 on an up to date win 10 system with VCV 2.0.4 as VST. Recently downloaded a couple of docB modules. Tried to select the padsynth in the browser but it just crashes VCV Vst. From the same dev: I tried the MVerb and it sounds great but is extremely CPU hungry. Can anyone confirm either one of the above?

I’m sure @docB will take a look. Was it the Pad or the AddSynth?

I don’t have VCV Pro to confirm the issue though.

I see the same for padsynth and similar for MVerb; Win 10, rack pro 2.05, Bitwig 4.1.3.

hi thanks for your report,

yes the MVerb is very CPU hungry as it has 5x5x4 = 100 delay lines. I have planned to try some performance improvements for the next releases.

Currently i have no VCV Rack Pro and no Windows but i will take a look what can happen on adding/startup the Pad module.

2 Likes

I’ve had a look at this and I think I know what’s going on.

The crash is due to a stack overflow when setting up the tables. You’re initialising a RealFFT with a length of 262144, which then causes the irfft() method to allocate 1MB of working space on the stack. That crashes because Bitwig’s plugin host only has a 1MB stack.

Standalone Rack has a 2MB stack, which is why you’re getting away with it there.

The correct fix is probably to provide pffft with a working space buffer, rather than leaving up to it to allocate the working space on the stack. The irfft() method doesn’t allow for that, but it’s only a one-liner that calls pffft_transform_ordered(). You could call that directly with a working space buffer that you manage yourself.

1 Like

hi, thanks! Great effort! I will fix it in the next version.

1 Like

hi, can someone verify?

Did a quick check for the padsynth: it can now be loaded without crashing VCV. But it is also quite CPU hungry. It runs at about 8 to 9 % CPU on my system in VCV VST. This stays the same whether I use one voice or more.

hi thanks for verifying! regarding performance i wonder about, because PAD on my linux system in VCV Rack Standalone has 1.7% with 16 voices and 0.5% with 4 voices. (it does not more than a sampler while playing - reading a lookup table). What is your setup?

Did a quick test with VCV standalone 2.0.6. CPU usage fluctuates between 1 and 8 to 9 % with an average usage of 5 to 6 % for 10 to 16 voices. I’m running an up to date win 10 laptop with an Intel i7 processor. As I’m not a programmer I have no idea what could cause such difference. If I could make a request I think it would be awesome if the modulation processes could be made smooth instead of abrupt as they are now and if maybe cv inputs for modulation control could be added. Anyway thnx for your quick replies.

ok, I’ll recheck it on other hardware i have.

your feature request is valid I’ll have a look onto it in the next versions.

I’m a programmer. It is that every now and then the module needs to do a large FFT that takes a lot it time, and then for many other process calls it does not need to do this?

1 Like

i dont think this is the problem. the ifft is only called from the ui thread if the mouse is released on a parameter knob. the audio process only does make a table lookup.

I tend to believe you :wink: btw, this stuff here is pretty basic, so may not be anything useful. Demo/efficient-plugins.md at main · squinkylabs/Demo · GitHub

thanks for the link, i have already took a look at it for a while, great resource. I’ll tryout next the MeasureTime class in my performance test project.

oh, cool. I have to admit that my perf tests just measure for a second, they don’t find spikes. good luck!