[rewritten to make the original question, spread over 3 posts, more compact and informative]
While creating a rack with modularly connected “audio processing blocks” I experienced severe slow downs of the editor. CPU load itself was ok though. (some detail about the rack is described at the end of my post.) A short example of routing scenarios:
Main Out receives from: InsertFX1 <- Preamp/Gate <- Input Send Out receives from: SendFX <- InsertFX2 <- [use Preamp/Gate as Origin] vs Main Out receives from: InsertFX2 <- InsertFX1 <- Preamp/Gate <- Input Send Out receives from: SendFX <- [Delayed Double] <- [use InsertFX2 as Origin]
As GP only offers mixer blocks for handling routing, I re-purposed Mixer blocks as switches and used solo function to create a flexible 1 in, 1 out connection.
Trying to understand the bad editor performance, I speculated on how the wiring view is transformed into an executable audio/vst network. I guess that on each connection change, GP re-runs the whole wiring analyzation and resolve routing/execution order, which becomes very slow when complex or even looping routes are involved. (performance decreases due to looping routes already had a thread here - Spinning ball (Mac) after every change to wiring - #70 by joebot )
So I think the true issue here is that GP does not know about the intention of using the mixer as a switcher:
Conceptually, a mixer is a many-to-many connection to GP. It will try to make sure all input routes are resolved because only with all input signals available, the mixer can do its job.
This is different to a pure switch, where only a single input and output can be active at any time, resulting in different possibilities for resolving the audio flow.
So in my mind, the idea of separating “switching” from “mixing” was born.
With the limitation of having only one input and one output active at any time, GP could better understand the user’s intention. From abstract POV such a concept would create isolated/linear subsections which can be connected in various ways, but always with a clear signal flow.
(visual sub-racks would be pretty cool by the way, haha, but that’s not for this thread.)
I ensured that there are no actual loops in the rack, but the complex possible routes from GP’s POV lead to massive route calculations resulting in awful performance (10-15 seconds for every connection change). Right now I think I’ll have to remove some of the features because the editor is pretty much unusable.
So what do you think, are my speculations right?
Do you think a switching block could be a worthy addition for GP?
Is it even possible to enhance the wiring resolver with such a block without starting from scratch?
“switching” mixer blocks at top bottom.
In between are 4 columns:
center columns: Inserts1, Inserts2