I think the problem is when I use a software induced LFO, drawn out and it tries to send to the HAWK very quickly a series of numbers between 0-99, twice. One for CC 84 (param. select) and the other for CC 85 (value).
So it can get close to trying to digest 200 CC's in a fraction of a second.
My experience with other issues is it it can bog down.. I have seen it do so when I would have many notes going on and about 3 pairs of NRPN's being moved (using "MIDI OUT" plugin on FL).. eventually notes got skipped and the parameter changes started to fall on their faces.
when I use the same Ctrlr app to make a GUI for a Kawai K3 to wobble bass the filter, the K3 keeps up just fine.. but in it's case it is a steady flow of sysex msgs, rather than a pair of NRPN's or CC's.
It's like night and day between HAWK and K3.
The HAWK does ok at really slow LFO waveforms, but once it goes too fast, I watch the LED status try to show the "CC 21 ∗∗" msg, but it wont change numbers, just sits in a stupor.. unless you use a square wave, or clip the top to make a faux square wave so it can catch up at the flat spots of the waveforms.
Maybe if I change the Filter to use just the standard.. CC71, use it instead so it's only sending one CC change out and perhaps halve the data.
I did try out a VST instance of the GUI in Ableton Live 9 last nite and after a crash course in midi mapping, I quickly had Live using the GUI to translate standard CC's into paired CC's to change parameters.. I need to actually hook the HAWK up and listen/watch for results next..
I might have a VST plugin soon.. incomplete, but something to give a try on FL or Live.
~Blaine