Using Gigfiles with several USB Devices

Now I probably got a tricky one.
I would like to use one USB Audio Interface that is installed fixed in my Stagerig and I have a different one (actually it´s exactly the same) at home for programming and rehearsing. Because Windows identifies different USB devices as different hardware, even if they are the same type of device, all the controls I program are only working with the Audio Interface that was connected when I set the controller. So they either work at home or when I´m connected to the stage rig, which I just can´t carry with me all the time.

Does someone see a way to solve that? I prefer to do it that way also because of the redundancy it would provide.
Some way of keeping all the configured Midi Controllers set but changing the Interface globally would be awesome.


Before GP I was working with an iPad using two iConnectMidi2+ (one at home and one in the stage rig). There it was working great from this perspective because I could use each of the two iConnectMidi Interfaces and also my iPhone intead of the iPad for redundancy and everything was allways in sync.

I faced the same issue, but on Mac there is a solution.
In the Audio-Midi Setup I can define a virtual device which gets the signals from the different physical devices.
In GigPerformer I use this virtual device, problem solved.

I do not know if there is something similar in Windows.

Another solution could by:
Right click the Midi In Plugin and in the menu choose “Change Midi Input Device”
Then you will be asked if you want to replace the current Midi In only for the current Backspace or for the whole Gig.

Thanks a lot Paul! I see… a Mac can have it´s advantages. :wink:

The change function is actually great. I wasn´t aware that you can change the device globally that way.

I was also searching for something like a Midi Device Merger Tool for Windows but i wasn´t very lucky up to now. Maybe Tobias Erichsen can help me out here. He got a Tool that sounds promising.

The only mssing part when changing the Midi Interface seems to that the control source for the widgets seem to stay at the initial midi input device.

Ouch — that would be a bug! (sigh) Thanks for the report

So just for me to get an idea of the final idea of the function…

I have one main Midi Input block in all my rackspaces and 3 output blocks. These are allways there. My widgets control the 3 output blocks + VSTs. Do I understand correctly, that the idea behind the “change device” function is, that I can just change the device of the input and 3 output blocks in the first rackspace and GP changes the device in all rackspaces in a way that all my programmed functions including widget controls should still work?
That would be really nice and not too complex to handle before a gig.


Anyway I just found this: https://www.youtube.com/watch?v=_GkFvjPj36w
It would be worth a try, but I´m no sure if I want an additional virtual Midi driver in between and if it causes latency.

But maybe you planned to add like a Midi Merger block for Version 2 anyway. :wink:

Not sure I understand. If you have two (or more) MIDI inputs yiu can just connect them all to a single synth plugin (say) and all incoming MIDI events will be merged automatically. What are you trying to merge?

Change MIDI device function has the ability to change all devices in all your currently open rackspaces, but works for MIDI input (or output) blocks only.
It does not change the widgets. This is not really a bug, but rather a design decision at this time.

While we could have changed all the widgets as well to use the new device - it would work for one, and only one, situation where you have two identical MIDI devices, you are on Windows and the devices have different names. In all other situations it would not work.

Consider a situation where you would be using a different midi controller for some reason. The knobs, sliders and button on that controller would not match the old controller in any way and there is no way to automate the process because we cannot know which knob sends which CC message out.

Having said that - we do plan on introducing a solution for this in version 2.x :slight_smile: that should be elegant and work the way you want it.
Stay tuned!

I just got stuck yesterday with this particular challenge. I´m sure you guys thought about these real live problems allready, so I´m happy about everything that´s coming up.
Functionwise the software is allready awesome!!

To quote the Beatles, “it’s getting better all the time”

I know this is a question which is impossible to answer for a software developper. But do you have an approximate release date for version 2? :slight_smile:

We have an approximate date. But if we told you, we’d have to shoot you :slight_smile:

All I can say at this point is we’re going as fast as we can (without breaking stuff) and taking seriously all the feedback we have seen from users.

Answer accepted…