Multi Instances - exchange Midi Msg

General discussion about Gig Performer
1

Due to the usage of CPU hungry plugins (Softtube Minimoog / B-3X) I get more and more performance issues on my 4 year old Mac (quad core / 16 GB).

Therefore i started to test a Multi Instance Setup with one instance for the MiniMoog / Piano and one for the B-3X. First tests are positiv and i think this is the way to go.

I like to control all plugins from the primary instance with Piano and MiniMoog and including the B-3X in the secondary instance. I have set-up an IAC bus to send Midi from the primary to the secondary instance. Works as expected. I have also setup a Widget to control the Leslie Speed in the primary instance sending a Midi msg (CC 111) to the secondary / B-3X. Works as expected. So far so good.

I have not found a way to feedback the Leslie Status from the B-3X back to the Widget in the primary instance. Is there a way to enable the loopback of the Leslie Status to the Widget in the primary instance?

I had a similar setup using a combination of Local (Piano / MiniMoog) and Global Rackspace (B-3X). I used the available parameters between the Local and Global Rackspace to control the B-3X. It would be great to have a similar parameter exchange between different Instances.

May be there is a way to enable the Midi Msg exchange via Rig Mgr setup or OSC or define the secondary instance as Midi HW and enable HW Sync ???

2

When you control via the Widget, why do you need the feedback?

3

When i load an other rackspace via program change the secondary instance with the B-3X may also change and the B3-X set-up as well incl the Leslie.

It may also happen that you change something in the secondary instance and i would see these changes reflected within the the primary instance

4

I like to treat the secondary instance / B-3X like a stand-alone instrument. As far as i know a real Hammond or Nord organ would feedback their status of to GP.

5

There is no simple solution, you will need GP script.

6

That was my worry and fear :unamused: Looks like i need to start a scripting project.

May be the GP developer pick this up as a request to support Multi Instance use cases. A similar approach like used with the Global Rackspace would be a good starting point.

7

We may try to make this kind of thing easier at some point but the whole point of GP Script is to allow users to do things now that are not built in.

From what you’re describing, it’s probably the case that a simple GP Script that responds to OSC messages will let you do exactly what you need.

8

Lets keep the fingers crossed for future GP features…

… and for now it looks like that i need to improve my script skills and to start learning OSC… mmm looks like a bigger project

9

You’ll find it’s really not that hard — probably won’t need more than 10-20 lines of GP Script since there’s already built-in support for OSC

10

I just reviewed your original message again. I’m not sure you need GP Script at all for this.

If you configure OSC to use different ports on each instance, you should be able to have widgets communicate directly with each other.

Look at the following - here are the options dialogs for OSC for the main instance (left) and a new instance (right) Note that the listening port on each instance matches the remote port of the other

screenshot_6278
screenshot_62781409Ă—702 91.6 KB

Next, I dropped a widget on each instance (a blue on the left and a green on the right) and gave them both the same OSC name Remote1 Make sure that you also click the Enable OSC on both

screenshot_6280
screenshot_62801920Ă—785 102 KB

Now you can see in the animated gif below that moving either widget moves the other one which, as far as I can tell, is exactly what you needed.

2022-09-27 20-41-38.2022-09-27 20_42_35

2 Likes
11

Thanks a lot … that’s exactly what i`ve looked for and what’s needed.

As I have not used OSC before i may need a bit time to get used to it.

Again, thanks for all the valuable feedback and support. Great forum!

12

hmm, somebody reported they got an infinite loop when they tried this. Let us know if it works for you

13

will do … but i may take some time

14

I have done a first test – so far no problems!

I have tested a drawbar, a volume knob and a switch. All are working without any problems.
Only negative point is that the display of widget values is not working: eg the volume db or the fast / slow status of the speed switch are not displayed in the widget caption.

I have not seen any hints for infinity loops. Processing / CPU load is as expected. Is there a special tool to monitor OSC loops like with midi?

More tests next week but first impression is that together with Blue Cat’s Connector it works as required and delivers the required solution to manage the CPU load.

15

Update related the infinity loops:

I had a few occasions with “something” like a loop.

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.