I have set up 2 GP instances (Main and Organ) to distribute the load to different CPU cores on my Mac. Solar no problems and also OSC is working as required to link the widgets between the to instances. see link
I have now tried to setup a 3rd instance to cover the piano. Setup of the piano instance is no problem except for OSC. I’ve tried to enable OSC on the 3rd instance but get always an error msg
OSC Listening Failure: port number 54341
Gig Performer could not open your selected port and will not be able to respond to OSC messages.
The most likely reason for this failure is because some other application (possibly even a second instance of Gig Performer) is already listening on that port.
Port 54341 is the port of the Main instance. My understanding is that different instances on one Mac use all the same IP address (127.0.0.1) but different port numbers like
Main - 54341 / Organ - 54342 / Piano - 54343
I have also tested the “Broadcast” option with 127.0.0.255 for the Main Listening IP Adress. Thats is also not working: Spinning Mac colour wheel and GP stops to be responsive to any actions.
Any hints or experience with 3 instances and OSC on one Mac ??
I have attached the OSC options from the Main / Organ / Test3rdGP instance.
I have to be a bit more precise:
As you can see i have for the Test3rdGP the port number 54343. With this port number i can send OSC msg to the Main instance (port 54341). But the Main instance cannot send OSC Msg to the 3rd Instance. The Main instance is only sending OSC Msg to the Organ (port 54342).
I have tried to use for the Organ and the Test3rdGP instance the same port number (54342) but that is not working. And the broadcast is also not working.
No wonder that this is not working.
You can only define 1 port OSC messages should be sent.
But you can use scripting and GP script functions where you can define which IP address and port should be used to send OSC messages.
Curious why it’s important to have widget syncing between the instances?
On Mac you don’t have issues with using the same midi ports across instances, so you could midi learn the same controller/widget in each instance, if necessary.
And if you’re not using a midi controller, then using variation changes to keep things in sync.
Second
Related to the question from rank13 about syncing the widgets:
I have an old Mac and i try to distribute the CPU load across the available CPU cores. Basic idea was to setup a MAIN instance to mange and control the overall setup and use additional instances for Organ and Piano. Additional Instances should be used like a standalone instrument and should be controllable via the MAIN instance. Therefore i looked around and found OSC to link the MAIN instance with an additional instance. So far it worked for a pair of instances ( MAIN / Organ ).
Maybe there is a better way to link the instances. In the past i tried to avoid MIDI (as recommended by GigPerformer team and the Community) and used mainly widgets linked to an VST.
I’m right it is possible (as long as all instances are within the same Mac) to map a MAIN widget via MIDI to the VST of a second or third instance and also get changes from the second instance back to the MAIN widget (eg when you change a preset within the second instance) ???
Plan is to have different rackspaces with variations, eg: to have a B3-Rock and a B3-Gospel rackspace. The rackspaces may have different VST preset and different additional effects. The variations within a rackspace may have changes to the drawbar settings or the the on/off of effects or different amp drive …
Things could easily work in one direction from your Main instance, by using the widget ‘Direct Addressable OSC’ settings - which allow you to send specific widget values to specific instances.
But I’m not sure you can easily achieve full bi-directional sync, without hitting some OSC feedback issues.
I have tried the “Direct Addressable OSC” - works without problem but only in one direction.
And Yes: there are some problems when you link two widgets see link
When moving the expression pedal or a drawbar the widget did not follow correctly. The primary and secondary widget started to jump around for a few seconds but finally switched to a new value (not always the expected one). A bit like a spring witch needs a bit time to rest after you pushed it.
It happened only from time to time. Sometime it worked without problems. It also happened only to movable widget not to on/off switches.
Looks like there is no easy solution to combine 3 or more instances ?!?
Bidirectional with multiple instances - why needed:
– Multiple instances due to my old Mac
– Bidrectional sync due to the fact that i may change the secondary rackspace / Variation and would like to see the new widget values in my MAIN instance without having to change the MAIN rackspace / variation. Its also save to have a feedback in the MAIN rackspace if you incidental or intentionally change the widgets in the secondary instance.
So you have all widgets in you main instance, even if they just are a duplicate of widgets in the 2nd instance and do not have really a function in the 1st instance?
By the way: You can hide widgets in the 2nd instance, so no way to change the widget
I do something similar with 4 GP instances on my PC (for the same CPU reason) via TouchOSC on my ipad, which allows 5 OSC destinations. So switching a widget on one instance of GP syncs to the other 3 GP instances on their different ports numbers via TouchOSC. Hope I’ve understood…
I know the hide widget option (very useful). But for key widget like the Drawbars or the amp settings i would like to have the bidirectional sync.
If you have a fixed song list and perfect defined sound you may not need the bidirectional sync. But for the bloody amateur like me it’s helpful to learn and play around with the sound. I think it would be a useful option to have this as part of the base GP features to enable and support the jam aspect.
