One of my pedalboards has got a very high CPU load and I started to optimize it.
During optimization I found out that the CPU load of the MOD Duo also seems to depend on the audio routing.
Then I started to dig a bit deeper, and began to strip down the original pedalboard in order to find the source of the load.
In the end I found two easy to follow combinations that seem to contain the problem that I just don’t understand - maybe it’s a bug in one of the effects??!
The following two pictures show the same pedalboard - just with different routing.
The pedalboard contains:
This is simple. The audio graph runs in multiple CPU cores when possible, which happens to be the case for pedalboard 1, but not pedalboard 2.
On the 1st pedalboard, the 3 effects can run at the same time, then the output only has to wait for the “worst” plugin to finish.
On the 2nd pedalboard, each plugin has to finish processing before the next one can start.
For ambient sounds there could be a button to send the last buffer instead of the current one. Then it could be parallelized. Do you think this would be feasible with jack?
Thanks for the clarification.
So the overall performance of a pedalboard is dependent on each plugin’s processing time when enabled & the audio routing.
I already learned that it is worth checking a pedalboard’s maximum load when all plugins are enabled, in order to prevent CPU max load due to unforseen “ON” combinations, that might occur in a live event.
Oh wow, that could make a huge difference with my main pedalboard. I never knew this before but it makes sense and I will certainly test it out.
Given how non-obvious this is until it’s mentioned, it suggests to me a compelling argument for adding a “sanity check” feature where the software analyzes your pedalboard and makes practical suggestions about how to improve it. In this case it would simply notice metering plugins in the chain and suggest that they should be moved to be in parallel. Is that a reasonable feature request? If so maybe I should start a new post suggesting that.
It raises several more questions however:
In the case of plugins like TinyGain, is it the metering which is expensive, or the gain control?
If it’s the metering, is this always expensive, or only when the device is connected to a web UI?
Obviously it makes no sense to move gain controls to be the last plugin in a “dead-end path”. So would there be anything to gain by decoupling the metering from the gain, and having the metering at a dead end but the gain still in the overall path? E.g. like this if it’s desired to get post-gain metering:
plugin1 --> plugin2 --> gain --> plugin3 --> ...
\-> meter
