I think it is a proposal from @keyman, you could you OSC for this. Or perhaps he first would like to know how you operate your remote control ? I would like to know too… OSC ?
Lol @David-san. Ok I’m not using OSC. I’m using rtp midi to have the FOH pc talk to the MAIN pc on stage which also runs the stage monitoring console. The reason I did this is because visually the rack space on the FOH machine looks wayyyy better than the osc stuff and also anything I add on the main machine widgets etc, I can add on the FOH machine. I have also linked my 3 instances together to sub mixes and busses directly on the main machine. So I have access to audio from any instance in every other instance. I’m thinking about doing a write up on how I do it as this honestly gives me an incredible mixing console and vst machine all in one.
OSC is also interesting, if you give the same OSC name to two widgets in two different GP instances linked by OSC. This way any change in the first instance will be notified by GP to the second instance using OSC. This makes it possible to use an instance of GP for controlling a second instance of GP remotely without additional external services.
If you try to use levels from the GP audio blocks with anything else than a GP meter Widget, I think it will be difficult…
I do this via OSC using the meter infos from my RME audio interface. Which level would you like to display ? Where do they come from ?
Ok I’ll try using the OSC. What confused me was the client ip etc… give me a quick tutorial on what to do and I’ll try it out
Have a look at the OSC introduction video I give somewhere in this topic:
I got the osc to work from Gigperformer to Gigperformer across the network but I thought it was bidirectional or am I mistaken? If I have one machine listening it works fine for the fader or any widget but when I have it to go both ways I guess it goes into a feedback loop and the fader goes crazy. Any thoughts/ help ?
Hmmm, that sounds like a very obscure bug — sending OSC messages from one GP instance to another was not something we considered in the original design. Right now, when a widget receives an OSC message, it echoes it back - it may be that we shouldn’t do that. I’ll put this in our tracking system. Thanks for the report
@dhj same thing happens if I used midi as well. Honestly I know you guys intention for the program may have been of course gig/ musician oriented but honestly paired with asiolinkpro you can build a insanely powerful FOH and Monitor console
You shouldn’t be getting midi echo unless you have sync enabled
IKR… I do have loop midi installed though I’m not using it I’ll try to uninstall … oh one more thing I should do is update GP on the remote machine it’s running 3.5 while the main is running 3.6 not sure if that would make a difference
If you have loop MIDI installed and you have any Midi In OMNI Blocks in your system, you will get MIDI feedback
Roger that will update you on progress tomorrow. Thanks @dhj. Also do VU meters work via OSC ?
Yes it doesn’t work well bidirectional, so when I want to do so, I don’t use the built-in GP OSC messages, I use GP script to deal with sync issues…
@David-san do you mind giving an example of your case ?
There’s a fundamental question here – traditionally, when we receive an OSC message for a widget, we send it out again – it may be that we should never do that. Question: if we change the behavior so that we no longer echo OSC messages, will we break any existing uses?
How did you solve that issue in Midi Sync?
I had such issue with my M4L Patch and I could solve it (thx to @dhj) with a timout object in M4L.
The solution was not to send out Message as long messages come in.
I can send you the M4L Patch, maybe this idea is useful.
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.
@pianopaul I would appreciate that very much
That’s what I ended up doing until a solution can be found. Any thoughts on the VU meter though ?