I’m new to OSC and just started working with 2 instances communicating via OSC. I keep losing the listening port in the main gig file, which of course is the sending port in the 2nd instance. In this particular case, in my main instance, my sending port is 9000 and the listening port I have changed from 9001, 9002, 9003, 9500, to finally 15000 as per @edm11 's suggestion, because for him those high number ports have been stable. But in my case it seems no matter what I change it to, the listening port (currently 15000) stops working after a short while. If I reopen the gig file nothing happens, HOWEVER if I quit and reopen GP it starts working again. Every time. So is this a windows issue or GP issue? I no longer think its related to the actual number, rather something is “closing” the port, which becomes available again after restarting GP.
I’ve been editing the gig files, creating the OSC links between widgets, so I am not sure if this triggers something during the editing which may not occur during regular use, which I’ve seen with other strange issues from time to time. For example, the port numbers that come up as a default (before filling in the info) in the “direct addressable OSC” section are different from my actual port number.
Any ideas what could be causing the return part of the bi-directional OSC communication port to stop working after 30-60 minutes?
IMO Jumping right into OSC with this kind of complexity is not a good way to learn or to diagnose issues. There are too many variables in play right now without a proportional understanding of the basics.
I suggest starting slowly, with blank gigs in each instance. Add one thing at a time, get a handle on what is being assigned where. Also, download Protokol, and use it to diagnose whether a message is being sent or not, and exactly what is being sent. It’s an invaluable diagnostics tool for OSC and MIDI. Spend time with the GP documentation also.
Once you’ve a few simple connections made and are stable, then you can start to apply what you’ve learned to your actual gig files, and perhaps something will become clear as to why things aren’t working properly there.
Wise words! I just downloaded PROTOKOL. I added some widgets that send volume level or or other widget values over OSC. It seems a lot of messages are being sent even when these widgets are idle. They are knobs and none of them are being turned that sent messages.
I’m not sure I understand what you mean? I just setup OCS in both instances as the screenshot shows. I setup widgets to send out “SetValue” OSC messages. Protokol shows that apparently these messages are being sent out even when the value hasn’t changed. Is there a way to only send these messages on value change? Or if that’s what you meant by filtering out, how do I filter out unchanged messages? I spent extensive time in the manual…
The settings seem ok, although theoretically you could end up in a loop, because they can send messages to each other (and sometimes ‘theoretically’ becomes real).
The network card to which 192.168.0.186 is bound is that a Wifi network card? If GP binds explicitly to a network instead of binding to 0.0.0.0, then it might stop listening if the network card is (temporarily) not available, even when it is for a very short period. I’ll check if I can reverse engineer how GP does this.
With this setting you can get infinite OSC loop.
When a widget in the first instance send out via OSC the second instance gets an OSC message.
The corresponding widget is set to a value.
Now this widget sends back the value to the first instance.
The first instance now reacts on that incoming OSC message and again sends out an OSC message…
This happened when I wanted to start fresh, new empty gig, accidentally clicked on "
open file" then I hit cancel and got this popup. No second instance is open.
Hm… I thought this is how it had to be between main and second instance. So they should be on totally different ports and only use the other instances port number in the widget OSC settings? Or only the “return” ports different? Otherwise how does main send rackspace/song part change OSC if they are not on the same send (main) and receive (second instance) channel?
So for example:
Main send 9000
Main receive 15000
Second Inst send 1502
Second Inst receive 9000
???
And only use the main receive port of 15000 in the widgets OSC send box???
It is easy to control widgets in the second instance via widgets in the first instance.
The same in the opposite is not possible because of OSC loops.
What is your usecase?
Why the need to control widgets in the first instance via widgets in the second instance?
My use case is, I mix my analog guitar sound with synth sounds via midiguitar. In order to spread CPU usage, I put all my synth sounds in the second instance. In my main instance rackpaces I have bypass/unbypass widgets activating the synths I want (using the plugin bypass2 script as well as cutting off noteOn). As I mix my main guitar sound with synth sounds, I also need to tweak levels of the synths. Then the 3rd widget is sending PC messages to select different presets in the synths.
So can you give me an example of how the OSC ports should be setup for each instance send/receive for this? Can a widget send out an OSC message on port X if the sending port is other than X in the same instance?
I am. My widets in the main instance are setup to set the value of the widgets in the 2nd instance connected to the plugin. Are you saying just have a one way communication? That does work, but I thought if/when I’m ever adjusting anything in the 2nd instance I’d like it to reflect in the main instance. Is a 2 way communication not possible between 2 widgets in 2 instances without loopback? If it is, please give me an example. Thanks!
Can you reproduce that? I know of circumstances that GP does this, for example if you deactivated the license before updating Windows and after that when activating the license again. But it shouldn’t have any bearing on the original issue: OSC communications stopping.
Of course you need to re-enable OSC in settings.
I’ll try to reproduce… I didn’t deactivate anything, BUT I did recently upgrade to 5 and have both 4 and 5 on my system. Of course i have not started 4 since…
I just mentioned this as an example that in some not-common situations GP does show the ‘someone-is-already-listening’ message, so upgrading in the past has most likely nothing to do with your issue. If you can’t reproduce it, just leave it
