Managing 2 instances with 1 controller

Hi all,

I’m trying to control 2 instances (Program Changes and plug-in parameters) with only one physical controller (Behringer Xtouch mini).
I’m running GP 4.1.5 and have 2 keyboards : one Yamaha CP4 for pianos, EP, clav, strings… and one Viscount Legend Solo for organ and synths
I’ve found the benefit of running 2 instances to use 2 cores instead of only one instance. It works well and I would like to continue this way for my setup.

Now I would like to change program and sounds parameters with the Xtouch. No problem to do that for only one instance : sync, PC, CC, all is running absolutely fine.

Things are getting worse when I run the second instance. The Xtouch does not work when the second instance is launched. After reading some topics on the forum, I tried the LoopBe1 trick to transmit MIDI CC to the second instance. It works but sync is crashing the midi due to loop feedback. Moreover, PC are not received (CC but no PC in the Global MIDI Monitor). I can change sound parameters, but can’t change rackspaces with PC.
I also tried to fiddle with OSC… It works within the same instance but no MIDI CC are received on the second instance.

I’m out of ideas :frowning: … Your help would be very appreciated!!

Cheers,
JB

I think with OSC this would be very easy:

I think you could use Widgets in the 1st instance to control widgets in the 2nd instance.
So just map to your controller and give the widget in the 1st instance and in the 2nd instance the same OSC name
Set the OSC port in the instances so that OSC messages sent from the 1st instance are received by the 2nd instance.

This way you just map your physical controller to the Widgets in the 1st rackspace and via OSC you control the widgets in the 2nd rackspaces.

Sounds a little bit complicated but is is not

You can see how to use OSC and Widgets in this YouTube. video

1 Like

Thanks a lot I will check that and let you know.

Do you think it would be possible to sync the X-Touch with the second instance by doing this way?

With the widget approach it would be possible.
The trick is that the physical controller is only mapped to widgets in the 1st instance and widgets control other widgets in the 2nd instance via OSC.

2 Likes

Depends what you mean by ‘sync’. Do you mean feedback to X-Touch Mini’s LED’s for its buttons and encoders? If so, do you have some examples of your setup: do you want to have some buttons and encoders operating instance 1, and others operating on instance 2 - and both keeping widget values in sync with the X-Touch LED’s?

EDIT: I tried @pianopaul’s approach with my X-Touch Mini and it worked (of course!)

1 Like

@pianopaul you mean Instance instead of Rackspace isn’t it ?

@rank13 It’s exactly what I mean : some buttons and encoders assigned to Instance 1 (let’s say for X-Touch’s LAYER A) and some other for Instance 2 (for LAYER B). When I switch or change params on layers A/B, it should update LED status of buttons/encoders.

I will try to create a fake setup of 2 identical instances. Each instance will include 2 rackspaces in which : 2 pots (encoders 1 & 2) and 2 buttons (buttons directly below encoders 1 & 2).
Rackspaces will be switched with the two left buttons of bottom row on X-Touch.
Instance 1 should be controlled with LAYER A.
Instance 2 should be controlled with LAYER B.

Should I create widgets for Layer B in the Global Rackspace of Instance 1 ? How should I configure OSC params for these widgets to send messages to control Instance 2 ?

In this example GP sends out on port 8000 and receives on port 8001

So in your 2nd instance make sure the Gig Performer listening port must be 8000
Be careful not to set the port to 8001 for Remote client port in the 2nd instance:
This way you would create an OSC feedback loop!

SlaveOSC.gig (36.5 KB)
MasterOSC.gig (23.8 KB)

Thank you pianopaul, it works. I’m starting to understand the OSC philosophy.

In your example, it’s a master/slave configuration. Actually, it’s a kind of “simplex” communication. When I turn the knob in global rackspace in MasterOSC, it moves the SlaveOSC’s one.
I’d like to move MasterOSC’s knob from SlaveOSC.
Would it be possible to achieve this without making a feedback loop ?

Let me think…

I fear, currently it is not possible to avoid OSC feedback.

In fact, OSC and MIDI are working quite the same way. What didn’t work with LoopBe1 had no chance to work with OSC…
I experienced the same problem with LoopBe1. I succeeded in doing a master/slave configuration with 2 instances but no way to have a “full-duplex” communication between the 2 instances without causing LoopBe1 to crash (with loopback).

What I don’t understand is how the “sync” function is working in one instance. It’s also a kind of loopback isn’t it ? If I knew how it is implemented maybe I could try to do the same between two instances…

But finally, why the X-Touch mini can’t work in 2 instances at the same time ? It would be so much simpler :face_with_raised_eyebrow:

I am using Ableton Live together with Gig Performer and they are synced by a M4L patch.
There was also the issue with feedback loops and I avoided them in putting in a gate function in the M4L patch.
I think the developer implemented similar in GP dealing with MIDI.

I am working on a script based OSC sync to avoid OSC loops.

Stay tuned…

1 Like

I need to revisit the OSC subsystem so as get rid of these potential loops

1 Like

After reading here and there on several forums, a possible approach would be that the controlled knob doesn’t echoe the MIDI/OSC message to avoid loopbacks.
Maybe it could also work with some kind of interrupts/flags : when instance 1 send a message, a flag is raised which allows instance 2 to receives and update the knob status but prevents to send back the message to instance 1 since the flag is still raised. Flag is reset after a few ms. Same trick for instance 2 to instance 1. This would be a kind of “half-duplex” communication.

I don’t know if it is possible to implement such a scriptlet for MIDI/OSC messages…

It is not that easy as instance 2 knows nothing about flags set in instance 1

If you manage things in GP Script you could send a specific flag message before the widget value messages.

The issue is: When to clear this flag?
I think I found a solution, can you please verify?

Slave.gig (24.4 KB)
Master.gig (24.2 KB)

You mean, apart from switching to a Mac? :wink:

Bomes Midi Translator could be another option. It creates virtual ports and you can easily route the X-Touch Mini messages to these virtual ports (and also route back the other way). I tested this and could get bi-directional sync working between the widgets and the X-Touch Mini in both instances.

All I needed to do in Bomes was draw connections between the ports to allow bi-directional comms.

1 Like

Hmmm… Master controls Slave but still unable to control Master from Slave.
OSC is enabled for each knob in instances

Here is the OSC setup :

Made some additionnal fiddling… And it seems to work !!!

Here is the setup :

Don’t know why it works with 8000 and 8003 ports :thinking:

Hi guys,

I’m diving into OSC linking on the 2 instances.
I’ve duplicated the layer B layout of my X-touch controller in the global rackspaces of both instances.
Layer A is for controlling Instance 1, layer B for instance 2.
It works like a charm.

I would like to select rackspaces in the Instance 2 from the buttons in the global rackspace (which are linked with instance 1’s global rackspace). Is it possible for a widget in global rackspace to send a Program Change ?