Show/Hide Collection of Widgets

[dlwhite66]

I’m using some Neural DSP plugins like the Mesa Boogie. It has two flavors of the amp and the VST3 automatically switches. The controls for each amp are identical, but they are unique (e.g. Gain amp 1 and Gain amp 2).

To save space AND make clear which amp is active, I’d like to hide Amp 1 widgets when Amp 2 is on and vice versa.

This would be relatively easy to highly automate a script if I could get a list of GPScript-Names for all widgets on a Panel (or even in a Rack). That way, I could append the set the GPScript Name such as “Gain.Amp1” and “Treble.Amp1”

Ideally I’d program something like:
VAR myWidgetArray : String Array = GetRackspaceWidgetList(Rackspace[GetCurrentRackspaceIndex()]) Returns String Array

This would return a list of Widgets that have a GPScript Name value set to non-null. Ideally the array would be indexed by the Z-Order (top to bottom).
myWidgetArray[1] = Gain.Amp1
myWidgetArray[2] = Gain.Amp2

Now I can identify all of the widgets assigned to Amp1 and set their show/hide value based on an event such as the widget switch the choses which amp to make active.

Even better would be if there were script objects for Panel. Panels as a script object would be similar RackSpaces, they would have have an ID, InRackspace, Name, and Order)

Then a new “Container” level is added that acts like a “Group” in other UX worlds (except in GP Group means "control multiple widgets at the same time). You create Containers by selecting multiple widgets. Container would have the unique ID GPScript Name and get/set parameters: Lock and Hide. Then a script could easily show/hide a group of widgets

Today, it appears that I would have to manually keep track of all widget Script Names and modify my scripts everytime I want to add/remove a widget to my list.

Anyone tried to dynamically show/hide groups of widgets?

[rank13]

As far as I’m aware, you will need to manually list the widgets in the script. But you can list them in a widget array, so after adding them as a Var, the rest of your script can dynamically iterate/reference them - so maintenance is low.

The ability to hide a panel (in UI and scripting) would be a welcome new feature.

[dlwhite66]

@rank13 yep, did that. It’s just a lot of tedious work to do so for tens (ultimately 100s) of widgets.

Also, it turns that that GPScript Name can’t use special characters so you can’t parse by a delimiter. So you have to pick a truly unique script name pre/suffix if you could automate it anyway.

[dhj]

GP Script just wasn’t designed to be a GUI tool and certainly not for dynamic GUI control and although we’ve thrown a few adhoc GUI functions into it to help with some simple tasks, what you are asking for is (currently) far more complicated to easily achieve.

For example, given that GP is intended for real-time performance, we were far more interested in making sure that if you set (or automate over time) a widget value, it must happen as fast as possible. That is why there exists widget “types” and declarations rather than (what other products do) looking up a widget by name every time one tries to change its value. Widget variables in GPScript are bound at a very low level directly to the underlying implementation so you’re getting close to native response speeds. That is why widgets are not defined as strings.

Another factor (and a secondary reason for the requirement for widget handles) is that one generally doesn’t want to have to pass every single widget change through GP Script. You might have 50 widgets but only three of them need to be handled by GP Script. We don’t want to generate thousands of unnecessary callbacks or even just tests when you’re just controlling a widget from your hardware (say) to adjust the filter while you play a solo. That is why, for example, we don’t just have some kind of auto population of handles.

Now I can certainly imagine adding some mechanisms to get a list of widgets by something separate from handles that could be used for non-real-time usage, like showing/hiding widgets or moving them around the screen and so forth but unfortunately it’s not something we can promise soon.

[dlwhite66]

@dhj I appreciate the feedback, and can’t argue with the priorities. And I agree that automatically adding a handle for every widget isn’t the way to go.

But I see more and more folks using this (including me) as a way to use many VSTs live and having some dynamic views of widgets and contain/group widgets for visual display and lock/unlock would add some power.

Appreciate the consideration.

[jdent02]

What I ended up doing for the Mark IIC plugin (and the Morgan suite and the S-Zero from Bogren) is change the widget assignment dynamically using “MapWidgetToPlugin”.

So for instance:

On WidgetValueChanged(w : Widget, index: integer, newValue : double) from MorganChan1, MorganChan2, MorganChan3
select
index == 0 do
MapWidgetToPlugin(MorganKnob1, MorganAmp, 30)
MapWidgetToPlugin(MorganKnob2, MorganAmp, 31)
MapWidgetToPlugin(MorganKnob3, MorganAmp, 32)
MapWidgetToPlugin(MorganSwitch1, MorganAmp, 34)
MapWidgetToPlugin(MorganSwitch2, MorganAmp, 33)
SetWidgetHideOnPresentation(MorganKnob1, False)
SetWidgetHideOnPresentation(MorganKnob2, False)
SetWidgetHideOnPresentation(MorganKnob3, False)
SetWidgetHideOnPresentation(MorganKnob4, True)
SetWidgetHideOnPresentation(MorganKnob5, True)
SetWidgetHideOnPresentation(MorganKnob6, True)
SetWidgetHideOnPresentation(MorganSwitch1, False)
SetWidgetHideOnPresentation(MorganSwitch2, False)
MapWidgetToPlugin(EQOn, MorganAmp, 71)
MapWidgetToPlugin(EQ1, MorganAmp, 72)
MapWidgetToPlugin(EQ2, MorganAmp, 73)
MapWidgetToPlugin(EQ3, MorganAmp, 74)
MapWidgetToPlugin(EQ4, MorganAmp, 75)
MapWidgetToPlugin(EQ5, MorganAmp, 76)
MapWidgetToPlugin(EQ6, MorganAmp, 77)
MapWidgetToPlugin(EQ7, MorganAmp, 78)
MapWidgetToPlugin(EQ8, MorganAmp, 79)
MapWidgetToPlugin(EQ9, MorganAmp, 80)

Looks at which amp is selected by a radio group linked set of three buttons, assigns the parameters as needed, and hides/reveals widgets as needed. I found this to be a MUCH cleaner way than hiding or revealing widgets that are on top of each other. So far the only real issue I’ve run across is that changing the amp channels through rack variations can cause some screwiness with the widget values mapping properly (although it’s only happened once).

It’s still a very manual process and a bit of a PITA, but it gives me a nice. clean UI.

[dlwhite66]

I thought about trying this as well, but where are you getting the parameter number? Hopefully I don’t have to count the length of the plug-in parameters list for each one.

[dlwhite66]

I just found it… It’s in the PlugIn window at the top left (thanks Documentation!)

[edm11]

There’s also an option to show the mapping parameter numbers in Options > Display > Widgets.