That explains it quite well in my opinion.
3 Likes
I agree with gianfranco and spunktsch, going too technical would simply confuse me. I’m not really that interested in a geeky way how something like this functions. If it helps me with saving CPU usage that’s fine with me.
I have though “bookmarked” this discussion to come back to when I get around to trying out these two plugins.
2 Likes
I don’t think this question was answered, but I think having a single plugin is a more user-friendly option.
I would also consider moving away from the “portal” metaphor. I get it, it’s fun and I understand the reference (and the UI looks cool), but I also think it will serve more confusion overall. I’ll try to think of a fancy title, but even a pedestrian name of “CPU Reducer” would help convey the purpose more clearly IMO. The description should start simple and can progress with increasingly more technical information for those are interested:
This plugin can reduce load on the CPU with some specialized internal audio processing scheduling. It accomplishes this by adding a small amount of latency to the signal chain. See the examples below for best results
Then I’d include a few example pedalboard images annotated with details about where the plugin is placed and why. Then include a brief troubleshooting checklist for “The CPU load didn’t drop”. Finally, you can include the more technical audio loopback / scheduling explanation at the bottom.
10 Likes
I actually love the name Portal. I brings to mind diving into another route/realm that magically helps me.
Not sure about it being just one plugin. the actual visual thing of seeing the “entrance” and the “exit” portals has a sort of mythic tinge to me. Just my two penneth as we say in the UK.
The “magic” only works when we purposefully split the chain into 2 series.
If we have a single chain, the host won’t be able to parallelize it no matter how much buffering we do. So having 2 plugins is a requirement.
1 Like
Maybe the previous question could be translated as “we know that is two pedals is computationally required, but is it possible to mod ui abstract this fact and show us just one pedal/UI instead of two distinct pieces?”
Also, @falkTX, there is something that isn’t clear to me. You sad
But in terms of latency, both increase the same amount of latency? I thought that portal was cheaper because it doesn’t involves process like AD/DA conversion.
1 Like
Yes, this is what I’m asking. It’s not clear why the implementation detail can’t abstracted by a single UI plugin, since every example I’ve seen has exactly one sink and one source.
I would find a single modgui to be confusing, as we are meant to split the audio chain and this becomes less visible if it is all one single line.
The host is already doing parallel processing if there are multiple paths on the pedalboard, the portal plugins allow to branch off in another way but still with the very same idea.
I’m developing some intrest in “foolproofing” the description / usp of the Portal.
The main USP (unique selling point) has to be a bit of a “one size fits all” explanation while a deeper dive could document more specific cases and exceptions. In this case the essence is: “lower your CPU usage”
So, while I know I ignore some of the subtleties here but I try to adress “the masses” here.
Lower your CPU usage with the Portal
Do you like creating complex pedalboards with long chains?
Are you stacking plugins that use a lot of processor power like long heavy reverbs?
Have you bumped into the maximum capacity of your device now and then?
The Portal plugin can lower the CPU load.
When you add it to your pedalboard, the Portal plugin distributes the load in the background.
How to use:
- You put the portal somewhere in the middle a long serial chain of plugins.
Try break a long chain in 2 sections that have about the same load. - You put it between the plugins that use the most processor power on your board. Convolution reverbs, Amp sims that use a lot of oversampling,… Even on a board with a cabinet simulator will be positively impacted by the Portal
(( An example sketch could be something along these lines of simplicity: ))
The Portal can also help you in keeping your pedalboard by putting the OUT Portal somewhere else.
How does it work?
— to be written —
6 Likes
Maybe the least confusing would be virtual ports on each side like for the virtual midi loopback, but then we will have long cables across the pedalboard. On the other hand with two plugins you can improve the cables layout in any case. Anyway considering this is utility plug-in and no info shown on the gui, as small as possible, I think it would be better…
Edit: Or maybe show in the gui each CPU core usage would be possible?
About functionality, I just have a doubt: it is clear that the audio through these plugins, has a latency of one cycle more, but in
Has the dry signal (not through portals) also this one cycle latency more on the joint point? Or it just waits to the previous cycle reverb audio?
1 Like
if a connection before the portal joins something after the portal, it breaks your illustration due to phasing issues (one signal is 2.6ms behind the other).
I really do not think this is the approach to communicate what it is doing, the simple drawing only work for exactly that - simple connections.
Quite a few of shared pedalboard include at least 1 branch (where 1 plugin feeds into 2 in parallel), having the portal only shown and described in super simple terms will lead to confusion when things start to sound weird (again due to phasing).
the path that gets into the reverb has latency yes, and it does meet up with the main branch in the end that does not have reverb. this would usually not be ideal or good, but since the reverb is running as pure wet signal, the phasing issues are not audible much
1 Like
Then we drop the drawing? 
What about the description?
Don’t get the wrong idea, I’m not in a bad mood here I’m just trying to contribute in a smooth user journey for people coming into the MOD universe, approaching it from my end. .
After all, I still feel that is wherethe Community can help Mod Audio so I’m just offering inspiration and my perspective 
– so use or ignore as you seem fit.
The way it is communicated now doesn’t really help people understand. The main idea is to get people to understand when to use it and how to use it without going into deep or specific scenario’s.
I think the actual working only sit on position 5 in this order of questions users will pass through.
- What does it do? lower load
- How do I start using it? Like this
- Why does this work? 3 lines of text
- How do I optimize its use? Check that and beware of this*.
- Explain me how it really works.
I think that a group of users doesn’t even need to know what is going on from point 3 and just need to know how to use the Portal best. then again it comes down to some solid best practices that work as a model and not as a 100% accurate painting of reality. Just include the disclaimer that results may vary.
Phasing
Sounds like the phasing due to latency will happen in more use cases than I though.
“Using your ears” will always be solid advice but once again a few concrete “use the Plugin like this” best practices and examples work best. Keep out the clutter and examples that are too specific.
What best practices counter phasing?
Users need to keep their time-based effects together?
Splitting Drive and time-based effects works great?
Not the best idea to put the portal after a delay or reverb?
This could be brought together in one comprehensive paragraph
Including some more complex use cases further along the documentation can help
4 Likes
Maybe some diagramms of usage would be helpful, for example a full wet reverb or delay is save to use…
1 Like
@LievenDV i think it is awesome that you are writing some “layman” documentation and I want to help as much as possible.
I would like to share here some insights about the way that the CPU load works and how plugins impact the CPU load, as I believe that could be useful for a better understanding of the Portal plugins.
First of all, the CPU meter that we see in the lower right side of the Web UI is not the total CPU load of the internal processor of the MOD device, like the meters we see when going to the Task Manager in Windows or the Activity Monitor in MAC OS.
These computer CPU meters give us the total load of the multiple cores from our computer’s CPU, so if you have a 4-core processor and you are running a single-core program that takes 100% of that core and the other 3 cores are idle, your computer CPU meter will give you a 25% CPU load, as there are still 3 cores to be used for other programs, for example.
The MOD CPU load meter is given by JACK and it is related to the time it took to process the audio graph in relation to the total time available.
JACK works with a fixed buffer, which provides a fixed “time window” to process the graph. This time window is independent of what is being processed (adding more plugins does not add latency) and if the system has no plugins at all, the same latency is still there.
The CPU load it gives us is actually the amount of time that it took to process all the graph, in relation to the total available time window.
Let’s imagine that our sample buffer gives a time window of 10ms (the Dwarf uses a smaller window, but I want to make it simple here). If JACK is able to process the entire graph in 6ms, it will display a CPU load of 60%, independently of how the load is spread across the multiple CPU cores.
JACK already does parallel processing when possible but many times it is not. The issue is serialisation. When plugins are positioned one after the other, JACK cannot use parallel processing, as it needs the output of one plugin in order to process the next one.
This means that, in a serial chain, even if we have 4 cores, JACK will only be using one.
Let’s see some images to help:
Fully serialised chain:
Here we are definitely using only on core of the Dwarf. JACK is using 81.1% of the available time window.
If I go to the console and use TOP (the command line equivalent of Task Manager) we have this:
We can see that one core is very loaded and the others are not so much. One of them is actually quite idle and the average load of the CPU is only 19%, which is way smaller than JACK´s 81.1%
Now, let’s redo the graph, putting the same 5 plugins in parallel:
The JACK CPU load now is only 44%, even though the same 5 plugins are being processed.
Going to TOP, we can see the the overall load is spread in a more even way across the multiple cores and the average load is 24,2%, which is actually higher than the serialised example.
Now, going back to the Portal plugins. The magic it does is to split the CPU load of serialised chains, paying a tiny bit of latency to do that.
Going back to the first example, now using the portal, we can split the chain in different positions and we can see how the impact is different:
67.8%
59.9%
50.9%
67.9%
So, although all of the splits result in a lower CPU load, splitting between ChowCentaur and the ODJ gives the best result, as it splits the entire chain in a more even way.
It is interesting to see that, the strategy for using the Portal is to find the “critical chain”. That is the chain that defines the JACK CPU load.
Going back to our serialised example above and removing the DS-1 from the end of the chain, we have:
The CPU load oscillates around 70%
Now, If I add the DS-1 back, but in parallel, there is no impact on the CPU load, as it is using one of the idle cores:
By using the Portal, I can actually add the DS-1 after the OJD, and still keep the CPU load around 70%:
I hope these examples and explanations above help.
When I saw the portal for the first time I was also going “WTF?” and took me a bit to grasp it. I am no programmer, but I did a lot of Linux+JACK setup before the one and only @falkTX joined the team.
I believe that this “splitting” power of the Portal should be the core of the explanation and, because of that, I think that having it on the edges of the UI is worse and, if it was possible, I would prefer to have it as a single plugin. As it is not, I think it is didactic to use both side-by-side.
21 Likes
great explanation @gianfranco!
once again thanks to @falkTX as well for explaining as well.
It confirms where I thought this was going and we’re starting to get a lot together here that would make a fine wiki page.
Leaves me with this question though when I follow the logic of a signal chain:
Although we would like to put as much in parallel as possible, we want to stack plugins after each other like we do on our physical board. That’s because you want the next plugin to processor te result of what was coming out the first one.
Putting them in parallel will create a “sum” of these two instead, creating a different (ans often louder) signal…right? So in order to STILL do the serial thing while creating the parallel thing, we can use the Portal.
Brings me to the actual bottom line question:
The portal is the only way to serialize while processing over multiple cores.
There is no way to patch parallel chains in the UI while they sound as our old predictable physical board in series? (in other words, if that would be possible, it might look very un-intuitive but it would allow core balancing tweaks :D)
It is not, as in these serialized chains, the CPU needs to wait for one to finish, so that the next one starts.
So yes, I’d say that one of the Portal main features is to bring parallel processing to serial chains, at the expense of some latency.
1 Like
Thinking on ideal use cases, one I have discussed last Friday with @jesse is to use the portal to split the end of the chain where you have modulation and time effects.
Using the serial chain from my previous example, if I add a DragonFly Reverb plus a TTAP delay, CPU load blows up:
This end of the chain has a dry and a wet components, so we can add a direct patch from the DS-1 to the output and leave the plugins doing just wet:
But that does not help with the CPU load, as there is still a “critical chain” that passes though all the plugins.
But I can split the wet part like this:
Now the CPU load is still manageable, there is not perceptible added latency as the dry signal does not use the Portal, and the wet chain, which is much less sensitive to latency in this case, is diverted to another core.
These type of boards might actually be the ideal use case of the Portal.
13 Likes
That’s an interesting question. It seems it’s not possible to get the exact same result with parallel chains as with a serial chain. But it’s still interesting to know is what kind of parallel chains give good sounding results (eg : what plugins are worth processing a dry signal in parallel of a distorted tone).
For instance, the “INST” factory pedalboards have the reverb in parallel of the delay. They use volume plugins to send amounts of 100% wet signals. It reminds me the kind of setup you see in a DAW (with the use of busses if I remember well). But it’s less intuitive for a guitarist who is only used to physical pedalboards. Maybe @jesse could tell us more about this approach.
1 Like
For me, as a developer, it is class clear what the portals does and how they does it. I think to imagine what they do, best would be to have them as host sink and source (left and right side of the screen were you make your hardware connections). Then you understand that they are simply a internal loopback. Usability of them been much increased by present them as plugs.
2 Likes