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:
- Calf Envelope Filter v60.0-9
- GxCryBabyGCB95 V28.3-23
- Rakarrack Fuzz v0.0-6
All three effects are activated.
In this routing setup the CPU load is around 37%:
But in this routing setup the CPU load is around 60%:
Why does it make a difference for the plugins where signals come from / go to??
Thanks in advance for your thoughts and help.
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.
One bad use of plugins that I see a lot is having a meter-like plugin in the middle of the chain, that could be split instead.
plugin1 -> plugin2 -> meter -> plugin3
meter has to wait for plugin2, and plugin3 needs to wait for the meter plugin.
instead we could simply do:
plugin1 -> plugin2 |-> plugin3 -> more plugins
this way we can have a meter in the pedalboard without it causing less time for the important plugins.
something to keep in mind.
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 --> ...
On a related note, it might be worth revisiting Inconsistent Gain Handling - Feedback Welcome which IIUC was the original discussion which motivated the creation of the awesome TinyGain plugin. One of @x42’s suggestions there was to create a wiki page like “best practices for DSP on the MOD”. AFAICS this was never done, and it feels to me like it is still sorely needed. Is that a fair assessment?
@falkTX Would love to know the answers to these questions if you have a spare moment sometime