Keep volume or mute of certain plugins independent of variations?

I see.
Ok, now when you move the knob in the ‘Special’ rackspace, the knobs in the other 2 rackspaces move as well—that’s great.

However, when you switch to one of the other rackspaces and move the knob, it doesn’t change the knob in the Special rackspace. Furthermore, when you do switch back to the Special rackspace, the knob for the other rackspaces change back to the value in the Special rackspace.

However, when you switch to one of the other rackspaces and move the knob, it doesn’t change the knob in the Special rackspace. Furthermore, when you do switch back to the Special rackspace, the knob for the other rackspaces change back to the value in the Special rackspace.

Yes, this is an issue, maybe the developers can analyze.

1 Like

You are a genius! Thank you so much! This works beautifully for me! I can now switch patches and synth sound follows consistently. Much appreciated!

1 Like

Hi @pianopaul! Your script has been a blessing, thank you very much! I wanted to add 2 more widgets to my rackspace that behave the same way (following each others settings as per your script). However, I cannot get all of the buttons work the same way for some reason. Here is the script you wrote, where “A” was the master slider widget.

var A : Widget
EA : ExternalWidget

on Activate
if BindExternalWidget(EA, “A”, “Control”) then
A.SetWidgetValue(GetExternalWidgetValue(EA))
end
end

// Called when a widget value has changed
On WidgetValueChanged(newValue : double) from A
SetExternalWidgetValue(EA, newValue)
End

I wanted to add 2 push buttons. I named them “B” and “C”. I assumed I should do this:

var A : Widget
EA : ExternalWidget
B : Widget
EB : ExternalWidget
C : Widget
EC : ExternalWidget

on Activate
if BindExternalWidget(EA, “A”, “Control”) then
A.SetWidgetValue(GetExternalWidgetValue(EA))
end
if BindExternalWidget(EA, “B”, “Control”) then
B.SetWidgetValue(GetExternalWidgetValue(EB))
end
if BindExternalWidget(EA, “C”, “Control”) then
C.SetWidgetValue(GetExternalWidgetValue(EC))
end
end

// Called when a widget value has changed
On WidgetValueChanged(newValue : double) from A
SetExternalWidgetValue(EA, newValue)
End

On WidgetValueChanged(newValue : double) from B
SetExternalWidgetValue(EB, newValue)
End

On WidgetValueChanged(newValue : double) from C
SetExternalWidgetValue(EC, newValue)
End

The slider A still works but the buttons don’t want to follow. Again, the only difference is that the original A was a slider, the others are push switches, but I doubt that matters. Can you tell what’s wrong? Thanks much in advance!

A litte bit tricky, because of the timing.
Sync.gig (19.2 KB)

The On WidgetVaueChanged is fired before the on Acitvate.
Changed the script a little bit, new variable called va, vb and vc check if a widget value has been really changed.

var A : Widget
EA : ExternalWidget
B : Widget
EB : ExternalWidget
C : Widget
EC : ExternalWidget

va : double
vb : double
vc : double


initialization
 va = A.GetWidgetValue()
 vb = B.GetWidgetValue()
 vc = C.GetWidgetValue()
 end 

on Activate
 if BindExternalWidget(EA, "A", "Control") then
  A.SetWidgetValue(GetExternalWidgetValue(EA))
 end

 if BindExternalWidget(EB, "B", "Control") then
  Print("On Activate B")
  B.SetWidgetValue(GetExternalWidgetValue(EB))
 end

 if BindExternalWidget(EC, "C", "Control") then
  Print("On Activate C")    
  C.SetWidgetValue(GetExternalWidgetValue(EC))
 end
end

// Called when a widget value has changed
On WidgetValueChanged(newValue : double) from A
if newValue <> va then
 SetExternalWidgetValue(EA, newValue)
 va = newValue
end 
End

On WidgetValueChanged(newValue : double) from B
if newValue <> vb then
 SetExternalWidgetValue(EB, newValue)
 vb = newValue
end 
End

On WidgetValueChanged(newValue : double) from C
if newValue <> vc then
 SetExternalWidgetValue(EC, newValue)
 vc = newValue
end 
End

You have got a lot of typos in your GPScript, e.g. :

You bind EA rather then EB which is probably what you wanted… :wink:

1 Like

I corrected it in my newest script.
But because of the timing the new variables and the check against them seems to be necessary.

Good catch. It was 1 am, must have been very tired! LOL

Thanks! Seems to be working as per your gig file. Just to make things more complicated, I have the two buttons linked to the same widget and same parameter. It doesn’t work that way it seems. When I unlink them, seems to work fine. I have a foot controller and I want to be able to mute the sound of the synth, it is a latch pedal and I don’t have another available pedal to unmute it for live (trying to keep it minimalist) but I do have the volume controller on my Fishman TriplePlay that can override the mute. It gives me exactly what I want. Mute with pedal, quick temp unmute while I keep the pedal down and “permanent” unmute with the mounted controller. It stays unmuted/muted within the same patch (switching between variations is fine) but when I switch racks and they are both routed to the same plugin and parameter, it doesn’t follow.

I do not understand why you map 2 buttons to the same parameter.
Better do this:
Map button1 to the parameter.
Do not map button2

BUT: give both buttons the same group
https://gigperformer.com/docs/Userguide36/widgetpropertiesinspector.html

Unfortunately, that doesn’t give me the same behaviour. It doesn’t override the mute function of the mixer. Anyway, this is non issue b/c it turns out that’s not the problem. Your script DOES work even when both buttons are pointing to the same plugin and parameter. What was happening was that some of variations called for a program chance in the FTP controller and when FTP changed programs, it automatically sent it Volume CC#7 messages. It is the same controller that is attached to my guitar and I need those CC#7’s to go through when I manually am controlling it, I just don’t want it to happen upon every program chance and there seems to be no way of stopping the FTP from automatically sending them out. I can’t figure out a way no get those pesky CC# messaged filtered only for the instance of variation change (which sets off the PC in FTP) without it also filtering it out when I DO need it! Urgh… 1st world problems! LOL

Any CC Message mapped to a widget is filtered out.
In scripting you could send out CC Messages to a MIDI In plugin to push through the filter CC message.

So in a script you could filter out CC#7 ONLY when the variation change is occuring but not otherwise? That would work! Another way of looking at is how else can I stop the synth sound besides a volume change/mute. I can bypass the plugin that is generating the sound, that works beautifully and those CC#7 messages aren’t getting in the way, BUT since my volume control is now linked to the bypass, every time I go lower than about 50% of my volume, it triggers the bypass. I tried lowering the parameter scaling MAX value but it makes no difference when targeting the BYPASS of the plugin. Interestingly, this setting worked wonderfully when targeting the MUTE, but not for the BYPASS. I have to find another target that kills the sound but doesn’t kill it at 50%.

So far the NOTE ON allow/block seems to be best option! :slight_smile: Thank you so much for the new script!!!

UPDATE: Nevermind! The 50% problem went away with the NOTE on/off, but somehow the PC coming from the FTP is overriding the NOTE on/off midi filter.

I’m not sure if I understood you correctly, but if you meant that a script could temporarily filter out CC#7 messages during variation/patch change, otherwise NOT, that might be what I need… Is that possible?

Here is a sample gig.
sus_script.gig (10.8 KB)

2 rackspaces
the 1st rackspace contains a script to send CC64, because when CC64 is mapped to a widget no plugin gets this CC64.

the 2nd rackspace works without a script :wink:
it uses 2 widgets: the 1st widget is mapped to CC64 and with the use of the same group number the 2nd widget is sending CC64 to the Midi In.

In both solutions you can map CC64 to a widget and get CC64 for other plugins.

//$<AutoDeclare>
// DO NOT EDIT THIS SECTION MANUALLY
Var
   PEDAL : Widget
   vsus_on  : ControlChangeMessage
   vsus_off : ControlChangeMessage
   MIN : MidiInBlock
   
//$</AutoDeclare>

initialization
 vsus_on = MakeControlChangeMessageEx(64, 127, 1)
 vsus_off = MakeControlChangeMessageEx(64, 0, 1)
end 
  
// Called when a widget value has changed
On WidgetValueChanged(newValue : double) from PEDAL
 if newValue == 1.0 then
    SendNow(MIN, vsus_on)
 else
    SendNow(MIN, vsus_off)
 end
End
1 Like

Thank you Paul! I will try to wrap my brain around this one. Will I need to use 2 racks for every new rack, or can other racks be effected by this scripted rack as long as those widgets are identified in the scrip such as “PEDAL : Widget”?

Hi @ztones,

to clarify: I showed you possibilities to route a CC message to a plugin when this CC message is used in MIDI learn to a widget.
A learned CC message is filtered out and not sent to any plugin - because it is mapped to a widget.

In my sample gig there are 2 rackspaces to show you the alternative solutions.
the 1st rackspace uses a script and the the 2nd rackspaces uses widgets in the same widget group.
So when you need place on the panel and you dont like the 2nd widget, then scripting is the goal.

When you create a new rackspace and you do not face the issue with a “lost” CC messages because you do not really need it, except for MIDI learn => forget that example gig I uploaded :wink:

I’m trying to follow recommendations to group widgets instead of assigning two to the same plugin/parameter. However, the problem I am having is that I can only get a “switch” type operation instead of “knob” or incremental value based.

EXAMPLE: widget1 is assigned a mute button operation. I am triggering it with a foot switch. Widget 2 is supposed to override widget1 when I want to turn the mute off. (Can’t do it with the same pedal b/c its a latch type, but also b/c I want to keep it latching as that way I can get temporary quick shots of unmuting while I am pressing down on the switch. I want to preserve this functionality.) So widget2 is used to turn off the mute completely, not just temporarily. I want to link widget 2 to be triggered by my volume fader on my midi controller.

OPT1: When I have widget2 grouped to widget 1 (and not linked to any plugin), it does override it, but at 50% value it turns it back on. So it un-mutes the sound, I can adjust the synth volume, until it hits around 50%, then puts the mute back on. I have tried invert value, playing with all kind of different value settings etc, behavior is same/similar.

OPT2: When I have both widgets mapped to the same plugin and parameter, the widget2 behaves exactly how I want. With the inverted checked off, max val at 20%, I can adjust my volume all the way up and down to 20% before the MUTE it turned back on.

So OPT2 gives me the behavior I am looking for UNTIL I switch racks. The script @pianopaul so graciously provided for all widgets to follow each other’s values is broken. So, with OPT1, the script works, but the volume fader doesn’t. With OPT2, the fader works, but the script doesn’t…

@ztones that’s all starting to sound pretty complicated. Based on what you’re saying I think you’re best off not trying to get this to work with both standard widget functionality and custom scripts. If you do need the scripts for some part of what you want to achieve, then use scripting for everything.