Best practice for managing multiple instances with shared setlists

General discussion about Gig Performer
1

Hi everyone,

I’m currently using two instances of Gig Performer on the same machine, each connected to a different keyboard controller:

• Instance 1 is for basic piano sounds (bottom keyboard)

• Instance 2 is for synth sounds (top keyboard)

These two instances are linked via OSC, and they share the same setlist for seamless patch changes.

Recently, I wanted to add extra synth layers to the bottom keyboard, so I created a third instance for those sounds. However, I ran into a limitation: I couldn’t link all three instances via OSC to share the same setlist — only two at a time seems possible.

As a workaround, I’m currently controlling the third instance using MIDI Program Change (PC) messages via a widget in Instance 1. This works, but now I’m wondering:

What is the best approach when using multiple (more than two) instances of Gig Performer that should respond in sync?

Should I stick with controlling extra instances via widgets and MIDI PC messages?

Or is there a way to link three (or more) instances via OSC and synchronize their setlists more elegantly?

Any insights or best practices would be much appreciated!

Thanks!

2

What IP address are you sending from and to?

3

instance 1
Remote client IP address: 192.168.178.245
Remote listening port: 54341

Gig Performer IP address: 192.168.178.245
Gig Performer listening port: 54344

instance 2
Remote client IP address: 192.168.178.245
Remote listening port: 54344

Gig Performer IP address: 192.168.178.245
Gig Performer listening port: 54341

4

Oh I see — the problem is that you can’t have multiple applications listening on the same port

5

Yes!

Just to clarify:

The reason I’m using multiple instances is to make optimal use of multiple processor cores.

It’s not strictly necessary — my CPU has enough power to handle everything on a single core — but I prefer to keep the overall CPU load as low as possible, especially for live performance reliability.

6

You chain them so that Instance 1 sends to Instance 2, Instance 2 receives from Instance 1 and sends to Instance 3. They all have to have unique ports, and in Instance 2 you need to make sure both of these options are selected (since it is the one that is both receiving and sending).

49 (01)
49 (01)571×151 7.66 KB

Instance 1 just needs to have the Send option enabled, and Instance 3 just the Receive option enabled (assuming you are making all your song changes from Instance 1).

chain

7

Whoaaa thank you! I’ll try this asap

8

This is awesome. So now I can use the GP Relayer plugin to send midi (Note on/off and sustain) data from instance 1 to a second and third instance, and also to send back audio to the Global rackspace in instance 1. And as long as I keep all the setlists up to date (add new songs to all instances and keep the song names identical) I can move through all setlists in sync.

This way I can spread the cpu load over multiple cores…
:folded_hands:

9

(Just for the sake of completeness, so no need to change anything if your current setup works for you)

It appears on Windows, GP opens the OSC listening port in a mode that makes it possible to have multiple listeners (in this case multiple GP instances) on the same port (in this example 9003). Here is the listing using netstat -anbo:

afbeelding

Because GP binds to address 0.0.0.0, you can use a local broadcast to address all instances in parallel:

afbeelding
afbeelding628×235 14.8 KB

Note the 127.255.255.255 (which is the broadcast address for 127.0.0.0/8) and also that the sending instance is not listening on the same port (9003), which would introduce a loop.

This way there is no chaining.

Please note:

  • As I said, this goes for Windows. Other OSes might work differently. I didn’t check that.
  • If you use another application that happens to listen on the same port, it will probably not open it in a reusable fashion, thus blocking the listeners from GP to open using that port.
10

Very interesting.
I’m not familiar with the 127.255.255.255 address, and haven’t seen that referenced before. I’ve always used 127.0.0.1 for local addresses, and that doesn’t work wtih multiple listeners on the same port while 127.255.255.255 does.

11

Every valid ip-address/netmask combination has its own broadcast address. It’s made up by the bits of the address ORed with XOR of the mask. This allows for directed broadcasts (if the router is configured to allow that), in contrast to general broadcasts using 255.255.255.255, which routers tend to ignore (luckily). 127.0.0.0/8 is a loopback network, so these directed broadcasts will never leave the local device.

12

I read this in the manual:

When you perform live, you might want your FoH engineer to have access to your controls, too. In cases when OSC applications are running on multiple devices (i.e. a tablet, a smartphone or another computer) and you want to use multiple devices onstage, there is a simple way to accomplish that: if you simply set three last digits of the OSC applications IP address to 255 (i.e. 192.168.0.255) then Broadcast Mode is activated. Broadcast Mode enables Gig Performer to send OSC messages and communicate simultaneously with all listening clients on the specified port (i.e. 4252) on the same local network. Click here to access our Knowledge Base article with more information.

But I’m not ready to completely understand this :slight_smile: does this also work for multiple instances on the same device?

I guess the chaining method is working fine, and I’m on macOS…

13

Ah, I think I start to understand you, Frank1119! But I didn’t mention that I’m also using TouchOSC on my phone (connected via my offline router I bring to shows) to start the intro tune from backstage…

So I think I can’t use the 127.255.255.255 …?

14

Indeed, you can’t use 127.255.255.255 if you want to reach connected devices (because 127.0.0.0/8 is the local loopback). You need to use the broadcast address of the network between the devices. All the devices need to use the same subnet, (otherwise you have to depend on the router in between being capable of doing directed broadcasts).

Let us say your ip address is 192.168.1.23. The mask is 255.255.255.0 (/24). The broadcast address will be 192.168.1.255.

Another example:

Address 172.16.3.55. Mask 255.255.0.0. Broadcast address 172.16.255.255

Yet another less obvious:
Address 192.168.0.23. Mask 255.255.254.0
Broadcast address 192.168.1.255

And if you’re lazy (as you should be :grinning:):

(If you need the explanation in Dutch I can do that)

15

127.255.255.255 addresses only listeners on the same device, so yes it works for multiple instances on the same device.

Some OSes have different implementations for the address/port reuse options, so I can’t guarantee it also works on macOS.
It is also possible that GP on macOS opens the listening sockets in a different way. I can’t check that, because I don’t have a license for GP on mac. But you can easily check that yourself: have 2 instances of GP using the same listening port, start these instances and then in a terminal issue netstat -an|grep <port-number>. You should see the same port two times (see my screenshot above).

16

Frank,

I am having a similar issue on Mac and my post is : Syncing Setlists in Multiple Instances of GP with OSC on Mac

I’m trying to get a 3 instance configuration… Daisy chain works fine now, but I just can’t figure out how to get broadcast to multiple instances to work. The 3rd complains that the port is already in use.
How would you configure both the broadcaster and the receivers?