Changing Audio Device

Hi Guys,

I updated the driver of my babyface today. For some reason that caused that it got a different hardware name in GP now.
So I changed the respective Midi in and out blocks to the “new” device, which made it work again. But only for the Midi blocks themself. All the Controller Widgets are not working anymore as they are still mapped to the old device name.

Is there a way to automatically change these too? When GP can change the Midi Device on the Input blocks for the whole Gig, why aren’t the respective widgets changed to the new midi device as well?

Doing this manually would mean to remap about 500 widgets in the whole gig file by hand. I don’t want to do that.

Please see the documentation about using the Rig Manager feature in gig Performer, designed explicitly to handle this kind of thing.

There’s also an article about this on our blog

https://gigperformer.com/the-rig-manager/

Thanks David,

that’s still quiet some work, but it will surely help in the future.

There’s an interesting tradeoff here. We didn’t want to have to require everyone to use the Rig Manager before they get started, that would be very onerous, particularly for new users just trying to get up to speed. So it’s optional and if you build a large number of rackspaces before you set up the Rig Manager, you can get bitten

However, you’ve given me an idea which is now on our feature list. We should create default rig manager names for devices as you insert them. That way, when you do need to make a change, the devices will already be defined.

2 Likes

@dhj this default thing is a very good idea.

Maybe I’m going a bit too far here, but what would have helped me is a way to substitute a certain traditionally learned Midi Controller with a later added Control of the Rig Manager. GP knows where I used a certain Midi CC, so the change I do in Rackspace 1 could be copied to all other Rackspaces automatically.
I don’t know how many people struggle with such a problem. Now it took me about 4h to make the changes manually, but I hope my project is more future proof now, which is good.

That works already. Suppose you have a knob sending CC 78 on “A-Pro Port3” (i.e., a MIDI device called A-Pro Port3)

In the widget properties, you see the physical association

Now you go to the Rig Manager and you create a control called Foobar…

screenshot_3393

… and have it learn that specific MIDI message

image

Now, if you save that, go back to the widget, enable Learn and turn the physical know, the widget properties will now display “Foobar”

But isn´t that just for one single widget? My idea was that there will be a popup message saying that this controller is used in “54” other widgets in this gig file as well. Do you want to apply the change to the others as well? Yes, No.
Simillar to the way it works when I change a Midi Input Device or Midi Output Device.

1 Like

I think too that such a functionality would be appreciated by a lot of users who could then ‘update’ their older gig-files for the use of Rig Manager quite easily.
Or maybe (because for every old gig-file you would only need it once) there could be a separate utility/tool to do such a ‘mass-change’ of widget assignments?

1 Like

For my understanding:

If you use the Rig Manager from the beginning, then there should be not issue.

Right?

As far as i know: Yes.
But there still seem to be a number of users who had built some quite extensive gig-files before there was a Rig Manager (or built them without using it, for unknown reasons)… for them it is a lot of work, crawling through 100+ rackspaces and re-assign every ‘hardwired’ widget to a Rig Manager based ‘virtual’ controller.

1 Like

I understand

So do we😉

2 Likes

I just tested this (on Windows) and all the widgets were re-assigned to the Rig Manager names automatically - no need to touch the widgets again to ‘activate’ the global names.
But there is also no popup message that asks you if you want to change all the widgets - it just ‘happens’.:sunglasses:

Interessting. On MacOS only the widget I edit is changed. But anyway this should be an option.