Hi everyone, I would like to introduce 2 new plugins, part of the same set called “Portal”.
The Portal audio plugins allow you to magically send audio from one side of the processing chain into another.
They can be used as a way to parallelize the audio processing by forcely splitting a single chain into 2.
Explanation
Imagine the scenario of 4 plugins running in series (one after the other), where each plugin is given a letter:
A → B → C → D
Plugin D waits for C, which waits for B which waits for A, all a single line.
In audio processing each plugin runs consecutively one after the other, typically on a single CPU core.
From A to D, all plugins must be able to process audio within a certain time limit, otherwise xruns occur.
If one plugin in the chain is heavy, it will limit the amount of time and processing available to the others.
Now imagine the scenario of 4 plugins running in parallel, using 2 series for simplicity:
A → B
C → D
There are only 2 dependency chains now, B waits for A and D waits for C.
This means the 2 series can run in parallel, each on its own CPU core.
In the audio processing side the time spent running all plugins is now up to half of the first example.
We can run as many series as there are cores in the system while keeping good performance.
By splitting the processing chain in 2, the Portal audio plugins allow running the 2nd part of a chain in another CPU core.
Simply load both sink and source portal plugins and connect each to the appropriate plugins.
Note that only load 1 sink and 1 source can be loaded at a time.
The side effect is 1 audio cycle of latency coming out of the source/exit/transmitter portal.
(On MOD this means 2.6ms on the default 128 buffer size setting)
For some effects like delay and reverb this could be a worthy compromise.
Let’s take an example pedalboard that pushes Dwarf quite hard:
The final gain plugin in the chain is not really needed, but that is not the one that uses the most CPU.
Roamer, the 2 IRs and Dragonfly Reverb are the heavier plugins, specially Roamer and Dragonfly.
For reverbs the latency does not matter too much as it is less noticeable so we can split the processing right before the reverb with a portal.
Like so:
The result is a big reduction in apparent CPU load (from ~90% to ~55%) or we can better say - using parallel processing more efficiently.
This is a bit technical and not something that might be straight-forward right away, hopefully my explanation on the first post with this example makes things easier to understand…
Hope you like it! and enjoy!
Testing and feedback welcome, of course, there are 4 known issues:
firefox shows graphics oddities around the portal rotations, does not happen on chrome-based browsers
connecting portal sink to source leads to undefined behaviour (mostly just noise)
a click-free bypass is still to be done, before pushing to stable (assuming it does go to stable anyhow…)
there are some oddities around jack cables appearing below the portal, a web gui bug to be fixed soon
I’m not sure how 128 with a pair of portals would be any better than 256 without the portals. Now if you actually have 2 parallel chains on your board and you could run each of the parallels in different threads, that would be a definite advantage.
Running the whole system at 256 frames means we are dealing with 5.3ms per audio cycle (via 256 / 48000 * 1000), x3 for alsa and jack async buffering. So it gives more time for plugin processing, but end result is a 16ms latency purely on the software side.
On 128 frames with a loopback-like system that the portals do, we instead add a single 2.6ms (via 128 / 48000 / 1000) to the chain, which ends up being around 11ms in total when the portal plugins are involved (basically 2.6ms * 4)
On top of a great mountain sits an old wise god - Musicus Audeus - who fills the lands each day with wondrous harmonies to keep the people joyous and happy. Musicus Audeus does this in return for a daily delivery of three items: fresh cream, fresh bread, and a block of the finest cheese. Each day, the people pack dutifully pack a mule with the desired items and send it on its journey up the tall, treacherous mountainside. Usually the mule is able to make it before nightfall, but sometimes the mule fails in its journey and this angers Musicus Audeus, who will then refuse to produce any music the next day.
One day, the plains people come up with a plan. They send the mule with only the cream and the bread, but instead of packing the cheese, they set it aside and instead send along a note begging Musicus Audeus to forgive them this one time, and in return they promise that the three desired items will always be available for her by nightfall. Without having to carry the cheese this day, the mule makes it up the mountain by dusk and without being too exhausted. The next day, the plains people bring a second mule for the journey. This time, they load the first mule with the cream and the bread, and second mule takes the cheese from yesterday. The cheese for today is once again set aside. Both mules make the journey up the mountain with relative ease, and Musicus Audeus is pleased with the smooth delivery, barely paying any attention to the fact that the cheese is from the prior day.
And so it goes for many moons, with the two mules splitting the load - one with the day’s fresh cream and bread, the other with the cheese that had been set aside from the previous day. Musicus Audeus remains pleased - sometimes even impressed that the mules can arrive by late afternoon - and the lands are filled with glorious harmonies in perpetuity.
Quite interesting. I do not recall bumping into xruns a lot on my MDX, apart from trying some shady beta plugins, but I will try this portal-based latency trade-off next time I see an xrun.
If I get it right, looks like the nice part is a possibility to keep original low latency for the more or less clean sound, and to use this portal stuff only for the ambient textures where added latency would not be noticeable anyway, but cpu usage might be serious.
P.S.
Meanwhile, MDX has 2 more cores than Dwarf, is it theoretically possible to have more portals there? Not like I feel very limited at the moment, just curious.
Thanks falkTX, i did a try , it’s very effective.
The problem being highlighted with the use of IR reverb, wouldn’t it be easier for some users if PORTAL was directly included in each convolution reverb plugin?
I feel like that would generate even more confusion, the plugin(s) would need to do their own buffering and thread sync which doesnt always end well.
This portal idea is so that the host can still own and control the whole pedalboard / audio graph, the order of processing can be kept on host side.
The only thing the portal does to slightly get in the way of this is to ensure “source” always runs before “sink”, as to keep processing order consistent internally too. Since the “source” has no input ports it is typically one of the very first plugins to run on the audio graph, in theory being safe to wait for it.
I like the idea. And maybe I got the whole functionality wrong but isn’t that a function that the system should do on its own without a need for user interaction or extra plugins?
The underlying system knows the signal path, maybe the best split point and what is hogging the cpu. Why not do this rerouting stuff in the background?
This seems overcomplicating a system that’s already complicated for the user.
doing it in the background sounds even more complex to me to be honest. I cant see how it would technically be a better solution, specially if trying to do it automatically.
for one, users make the most complex audio paths, finding the right place to split a chain is not as obvious as it might appear, would only work for simple pedalboards.
the split introduces latency in a few places which leads to phasing issues if not done carefully (combining the output of regular and split signal chain, for example).
an alternative I would be ok with is a system-level audio loopback, alike done with the MIDI virtual loopback optional port. jack2 actually has a way to do this, but it is not something we can enable/disable at runtime, so if going for this we would increase the base cpu load on the entire system…
pushing such functionality to plugins is the way to go in my view.
it does not require system-level changes, so no risk of breakage and less stuff to maintain overall in the end.
I have some ideas on supporting web-midi through a plugin, usb audio cards also through a plugin etc… it is a lot faster to have this work on a plugin than trying to integrate it all on jack, mod-host, mod-ui and also system service stuff…
it is also a question of QA and testing, where an official system feature will need testing on duo and its variants, 2 duox models and dwarf…
on the other hand, plugins are self-contained and do not risk breaking other system-level things by mistake. plus one gets the extra functionality a bit faster, no need for beta-testing specific builds for example
ok that makes sense then. Not really from a user perspective but I get it’s a lot easier to maintain everything.
How do I know which plugin uses the most CPU?
Good question
For now it is kinda guess work, being the one that introduces more CPU when added to a pedalboard I guess…
I like how VCV Rack decided to handle this, they have an opt-in per-plugin CPU meter.
It is not enabled by default, which is crucial as this metering costs some CPU and it goes up linearly with the amount of plugins/modules one has loaded. But it is great to temporarily enable this mode to check how the CPU is being spread out across all the modules.
It is not hard to do at all, just timing of start and end of processing, some averaging filter and divide against max allowed time…
Example using Cardinal since that is what I have at hand now:
that would make it a lot easier to use on existing pedalboards.
A little cpu % and meter left of the info icon of every plugin. The main cpu acts as a toggle switch and shows all meters. You wouldn’t even need to activate it on a per-plugin basis.
HI, i have to say that this is the biggest improvement for me and i’m in the need of telling you all.
I always tried to make one giant pedalboard with 4 paths (clean - crunch - dis - high gain)
all together on one pedalboard with the same effects in the front (like chorus wah etc) an the same in the back (delay - reverb - cab sim etc); all controlled with a external midi footswitch with 12 footswitches.
i always struggled with the fact that all these effects in series add up CPU like hell especially cab sim at the end. Some days i thought - god damn why is there not more CPU power why didn’t mod take a more potent CPU
enough talking this pair of plugins solved that problem for me perfectly. @falkTX THANK YOU ! great work
here is the pedalboard i’m talking about.
it is build for a fender strat. there needs to be some tweaking regarding gain staging but anyways maybe somebody has fun with it.
EDIT: now i can add potent IR Loader at the end or even the LP3 or other CPU hungry stuff which would be a nightmare in this kind of series pedalboard - just nice !
