But take care before using this. e.g. on non velocity sensitive plugins (organs, fx sounds) it will be noisy and it could necessitates a CC#7 0 before and a CC#7 127 after…
And GP Script which reacts on specific incoming notes could be triggered?
I was wondering if triggering a Panic message could be enough (and cleaner) to wake up Kontakt?
What do you mean by wake up Kontakt?
Play the first note without latency…
OK, but panic sends all Note Off
I know…
And Kontakt takes time to play the 1st note for specific sounds.
Why should Note off help?
Stupid situation…
Stupid remedy
So I don"t know. Why should Kontakt wait for a note on to be ready… I don’t know…
Good point … Luckily for my volumes I’m using audio mixers (all over the place), being not depending on CC#7 values.
Maybe to save memory, to prevent loading samples until it’s really needed (i.e. when a key is pressed). But not sure why Kontakt would wait until it’s needed (knowing it is too late). But that’s outside of the GP community forum.
Why send all notes?
Kontakt would load samples never needed,
You are right, but then there is no solution (as we cannot guess the MIDI in blocks splits without handle names). We’re patching stuff while NI should be fixing Kontakt.
You are right, so I would only use rackspace scripts and send just 1 not and only to Kontakt.
Or move the volume down, play 1 note by hand and move volume up 
It’s not a pity - it was a careful deliberate design decision! Despite its name, GP Script is in fact a strongly typed compiled language intended to both be easy for non-programmers as well as being efficient.
So first of all, when you declare a plugin block, the strong typing (e.g, it can be a MidiInBlock, a MidiOutBlock, or just a PluginBlock) ensures that only correct operations are allowed so you can’t write erroneous code that doesn’t get discovered until runtime - perhaps in the middle of your show!
(an aside, I’m not interested in allowing such idiotic things like you can do
in Javascript where for example you can write such things as
++[[]][+[]]+[+[]]
and get the string result “10” (try it!)
In other languages, you have to typically declare some kind of opaque handle and then explicitly bind it to a plugin using a string. Lots of opportunities for mistakes, invalid function calls and frankly uglier code!
Secondly, and more importantly, when you declare such a variable, at startup the runtime system confirms the existence of the named plugin and tightly binds to it so that plugin block functions can communicate directly with the plugin without having to dynamically look for the plugin. So it’s much more efficient.
So this opens a completely different can of worms. Understand first of all that GP Script was originally intended as a way to do simple MIDI transformations, respond to widget movements, perhaps changing plugin parameters, etc. It was also a way to experiment with ideas that could later be incorporated into the GUI directly. (For example, important early uses were the ability to change multiple widget values simultaneously, now subsumed by the notion of widget groups, scaling widget values to be sent to plugin parameters or scaling incoming note velocities, both now subsumed by the scaling curve feature)
However, and much to our ongoing amazement, people started to do extraordinary things with the language and we’ve done our best to add extra functionality as we saw what people were trying to do. Unfortunately at this point, GP Script is bulging at the seams and really needs a serious overhaul, such as allowing overloaded functions so that we can reduce the number of system functions we have to provide, for example.
But GP Script is not intended to be a “systems” programming language. Consider what can go wrong if we allow arbitrary traversal and access to plugins and while you’re performing operations, a plugin gets deleted! Ignoring for a moment that these kinds of issues are very hard to debug (race conditions) in general, to protect against such problems, we would have to perform all sorts of locking on any access to a plugin (including just setting a parameter) and I don’t believe it makes sense to suffer the time cost of that given the intended purpose of the language, particularly when the need is to just try and work around a bug in some other product (like the well-known missing first note in Kontakt problem)
That said, you might be able to “hack” your way to this using some OSC tricksBut, for example, there’s an OSC message “/RackSpace/ListOSCPlugins” which returns a list of all plugins that have OSC handles.
So if you give all your MIDI In blocks and Kontakt plugins OSC handles, you could send this message from GP Script and then respond to the OSC callbacks.
(NB I’m not going to try it myself and can’t guarantee it would work! 
)
I just made a short test with the GPScript and a HaNonB70 plugin… I think I invented a dolphin scream generator 
So the brute force may not work (for all plugins).
At least you have now a brand new sound in your collection
Btw, it can also be made smarter:
Before doing the brute force way, muting the master channel, I don’t the plugins are smart enough to know it will not output any sound to the output.
Fully agree to this
In principle I’m going to use all sounds which I place on a rackspace (otherwise why add it anyway?) Maybe not all notes will be played, but by playing all of them, it can be assured all plugins are activated at least once (except for bypassed ones).
I have the same situation as you, Kontakt not reacting fast on the 1st played note for a specific sound.
I just use a rackspace script and just send 1 note, that’s all
With the velocity set very low no sound can be heard, but the sound is triggered.
I would never send such a huge amount of note when activating any rackspace just to be sure that a special Kontakt sound is reacting on the 1st note.
That is “mit Kanonen auf Spatzen geschossen”