I am using a keyboard that sends way to much CC#11. Is there a GP function that I can use to reduce the number of CC#11 messages getting to my plugin?
note** I know I can block CC#11 from coming in using the midi filter, but that is not what I am trying to do.
You can MIDI learn a widget to CC#11, rescale the widget value and assign it to the CC#11 parameter of the MIDI in block feeding your plugin:
But if you can, rather use host automation within your plugin and rescale the widget the same way.
EDIT: perhaps I misunderstood. You only want to reduce the amount of CC#11 MIDI messages received?
I do this with several of my plugin parameters, change the max or min value in parameter scaling. David-san’s eg is how you’d do that but it does require a widget get’s involved. Works a treat though.
I use it on rotary encoders from my studiologic to change the range of an effect I am controlling, like reverb or drive, where if I had the value scale to max=100, it would be way too much or min=0 might be too little and I want the knob’s travel to feel right for a plugin.
This can be different for different rackspaces so that same controller, like your expression controller, could have full range mapped in a different rackspace if it was more appropriate.
Yes, I only want to reduce the number of CC#11 (Expression) received from my keyboard.
Your solution above only scales the value of the controller … which of course is not my problem at this time 
Are you talking about the rate at which CC11 values are being sent?
How are you generating them? Why is the rate at which they are being sent a problem?
OK, at this his point I think you have to explain more. Why is you controller sending CC#11? What is the effect of CC#11 on your plugin. Which CC#11 message would you filter out? (duplicates only, 1 out of x). It is possible to filter out some MIDI messages using GPScript, but we have to figure out if it makes sense and how to be sure we don’t suppress important ones.
I am using an Expression Pedal from Moog and sometimes it is sending lot of Expression Messages event when not moved.
In my usecase I am just filtering CC11 when not needed.
How are you doing this with GP?
In all rackspaces where I do not need CC11 I filter it out with the Midi Filter Plugin
Dhj and David-san, yes I am talking about the excessive inter-arrival time (dhj, since I know you took Queuing Theory at IBM). The problem becomes acute when I use my Roland FR-4X MIDI V-Accordion as an input to Omnisphere for example. The FR-4X sends CC#11 by using the bellows and will automatically send approx. 100-200 CC#11 messages per second! There is nothing I can do about the amount of MIDI data that is being sent from the FR-4X … and it is a known problem in the digital accordion world. So, the MIDI data must be thinned down to a reasonable amount on the GP end.
If a script could be developed within GP to do this and would allow the user to specify a thinning parameter EG: let’s say to thin at the rate of 20% of the actual inter-arrival rate … I personally know about 20 Roland V-Accordion players that would be indebted to you and would be serious candidates for GP.
On another note: I am starting to get dangerous with my neophyte GP prowess as I am delving into more advanced areas such as accepting the audio from my Quantum then applying compression within GP using Presswork and then sending the output back out to a Fireface 800 input. Did you realize that you created a monster in GP here? LOL! GP is truly an outstanding product … congratulations!!!
On another note: I have discovered an amazing plugin that GP users must try. It is called “Tantra” which is a Multi-Effect plugin by DS Audio … simply amazing and within bound. If you haven’t tried it, give it a shot
PianoPaul, as you can see by now, the problem is not to filter the CC#11 completely but to filter it sparingly.
OK, let me think 
Try this
CC11.gig (7.1 KB)
//$<AutoDeclare>
// DO NOT EDIT THIS SECTION MANUALLY
Var
MIN : MidiInBlock
Time : Integer
Interval : Integer
TimeNowV : Integer
//$</AutoDeclare>
on ControlChangeEvent(cc : ControlChangeMessage) matching 11 from MIN
TimeNowV = TimeNow()
if TimeNowV > Time+Interval then
SendNow(MIN, cc)
Time = TimeNowV
end
end
on Activate
Time = TimeNow()
Interval = 100
end
Initialization
Time = TimeNow()
Interval = 100
endPerfect solution from @pianopaul I think. I just added a knob to adjust the time interval in order to quickly figure out which interval is the best. It will probably be very close from the 100ms proposed by @pianopaul.
CC11_knob.gig (10.4 KB)
But I also think it is also interesting to answer this question:
Because filtering the CC#11 out using a GPScript also needs some CPU cycles to do the job. I don’t know if it is not better to let the plugin deal with the incoming CC#11 
Because the plugin crashes when it receives too much data.
Wow! All I can say is Wow! I can’t wait to try this script this evening Paul
That’s indeed a good reason. Did you give this feedback to the plugin developers?
Which plugin?
This sounds like your pedal has a dirty potentiometer. That can cause it to keep jumping in value.
I think those Moog pedals have a calibration knob on the side. If you exercise that knob back and forth, it might help to clean any corrosion that might have built up on it (I used to need to do that to mine occasionally). You might also want to try cleaning any pots with some Deoxit contact cleaner.
Anyway, it’s definitively not normal for it to be sending messages without be touched, so something is either broken, or dirty. Good luck.
Saving CPU cycle with Deoxit! 