fundamental
commented
6 years ago unfa was talking about filter DSP overhead and brought up Calf. While it's been a while since I've dug through the code, it seems like the code (for the vocoder at least) is more so optimized for readability and output accuracy than speed. If it sounds like the overhead is too much it seems like there are a few places where optimizations could help out. e.g. the way the filters are implemented could be changed to make it easier for the compiler to optimize the computation and have fewer memory ops shuffling data around. Rather than just fixing random things, it would likely be best to start with callgrind->kcachegrind to know where the true hot spots exist in the plugin. While it's not perfect it should point out any CPU bound operations. Anything more memory bound in my experience tends to be best addressed by followup sampling profiling.
boomshop
I've figured I can't use more than 1-2 instances of Calf Vocoder in Ardour, or my DSP load and make working on projects really difficult.
I've asked about this before, and I think the response was hat Calf Vocoder uses individual filters, instead of FFT to do it's thing, which has to be expansive.
However - I have asked Mark McCurry about if SUBsynth (one engine in ZynAddSubFX) is using FFT or individual filters, and he said it's using filters.
That got me thinking - maybe there is something that can be done to speed the Calf Vocoder up, if I can run dozens of instances of ZynAddSubFX using dozens of filters each in realtime without a hitch, but can't use more than a few Calf Vocoders before chainging my JACK buffer size to 2048 - I think it's too drastic of a difference.
I asked Mark McCurry about it and he said "I looked at the [Calf Vocoder] code for a few minutes and saw portions which looked like they were not optimized".
I hope maybe he can be more specific. I love the sound of Calf Vocoder, but it's DSP load makes it difficult to use.