I’m trying to connect several plugins to a matrix (Melda ChannelMatrix) so I can choose the order in which the signal passes from one plugin to another. If, for example, output 2 of the matrix sends a signal to a plugin and this signal returns through input 2 of the matrix, no signal reaches that input. The only way to make it work is to place an instance of GPrelayer after the output of the second plugin that sends a signal to another instance of GPrelayer that is connected to input 2 of the matrix. In any case, the limitation of creating feedback occurs with any plugin.
That is by design
If you really need this you could try using 2 gp-relayer instances.
But you could end up with a loop so be careful. Speakers/headphones to the lowest volume level!
Yes, I did. But I ended up using 10 instances of GP Relayer. It’s very resource intensive, and the CPU usage increase is significant. I can’t have all the plugins in the chain active because the CPU reaches 100%.
Ok, but it would be more useful to have a configuration option that allows the user to enable or disable this behavior, as happens in Reaper.
I think I understand what you want to achieve: One general purpose rackspace that can be configured by the matrix to have different sound options, for different songs, or song parts or performances.
Maybe think of a different philosophy, more suited to GP: Having a dedicated rackspace for each different song or performance, with the plug-ins in that order and only those required for that particular song or performance. GP is quite efficient both in RAM and CPU in working with dozends of rackspaces. In my gig file, I have 100 rackspaces for 100 songs with roughly 1000 plug-ins loaded, including heavy beasts.
Patch persist allows seamless switching of rackspaces. Within one song you could use variations in song parts, switching audio mix between parallel chains of plug-ins in different order, for changing sound.
1 Like
Yes, I know how to operate GP. I have a ton of projects with a ton of rackspaces… and so on. But that doesn’t preclude the search for new ways to approach sound design and, above all, having to think less and less about the “machine layer.” Working with rackspaces is great, and I’ve achieved interesting configurations that I know I couldn’t achieve in other environments, but the modularity inherent to the GP interface, I think, is affected by these kinds of restrictions, which, honestly, I can’t understand why; as I mentioned before, this is allowed in other applications.
You can use the To/From Global Rackspace blocks for this kind of thing also. In a free routing system such as GP, I don’t see any problems routing things the way you want. It just may take a few extra hops.
I’m inclined to agree with @Angel though. Rackspace switching is how GP is designed to work, thus keeping down CPU usage.
Also, the words ‘Feedback’ and ‘Live performance host’ don’t really go well together. 
4 Likes