RFE: Accept list of input Operators

[drmbt]

It would be amazing if I could point UBERGui at a list of operators for input/output and assemble parameters from all of the containers into a single scollable UI. I've been trying to figure out the best way to assemble a paramInspector for both toxes and associated post effects, and I think this would be a beautiful solution

[EnviralDesign]

If I understand correctly you're saying that a way to generate a UI that shows parameters across a series of different operators instead of just the single source operator that currently builds the UI?

If so, I think that's a possibility with out re thinking a lot of the code completely. Right now when you specify 5 operators for instance, the first one is utilized as the "source" operator.

If they are say a collection of 3d objects, they all share Tx,Ty,Tz and already right now you can move parameters unique to the source operator and it will silently fail when trying to move those parameters on the other objects.|

---

I can envision one edge case that may not be desirable:

Say we have 2 params on two dif comps:

• Comp1.par.Brightness
• Comp2.par.Brightness

A) The easier way to address this RFE would make it so that UG only makes one parameter called "Brightness" and when adjusted it will change both of those parameters in tandem.

B) The slightly more challenging version of this RFE is if those two Brightness parameters should show up as unique sliders, because they belong to separate operators.

The parameter DAT does support prepending the par name with the operator name, which is handy.

However this will break the logic we have currently, where it tries to set a parameter on all target operators regardless of name, if the param exists.

Do you have any more insight on if your use case is A or B?

[drmbt]

Ideally case B... Unique sliders pushing changes to unique parameters of unique COMPs that happen to have parameters with the same names