Control Knob/Fader with Toggle Button

I’d like to have a toggle button increase the value of a knob/fader by x amount when the button is on and reduce the value when it’s off. I’m trying to create a boost function for my monitor mix on my X32 mixer and would like to have a preset boost function for certain channels for things like guitar solos where I can temporarily boost the mixer channel in my ears, then bring it back to where it was.

I haven’t done anything with scripting in GP yet, but am familiar with programming, so a point in the right direction would be appreciated.

I don’t see why you need a script for this.
Just group a knob and a switch together and set the scaling curve for the knob to define your min/max value. Then the toggle will cause the knob to send either the smaller or the larger value

(in the example here, the small value is 30% and the large value is about 62%)

2022-09-04 20-21-11.2022-09-04 20_21_19

1 Like

I was looking to use the script since the knob values will be changing and I need to boost the value based on the current value of the knob. For instance, if it is set to 60% I’d like to boost it by 5% to 65% when the switch is active, then back to 60% when the knob is off. But if the knob is 50% it would boost to 55% and back to 50%.

It seems the grouped widgets would just set the knob to 2 values if I’m understanding it correctly.

When the knob is at 100%, what should the switch do?

1 Like

And would it be OK if you’d manually (or accidentially) dial the knob to a lower value while the button is still ON, and then, after switching the button OFF, the knob would be set an additional 5% lower?

1 Like

I created a sample how to do this with scripting with gain and boost. When you touch the gain, boost will disengage and the gain will not suddenly jump.

Take a look to see if this is the kind of behavior you’re looking for

(Update: just uploaded a slightly better sample)
GainAndBoost.gig (37.3 KB)


@Frank1119 That is exactly what I’m looking for. I love the fact that it resets the switch when the knob is moved. That will be very helpful for when I make a manual adjustment to the knob. Thank you so much!

Is there a function to convert the knob values to db? If possible, I’d like to set the boost in db instead of a set number now that I think about it.

(Update) I found the specs on the X32 fader curve and some formulas to convert the OSC values from Integer to DB and vice versa. I need to read up on it, but it might make more sense to you guys in how I can adapt that to this situation.

The info is on page 128 of this document if anyone is interested in taking a look.

I am interested. Thanks.

1 Like

I’ve changed the gig to make it more in line with your X32. Also included the conversions. The boost switch adds 3 dB.

For fun I also researched the function between the linear value of a GP gain control and its displayed dB value. Probably @dhj will tell me that there is already a scaling function for doing just that :grinning:. Than I invented this wheel again…

GainAndBoost.gig (88.6 KB)

1 Like

Thank you so much! That is exactly the result I was hoping for. My only remaining function that I’m hoping to get working is sending an OSC command periodically to the X32 to keep it sending updates back to GP. I was able to do it in TouchOSC using the following script, but would need to get it working in the GP Script. Perhaps I could ask one more favor to make this a perfect solution?

Basically, the X32 needs the /xremote command sent every 9 seconds to keep the communication between it and the remote software so if something is changed directly on the X32 or via some other connection, it will (hopefully) update the widgets and my connected midi controller. I have verified this behavior when using my TouchOSC test setup, so I’m hoping GP responds in a similar fashion

–Begin TouchOSC script code–

local delay = 9000 – every 1000ms = 1s
local last = 0

function update()
local now = getMillis()
if(now - last > delay) then
last = now

That is really not very difficult. Tomorrow I’ll write a sample how to do timerbased stuff, unless someone else is faster than me.

1 Like

Thanks, I’m still getting familiar with GPScript’s syntax so a quick timer example would be awesome!

This simple example is a good starting point:

Here the gig with the heartbeat timer. I’ve implemented it in the global rack script, because I assume that you want it running regardless which rackspace is active. I’ve added a blink led so you have a visual clue when the heartbeat is being sent.

BTW: Maybe you’re new to programming/scripting, but gpscript is not that hard, so you may look into that. Main pitfall is (at least for me) using too much scripting. To paraphrase this: “To some with only a hammer, everything looks like a nail”: “To a programmer, every environment looks like an IDE :grinning:

So before scripting everything my advise is to always check if there is a neat way to accomplish things without scripting.

Have fun.

GainAndBoost.gig (102.2 KB)

Small bug in the above example: When you open the options dialog, the timers stop running. Added a fix in this one:
GainAndBoost.gig (102.2 KB)

The added fix to global rack script
UPDATE: (but it doesn’t fix it, sorry)

On TimerTick(ms : double)
// With this callback defined, timers are always running
// Fixes an issue timers not being re-enabled after opening 
// the options dialog

1 Like

Hm… the timers fix doesn’t work… :thinking: Apologies :bowing_man:.

This one fixes it at the cost of more complexity. On the global rackspace there is a hidden widget that helps solving it.

GainAndBoost_TimersFixed.gig (115.4 KB)

The timer is a little fast: every second instead of every 4.5 seconds, but you can adjust that in the global rackspace script.

Update: There is a somewhat better solution. I will upload that later.

1 Like

Let’s hope this is the last fix. I’m really getting annoyed with myself :flushed:

GainAndBoost_TimersFixed_Revisited.gig (103.2 KB)

In this gig I used the system actions plugin to catch rackspace activations. These also occur when the options dialog is closed. The System actions plugins also works in the global rackspace. The advantage is you can create rackspaces to hearts content without any extra coding for keeping the timers in the global rackspace running.

For the timers there is no dependence between the global rackspace and the other rackspace(s) anymore.

1 Like

Thanks for all the work. I wasn’t getting any response from the knob which is bound to the OSC command on the X32 send level when the heartbeat is run. OSC control of the X32 works when I adjust the knob but I’m not sure if the /xremote command is working like it does in TouchOSC where it should be sending the commands back to the knob.

I changed the SendHeartbeat command to an OSC_SendStringSpecific command to change the value of a fader on the X32 and that does fire with each heartbeat, so communication to the X32 via the function is working, but the X32 doesn’t seem to be updating the knob on GP.

I did have to use the Direct Addressable OSC option to be able to use multiple “/” characters for the OSC address of the widget, so I’m not sure if that affects this situation. For example, the X32 address for the send fader of a mix is /ch/17/mix/01/level which cannot be used in the OSC/GpScript Name.

I may try to adjust your code for the fader curve to TouchOSC as that seems to be communicating with the X32 better and the timer is less complicated. It might be better to keep all of this outside of GP anyway to avoid any possible issues with my plugins.

If you think of anything obvious, let me know. Thanks again for the time and effort, it has helped me get a better understanding of how GPScript works

Sorry it took some time, but sometimes there are other things in life :slight_smile:

As far as I know this is possible:

On OSCMessageReceived(m : OSCMessage) Matching "/bus1/Midi"
// BlaBla

And this is also possible:

OSC_SendStringSpecific("/this/is/possible", "hi_is_not_low", "", 7701)

About this:

You have configured the OSC settings?


I have it pointing to my own laptop, but when the X32 has its own ipaddress, then you could configre that, although using the “specific” versions is perfectly fine, especially when you have more that one remote client to address.

Sometimes it is handy to use a packet sniffer like Wireshark, although is has a learning curve:

Make sure you let the ip-address point to an address that is not local on your computer, else your wifi interface or ethernet interface will not be used and Wireshark ‘sees’ nothing.

When you do not use a filter (udp.port==7701), you see much, much more and when you’re into networking, sometimes interesting stuff…

Maybe this gives you some pointers to investigate/try

Thanks! I have the IP/port of the X32 saved in the OSC settings. I’ll mess around with WireShark as I’m familiar with it’s use. I have a working prototype in TouchOSC so I’ll probably focus on that for now but will report back if I can it working in GP. Just don’t want to get too far down this rabbit hole when there’s a lot of of other work to do to get things set up. Thanks again!

1 Like