If you want to do this only in one way or basically - just to control another GP, but you do not want that other GP to control you - then you could deliberately enter a wrong port or address for the “Remote client” on the “Destination GP”.
That way OSC messages should be able to come in, but they will not be echoed back.
I know this is not ideal, but it may be good enough to get you going until we figure a better approach.
That’s what I ended up doing until a solution can be found. Any thoughts on the VU meter though ?
Sorry, I was too fast, this is only working with Ableton Live and M4L and not with Gig Performer alone.
I tested many things with OSC… If I want to have both a direct and remote control of a GP instance, I need to break the OSC feedback. To do so I simply send an OSC message from the main GP instance to the second one. In the second instance I implemented a mechanism that move the widget corresponding to the OSC message and I i inhibit its WidgetValueChanged callback. If the widget is modified from the GP interface, the WidgetValueChanged callback sends the appropriate OSC message to the main GP instance. What I describe here is symmetrical and applies also from the second instance to the main one.
I think echoing the received OSC messages is not a good idea. It is the main reason why I often don’t use the regular GP OSC messages. The only use case I tought about this OSC echo, is when you are chaining OSC messages between several other OSC entities (without IP broadcasting).
This is a bad good idea, because if you try to send some OSC messages to a wrong IP address, the OSCSend process slows down the whole process trying to resolve the wrong IP address.
I think it is not possible to react to information from an audio block level (if it is what you want to use for your VU meter), with anything else than meter widget. It is something that I regret…
Nothing to resolve if you already have IP address.
So if we were to disable that echo for a future question of Gig Performer, is there a risk that this might break somebody’s existing setup?
They would have to script it. Not sure if gpscript syntax would be able in a few lines to achieve it if needed. I’m gonna script tomorrow to try to fix it
Wrong wording here, I wanted to say something like opening a (non existing) port on a non existing IP. This take a long time for each OSCSend operation.
I don’t think that people can make any benefit from an echo mechanism that creates loops (surprinsingly not infininite, but this is probably due to a loss of OSC messages at a time 
, elsewhere it should go on bouncing indefinitely).
Perhaps one could decide not to use IP broadcasting to chain OSC entities, like GP1 sends to GP2 and GP2 sends to GP3. Here GP2 would echo to GP3 what it received from GP1. If you stop the echo mechanism, then you stop this kind of use case. I you are scared about this your could add an OSC echo option for each widget, on existing gigs you could activate it, and on new gigs you deactivate it by default.
@dhj I would at least like the option to disable it. Also the ability to export the rack space minus the plugins would be nice as well. Like an “export rack space to remote machine” option would be a huge time saver. But if nothing else echo disable for 3.6.x
Not echoing would work better for me. Definitely wouldn’t break anything I’m doing.