Have been playing around with remapping a grid controller (like Linnstument, Seaboard, Morph etc.) to a 90 degrees turned minor third layout. (Am using this on Eigenharp and wanted to see how it “performs” on other grid based instruments).
edit: no resource leak - the Print that caused the slowdown is not present in the script I posted on KVR, so should work as is.
Script and description in this thread (on page 2):
Are you seeing this when you just use a script or are you compiling many times in that hour?
Initially I have compiled it several times, but in the second session perhaps 2, 3 times (essentially just commenting and uncommenting the entire script to switch back and forth from/to the unaltered mapping a few times.
The slowdown still happened. (Not so severe but I cannot say whether it was the same amount of time).
Easiest way to see the slowdown is to type something in the script editor. If in this state it takes several seconds until the typed characters become visible. Oddly they immediately appear when pressing one of the arrow keys.
The fan also starts to turn like crazy at some point, so some cores must be really busy with something…
When I stop GigPerformer the fans tune down after a few seconds.
Are you on Windows or Mac? How much RAM on your system? What is your script doing? What kind of callbacks? Are you using function generators? It might make more sense for you to submit a formal ticket in our system so we can track this one, it doesn’t sound like an instant fix. We’re going to need to be able to replicate the problem but with as small (and plugin/hardware independent) as possible script with which to test.
Did a third test and was first unable to reproduce this.
Then I tried to remember what the last thing was that I changed. It was removing a Print statement from the OnPitch function. And indeed, that was the problem: When opening the Script Log I see now that when playing fast there are so many messages that the log takes minutes to catch up. And in this time I can reproduce the behavior with the slowdown of the rest of the system.
Sorry, didn’t have this on the radar as the log window was closed…
Was testing on a MacBook Pro 15" 2014 with 16 GB RAM. With the additional info that the Print statement was the cause of the problem it’s easy to reproduce: Just create a OnPitch function, let it print the current pitch and pitchblend like crazy for a minute or so. Then you should be in the state.
Not sure whether this is really a “bug” - the printing only appears to slow down low priority stuff like the UI. The best counter measure is probably not to overuse Print…
From my perspective you can consider this closed.
Ah – that makes sense — Print is intended for debugging - should never be used in actual real-time application. If you generate a ton of Print statements (as would be expected if you have large numbers of Pitch messages arriving), I’d expect a temporary slowdown while the GUI is handling all those messages. There’s also a ton of string handling that has to be processed as well. But once they’ve all been handled, things should get back to normal again. I’d be interested to know if that’s what you’re seeing and I’d also be interested to know if Activity Monitor indicates that more and more RAM is being used — that would suggest a problem. Appreciate your help tracking this down.
Yes, I have tested this script with my Linnstrument and seems to work nicely.
Great to you see you around here 
@NothanUmber, more so with creative scripts !!
Sorry for the late reply. Retried the script and couldn’t notice memory increase when just playing. Recompiling semms to increase memory slightly. But perhaps it’s just caching some stuff, doesn’t look unhealthy.
So as long as I don’t forget to remove debug stuff (…) it seems to work well so far.
It would not surprise me if there’s a little leaking every time you recompile, I’ll take a look at some point.
Hi, I use a seaboard in Ablet Live and use the included MPE Control to modify the pitchbend so the Kontakt patches only respond to 12 semitones and the Seaboard sends 48 semitones. The MPE Control has a setting for 2x 4x 8x the pbend. I use x4 12x4 48 and works very well. I can’t automate changing the seaboard itself to 12 sem from patch to patch so maybe you know how to script that in Gig Performer. Thanks and sorry to bother with this. Sorry my english is not good
Hi, my understanding is that you have a Seaboard set up to always send +/- 48 semitones pitch bend events.
And you have some rackspaces with Kontakt instances that expect +/- 12 semitones pitch bend range (and others that want +/- 48 semitones, thus you don’t want to change the setting on the seaboard).
My guess is that you could also set up Kontakt to use +/- 48 semitones - the loss of precision has already happened anyways. But you can also do that with a script (which can easily be derived from the script linked in the original posting).
var
midiin : MidiInBlock
On PitchBendEvent(m : PitchBendMessage) from midiin
var
pitchbendNumber : Integer
newPitchBendNumber : Integer
newPitchBendMessage : PitchBendMessage
channel : Integer
channel = GetChannel(m)
pitchbendNumber = GetPitchBendValue(m)
newPitchBendNumber = (pitchbendNumber - 8192) * 4 + 8192
if newPitchBendNumber > 16383 then newPitchBendNumber = 16383 end
if newPitchBendNumber < 0 then newPitchBendNumber = 0 end
newPitchBendMessage = MakePitchBendMessageEx(newPitchBendNumber, channel)
SendNow(midiin, newPitchBendMessage)
End
Great Sir!! Thanks, Im gonna try that and let you know!! But I dont know if that can be made in Kontakt, at least I dont know.
Ok, Google says that pitch bend in Kontakt is indeed limited to +/- 12 semitones. Looks like a case of “+/- 1 octave ought to be enough for anybody!” 
Yes!! It works great. I have to resolve a problem with some Kontakt patches that produce garbled pitchbend but with basics programs works as intended. I know Im gonna make it work for all of them. Thanks a lot man!!!
Sounds good!
My guess is that either the pitch bend data range is too high (so you could try to decimate the events like described in section “Slow down the MIDI data rate over USB to reduce synth overload” here.
Or that you are sending pitch bend events on several channels (with Linnstrument in MPE mode) and Kontakt is set up to map everything to channel 1, so your pitch bend values jump. To see whether that is the problem you can set Linnstrument to single channel mode and see whether it’s gone then.
As far as I can tell, Kontakt only allows a min/max range of 12 semitones.
I see what you did with your script but I’m wondering why a script is necessary?
First of all, you can assign host automation values to the UP and DOWN Pitch Bend values in Kontakt so why could you not just use a couple of widgets mapped to those parameters and set them as needed?
And if that automation is not available, why not just have a knob widget learn the incoming pitchbend message, map that widget to the pitchbend message of the MIDI In block and then use a scaling curve?
For example, here I mapped a knob to the pitchbend wheel of my controller - obviously it goes all the way from 0 to 2^14 - 1
Then I set the scaling curve to cause that pitch range to be just 2 semitones below or above so pushing the pitchwheel fully to either end just changes the pitch in a Kontakt by +/- two semitones even if Kontakt is set to respond to pitchbend messages using the full octave amount.
The other controller that Seaboard sends is CC74 and that the one that causes the problem. I filter “other Ccs” in input block and works perfect. Its something inside that Kontakt patch, some scrip or assignment. If I transform cc74 to other happens the same. So I loose that control but i can manage> I not use Kontakt with the Seaboard that much but need it sometimes. Thank you!!!
Are you familiar with host and MIDI automation in Kontakt? Here is an example where some MIDI CC numbers are tied to controls in a Kontakt instrument. In your example, CC74 is probably tied to something.
That said, you should not be using MIDI at all to control parameters — attach those MIDI messages (like that CC74) to a GP Widget and then map the widget (or not) to the parameter you want to control in Kontakt. Then you can also use widget scaling.
You may want to read up on how Kontakt works a bit more.
I dont see this works like I need, Scaling can reduce the range, Maybe I dont see it but I need to x4 the data, how can I do that in the Widget?
