You have not defined what “m” is when you’re testing for IsController(m). It’s also not needed because the callback will only ever be called if it receives a CC message (which you’ve called C).
Unfortunately it doesn’t change my rackspaces.
Well, not correct, now it changes the rackspaces. 
Looks like the system needed some time to understand my intention …
Thank you for the support.
No problem. You could probably simplify it to something like:
Var
TW1 : MidiInBlock
On ControlChangeEvent(c : ControlChangeMessage) Matching 127 From TW1
SwitchToRackspace(GetCCValue(c), 0)
End
You made this more complicated than necessary. This is all you really need.
It will also be more efficient since it will only respond to CC 127
Jinx buy me a coke
1 Like
Thanks, interesting informations for optimization.
By the way, I had an additional intention with this thread. First of course to help me solve this program change issue which will be very useful for me when I use Gig Performer for the first time in a FOH situation.
The second thought is about communication. I have read several threads here where people asked for training to program scripts and where the experts often then refer to parameter overviews which leaves the asking people a little bit unhappy.
Here we have an example where the communication worked. I came up with an idea in the beginning and then it was solved step by step.
Some people asked for a better understanding of what programming is.
Programming starts with a blank sheet when you open an editor, and when the work is done then there are some letters on this blank sheet which do the trick.
In the background there is the understanding needed that a single thing which you want to achieve in real life may consist of one or more steps that need to be done. And because technology is not intuitive in most cases itself it is neccessary to provide the informations to the mechanism. So before programming something it is neccessary to visualize and plan the neccessary technical steps.
The blank sheet doesn’t know them in the beginning, and it also doesn’t know any information it can work with. This is where variables come in. They are able to catch external information so that the program can use it. Also it is technically neccessary to say what kind of information is used. If it contains letters like “a, b, c, d” then it’s a “string”. You can store words in it but can’t perform calculations. Someting like an “integer” can store numbers and you can do calculations with it. But you can’t use it to store words.
In the rackspace scripts the first sections seem to be always “var” where the things are defined the script or program can work with and where they come from.
Then there come some things which selects and process information. In the end there is a kind of result, an output or a reaction somewhere in the configured system.
I think a good way to understand this programming here is to look at the existing gigfiles and examples which are available here in the forum, to load them, to check what they are doing and if there are rackspace or gig-scripts attached. And then try to understand what they are doing. If the scripts refer to plugins that somebody doesn’t have please replace them with existing ones and try to bring them to work in the configuration.
Of course this might be a little bit time consuming but I think this is one of the appropriate ways to make it work. And after some excercising the understanding grows step by step.
1 Like
One additional notice about " If it contains letters like ‘a, b, c, d’ then it’s a ‘string’."
For this explanation it would have been better to take e.g. “k, l, m, n, o” as examples. Why? Because the letters a, b, c, d, e and f can be seen on the one hand as letters, but on the other hand also as numbers, when you are working in the “hexadecimal” area.
So one of the first things if somebody thinks about programming should be how numbering systems correspond to each other.
It is important to know the normal decimal presentation with numbers from 0 to 9, but also the corresponding values in the binary area with numbers from 0 to 1 and in the hexadecimal area with numbers from 0 to F. Once the relationship is clear many items and parameters are seen in technical environments which use this. Additionally there is the octal system with numbers from 0 to 7 but you won’t see it that often. Of course the calculator in Microsoft Windows has a programmer mode that works with this.
For example the value 127 which is often used as value in the MIDI area. In binary representation this is “0111 1111”, therefore the biggest number in an area of 7 Bits. In hexadecimal representation this is “7F”. Technically the same but needs less space to write down.
Although it will be slightly faster, it wasn’t suggested as a optimization but rather as the correct way to implement this feature as described in the GP Script language manual in the section about constrained MIDI callbacks.
Well, don’t make it “small”. Of course the result of the process in this thread is a technical way to transform an input value into a different output value. The correct implementation results in less calculation cycles to deliver the result which is good for overall processing stability.
But in reality this here is a little bit more than just a simple addition of two things: It is a complete solution which can be easily adapted to different scenarios by changing the input sources or output targets.
Maybe the GP script language manual shows the correct way to write a parameter. But it gives no idea how to combine the parameters correctly to build the complete solution for a demand. Maybe there are people who understand programming but most likely they are often not musicians. Musicians with demands are often not programmers and think less structural (which is of course good for the music and opens space for new thoughts and things).
I think this here was something good.
Correct — we cannot be in the business of teaching people how to write programs or develop solutions with GPScript. That’s a rabbit hole.
2 Likes
A second thought… please… a second post!
I am not sure to understand exactly what you mean, but I really have the feeling that GP community member always try to make other community members happy. There is no notion of high level expert and low level users here. 
Regarding GPScript, devs are clear about it, it was never thought to be a GP functionality from its own. But the beast escaped from its creators 
It is probably not true that scripting is for every users (some basic programming skills are welcome to start with it), and hopefully users don’t need to use GPScript to use GP and play music. So, scripting is not the ultimate GP level to reach and many happy GP user will never program a single GPScript.
However it can happen that in some difficult use case scripting would help. In this situation we can give some help to willing users who wants to start with scripting, but for some without programming skills, there is alway another user with programming skills who can help.
Please tell me who is unhappy here, we will make him happy 
5 Likes
Well, let’s say it is a very useful beast and it’s worth to care a little bit about it …
While surfing on the threads in the forum here I found several places where users asked for some more explanation about how to get in touch with this “programming thing”, and the reaction mostly was a comment that this kind of training can’t be offered plus a hyperlink to the command overview.
I can fully understand your point of view. When your knowledge of programming rises automatically the view changes how you look at things. You get a deeper understanding of how things happen and it’s not longer possible to go back to the point where you didn’t know all the things. And then it is fully understandable that you refer to the command overview if someone has a basic question and you know you would find a solution by just reading through the commands.
The thing is that a user who wants to get help from this knowledge must try to enter this world by his own brain. Even if there is a trainer sometimes the trainer doesn’t reach the user with his explanations. The user must perform the initial step by himself to be able to work with the presented information.
In the meantime to me it seems that things in GPscript mostly follow the sequence “information collection - selecting/processing - result/action”.
So I would recommend that somebody who wants to understand the programming should look first at existing scripts and try to identify the three regions in a script. Just to get an initial feeling for the form and the general parts of a script.
Next step is then to look at the used commands and review the command library to see what is explained there for the used commands. Instead of a big unsorted amount of commands he would care for some informations which already work together. This is better for memorizing.
When you do this a while the big amount of unsorted information automatically starts getting to become more structured and comfortable because you start memorizing things you have seen earlier. And then you start understanding the things other users did. Also you might find things that look a little bit like the issue you would like to solve. And suddenly you have the understanding for the things.
So my suggestion if someone asks for a programming training would be to give him a link to a place here in the forum with GPscripts and rackspaces which are working and ask him to try to understand what is happening.
Even if these scripts have nothing to do with his original problem. And maybe after this sort of training he at least is able to discuss things with you on a level with at least a little bit of knowledge.
Like pretty much every imperative (non-functional) programming paradigm in existence!