Thank you very much, but how do I do it? I haven’t done scripts yet. Can anyone help me?
First you have to give the MIDI In Block which is connected to Kontakt a so called handle
Then open the script editor
In this window you can paste this code (I gave the handle RHODES, you can give a name what you want and use that in the script)
var
RHODES : MidiInBlock
On Activate
PlayNote(RHODES, C3, 1, 1, 200, 100)
end
And here you can find some documentation and examples:
https://gigperformer.com/docs/GPScript36/
1 Like
Thank you, I’ve already done it. I tried it with an el guitar and a faint tone was heard while loading the gig file. I changed the ton c3 in the script to low with an inaudible frequency. I hope I didn’t mess anything up.
ohh so sorry @Dick , I run out of time that moment, I was going to post it here…
I officially!! collect such scripts (besides I use that one myself) 
Oh no, no worries! I knew it was somewhere posted, and I was already searching for it.
But it’s a good idea of yours to save these scripts separately!
1 Like
You mentioned using the GSi VB3-II organ plugin. Do any of your rackspaces attempt to send program changes to this plugin? I had intermittent crashes loading a gig due to this issue. I had to create separate rack spaces for my organ patches.
When GP crashes you can collect and send a report which may reveal the plugin that crashed.
Hi, did you mean I should try a separate gig file where there will only be Gsi VB3 plugins?
Until August 7, I used a system in which I made all changes to rackspaces from panels, including program changes in Gsi VB3. The Gig file crash usually occurred while loading it. As of August 7, I no longer use the panel organization. The day before yesterday, my Gig file crashed 5 times while editing it and when predictive loading was turned on when editing, not when loading it. Yesterday, the program crashed only once, during intensive work of about 16 hours.
I guess you know it is probably not the best way to work with GP…
Now yes, of course with the willing help of this community.
1 Like
Today, the program crashed 3 times again. During the predictive loading, the rackspace did not finish loading and remained hanging on red and then crashed.Zip.zip (7.4 KB)
OK, now the test to make sure VB3 is the bad guy.
Can you remove every VB3 plugin and save as a new gig and test with this new gig?
I can do that. Do you think that there is anything you can do about the supplement? It’s one of the most important I use. if not, can you advise on any adequate compensation? I don’t like Hammond in contact at all.
A very good VST is Blue3
https://gg-audio.com/blue3.html
Very low on CPU very versatile
Another option could be Hammond from IK Multimedia.
But it is CPU demanding.
https://www.ikmultimedia.com/products/hammondb3x/
B5-V2 from AcousticSamples
https://www.acousticsamples.net/B5
By the way: Can you send the crash report to the developer of VB3?
Ooops: Are you using the new VB3-II ?
I use the new VB3 II. Do you know someone who also had problems with this add-on?
I am using it and I do not face the crashes you have.
I think the developer of this plugin should be contacted.
I also tried the new Gig, loading only VB3 into several Rackspaces, as you advised me, using Predictive loading at number 3, I switched it up and down several times, slowly and quickly and it worked flawlessly. Isn’t it possible that it can do this in conjunction with another plugin? I also overwrited the current Gig file with Rackspaces, which I used in the organization from panels, but I deleted the panels. Couldn’t there be any clues that caused the failures? I use VB 3 in almost all rackspaces, but only a few cause crashes.
Just for the record - I looked at two crash reports that @Premek submitted. One today (the 10th) and one yesterday (the 9th) and they both say the following
ExceptionModule -> C:\Program Files\Common Files\VST3\VB3-II.vst3
ExceptionModuleBase -> 0x7ffc71160000
ExceptionAddress -> 0x7ffc7124f5db
The version is reported as 0.0.0.0 so we can’t tell which version of this plugin you’re using, but it is definitely crashing.
If you provide the developers of this plugin with the information above as well as an exact version - they may be able to help and fix the problem in a future version.
Suggestion: If you have a VST2 version of this plugin it may work better. Typically plugins work the same in VST2 or VST3 version, but sometimes there are subtle differences.
A version which crashes and another one which doesn’t is indeed a subtile difference 
1 Like
Thank you very much everyone.
No… use a single gig file. The GSi VB3-II plugin is prone to crash if you send program change events to it, especially on rackspace load operations.
Remove sending program change events to this plugin. In my case that meant creating additional rackspaces.
1 Like