The Perfect Widget

Okay, I’m really interested in perfect control of a plugin block parameter, but “The Perfect Widget” is a better hook. Also, this isn’t a feature request. I want to solve this with today’s features.

Here’s the use case… We have a parameter that we want to control differently in different variations, depending on the situation.

Case 1: Hardware. We have a pedal, knob or button. Classic use case.

Case 2: Variations. Now, we want to disable the hardware (but track the hardware state), and we want the control to have a specific, value. We want the value to be locked in and not get bumped or saved with an unintended value.

Case 3: Automation. This is similar to the hardware situation, but we follow a different MIDI message from a MIDI sequence. Best practice is likely to start with a default value, until the CC value takes over.

Of course, the hardware use case has the usual sub-cases of continuous rotary knobs vs, absolute value knobs, buttons with and without state indicators, etc.

To start, I expect to have three radio buttons, one for each use case. Next, I might have a widget for each case. One follows hardware, another is the variation widget, and the third is the automation default for each variation. Maybe I hide or lock them. I could add a fourth widget that is large and visible, and tracks the actual state of the parameter.

The final piece of the puzzle is a script that ties the desired widget, value, or MIDI message to the plugin block parameter, depending on the use case.

Is this approach sensible, or would you approach it differently?

All input is appreciated!

I am trying to understand but I am getting lost while reading.
Will try to read again later.
I read it like 3-4 times and I still don’t get it fully.

Let’s take it one case at a time please.
What about the hardware pedal?
What are you trying to do?

Let’s say I have a Song with one Rackspace. During part of the Song, I want a control (in my case, a drawbar) to jump to different settings as the Song Parts and Variations change.

This works perfectly. However, if the Widget is controlled by hardware and I bump the control, or if the controller has noise and believes that the hardware was bumped, it might send a CC message and make the drawbar jump. So during these variations, I do not want the Widget value to change, based on the hardware MIDI value changes.

During the bridge, I want to control the drawbars manually. I want to be able to pre-adjust the drawbars to the initial setting before the bridge, and the Widget should ignore it.

When the bridge starts, the drawbar widgets should jump to match the hardware. Variations should now be ignored. The Widget should 100% follow the hardware.

During the final part of the song, I want the Widget to be smoothly automated from a MIDI sequence. Now it should ignore the hardware port as well as the variations, and it should follow the automation port. This is a bit simpler, because it is deterministic. With automation, I don’t need to worry about noise or bumping knobs.

I have a solution that works, but it’s messy. After I refine it, I hope to share it.

wow now i see.
interesting setup there.
the way i would approach this if i wanted to have control of the widgets from the hardware sometimes, but other times i just want to the widgets to follow the value set by the song part,
i would try to use the power of the midi in blocks or a midi filter which i can bypass.

the idea would be to filter out ccs when i don’t want hardware control and let it pass through when i do want it - same with automation.
unless somehow this would not work - i imagine it would.
i would be interested to see your solution once you refine it like you said.

There’s an additional requirement. The system should remember the state of the hardware and jump to that state; otherwise, we have to move the controls to wake it up, and there could be undesirable jumps.

I might pre-position the organ controls to, say, a Jimmy Smith setting, and I want the widgets to jump to those settings when it’s time for the hardware to take over.

Also note that knobs (with possible noise) might be handled differently than buttons.

that’s nice - how do we read the control values of the hardware if we don’t move them.
i know this type of sorcery is possible via touchOSC.
can the hardware somehow send that? like maybe a sequence?
or can GP request the values from it?
i am interested in this concept - syncing with the hardware, but i didn’t know how to do it with GP.

There is a “Follow Hardware” feature for Widgets. You have to touch the controls once, after Gig Performer starts, but it then tracks the hardware globally, even when different Rackspaces are active.

Of course, this situation applies to absolute controls like expression pedals, knobs with fixed limits, and toggle switches. For motorized faders, buttons with LEDs, and rotary knobs without limits, Gig Performer can send a value to the hardware to sync it.

My solution takes a lot of Panel space, but I don’t look at the Panels during performing. I just use them during development.

One set of Widgets is connected to the plugin parameters. It tells me the state of the plugin. It’s not connected to any MIDI controls. These Widgets ignore Variations.

Another set of Widgets is controlled by the hardware, using Follow Hardware. These ignore Variations.

Another set of Widgets follows Variations.

I then have Button Widgets to specify whether I want to follow the Variations, follow the hardware, etc. A Rackspace Script reacts to variation changes, monitors the switches, sets the appropriate values, and connects or disconnects certain Widgets to the plugin parameters.

It’s very powerful, and makes everything deterministic. I can control everything exactly how I want with no surprises. The only negative for me is that it’s heavy on panel space. Ideally, we would have a “Super Widget” that could handle all of this simply, but that would be no easy task. The bottom line is that I’ve got a design pattern that does everything I need with today’s Widgets. It’s Panel-heavy, but I can live with that.

Sounds superb. Can’t wait to see it when you optimize and share it.
Great thinking.

In the MIDI tab of the Widget Properties change the behavior to catch.

A solution for this use case could be to use a Scriptlet with Drawbar parameters and an Enable MIDI Output parameter which would send MIDI messages for each drawbar to the MIDI Local GP Port (for all drawbars at Enable MIDI Output parameter activation and then each time a drawbar is changed). Map your controller drawbars to hidden Drawbar Widgets ignoring Variations and following hardware and mapped to the Scriptlet drawbar parameters and also add a Widget Button mapped to the Enable MIDI Output Scriptlet parameter. The displayed Drawbar Widgets would be assigned to the MIDI Local GP Port messages sent by the Scriptlet and mapped to your plugin drawbar parameter. If the Widget Button is deactivated in a Variation you can change your drawbars without effect to the plugin and when you activate the Widget Button in another variation it would first sends all your drawbars values to the MIDI Local GP Port plugin and then each new drawbar change. If you deactivate the Widget Button, again you would be able to modify the drawbar without any changes to the plugin.

This could be done by sending MIDI values to the Local GP Port as would the Scriptlet also do.

Thanks, David-san,

I hadn’t considered using “catch” as a noise filter, I always thought of it more literally - that I would want hardware control, but only after moving the control a long way. That literal usage didn’t appeal to me, but the noise filtering can be very useful. I’ll reconsider the feature.

And yes, I have hardware controlled Widgets that follow hardware. Everything works as desired, but I might refine it for efficiency and maintainability. I like having as little as possible obscured, so I can come back to things years later and not be confused.

Regarding hiding the hardware Widgets, I haven’t done so. They are just on a lower panel that is off the screen. On an M1 Mac, would hiding the Widgets reduce resource usage? If there is value in hiding things, I’ll do it.

1 Like

Not at all, it is only for display purposes. And your solution is also good. Exactly what we did when there was no « hide » Widget option.