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:
Something like this for MOD sounds quite doable, not a whole lot of effort and quite worthwhile in the end.
Adding to my TODO list for investigation.
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.
You might be interested in this thread :
I agree. Don’t turn the OS into a bloatware. Keep it efficient and easy to maintain. Niche functionalities should be handled by plugins.
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 !
So I understand it better. I build my boards for guitar in stereo using the 4 cable formula.
When I split my mono pedal into my stereo pedals I can use this pedal as it turns it into true stereo?
Hi,
Very cool idea, and webUI !
Wouldn’t be easier if the 2 plugins were only one with 2 ins 2 outs ?
I see why it has to be a plugin, now I think it has to be carefully documented in the plugins descriptions.
Description is a bit extensive already, dont want to add more before summarizing the existing text.
there is a direct button to this forum discussion on the plugin info dialog by the way, maybe that is enough…?
that last button leads here 
@falkTX You may want to include the detailed description that you gave in answer to me. The savings is difficult to visualize unless you understand what is being saved.
Okay, I’ve put the portal in my main board, which was using around 80~85% of CPU, with portal put before the delay it goes now around 65% !!!
Same!
Threw it in as a split from my mono effects to my stereo effects and it really helped!
I’m probably misusing it
I just did one silly test tat MAKES NO SENSE IN MY HEAD
yet
-25% processor load! just by putting a portal IN and OUT in front of those 2 parallel amps.
that is easy to see, introducing a bit of latency you now have these 3 chains in multi-threading:
the only point where audio meets in a waiting-for-processing manner is the 2nd gain (the one just before the caps plate reverb)
if it helps, think of the portals as loopback interfaces.
place the yellow sink on the right-most-side of the pedalboard, and the blue source on the left-most-side. this shows you how the processing is done, in a visual way.
I understand it better but not completely.
Not enough to know where the best spots are on my board but DANG DO I LOVE WHAT IT DOES.
3 weeks ago, I was struggling to get the Mutant running together with something else on my board.
Now I was able to expand my Mutant board with a momentary Dragonfly Reverb!
Yes, got a new board lined up for band practice on Monday 
PRO: massive CPU wins
CON: try to explain this to simple guitarists like me!
This could use a board building guide but the sentence: “running the 2nd part of a chain in another CPU core” is the most crucial one to understand
I know the “portal” gimmick is sweet but if this is about splitting it over 2 cores, everything, including design and branding, should point at that, as it makes more sense.
(Sorry, I’m not as smart as some of you guys but I’m on a mission to help to get this MOD Universe as foolproof as possible. )
Seriously; this is a HUGE breakthrough!
… but it lacks intuitive usability
I would vote to mature it into something dummies like me understand. If the idea of “run on another cpu from here” really IS the main deal; build the story around that!
Also; perhaps the next gen portal plugins could be made a bit smaller? my older laptop upstairs makes it hard managing and rendering all these large plugins
The problem with trying to understand this is that you would need to understand parallel signal path first…
These plugins do not do any magic whatsover, it is really just:
It is the host and its multi-threaded path processing that allows this to happen in the first place.
The portal just simulates you taking audio from a place and routing it back into the unit.
You can try this yourself to see it in action:
Using this approach you get exactly the same effect.
Assuming the 2 processing series do not share connections on the pedalboard, they will run in parallel on the CPU.
type or paste code here
A bit of a clarification would be great here.
Lets say I have some chain with a non-reverbed sound, that I would like to hear without an added latency.
Also there is a chain that will take “clean” sound and apply heavy reverb-delay-etc stuff that I would like to offload to the parallel processing and latency does not matter that much.
In the end I would like to have a bit of the non-reverb sound mixed with reverbed.
Do I get it correctly that the only place where I can mix them is the final “physical” output connector of the MOD device in the pedalboard, otherwise magic will not happen? For example I cannot have some shared final volume or mastering plugin for the both non-reverbed and reverbed streams?