Layout remapping script for grid controllers


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 :wink: @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.