Unfortunately I have a stupid bug in connection with a second Gig Performer instance and about 16 Komplete Kontrol VSTis in each of the instances.
If someone is running Windows (but maybe it’s the same on a Mac?) and also has Komplete Kontrol, I’d like to see if it works the same way:
At irregular intervals, one GP instance will “freeze”, then the other GP instance for a short moment.
This means that the complete GUI freezes. You can’t make any entries during this time, a possible script pauses, you can’t even move the GP window itselves. Just so you can see it well (also in the video), I let a widget rotate continuously in the attached example gig file.
But it definitely has nothing to do with the script. The effect occurs even without it. There are also 16 Komplete Kontrol VSTis plug-ins open. But without any loaded sound. The CPU and memory usage is consequently also low.
The absurd thing is also: If I e.g. replace the 16 Komplete Kontrol VSTi of an instance with 16 randomly selected other plug-ins, everything runs fine without stopping. Even if they are “big” plug-ins and the CPU usage is over 60%.
Also strange: If I have only one GP instance running and opened a rackspace with over 40 Komplete Kontrol VSTi, everything runs smoothly.
Here is the example file I opened in both instances: Test2.gig (38.9 KB)
The two run smoothly on my Windows 10. I can change views, create songs, etc…no problem. If I add a rackspace and then go back to the original rackspace the knob has quit turning and I have to compile the script again to get it going.
The background process NTKDaemon is running for you too? When I end the task, it starts again by itself after a few seconds.
Edit: And the widgets are really spinning all the time without stopping for a little moment about every 10 seconds? (On my fast system the stopping is even shorter than shown in the video)
I take it back. I am getting some hiccups now. Before, the two knobs seemed to be almost sychronized. Now they are both kind of erratic. When they lock up the CPU rate jumps up a little…then they continue. The second instance percentage is always about 10 percent less.
Yes, it’s not about them running in sync, it’s about the hiccups. In this short time GP freezes briefly. Instead of the script, you can also assign the widget to a midicontroller. If you move the controller, you will also notice this little “hiccups” (Which you also hear when the widget is linked to a plug-in sound parameter and you play)
I tried the scenario that @LeeHarvey described above and i am also having those erratic “hiccups” on both instances - no OSC or virtual midi channels involved.
My machine is a laptop running on WIN10 (2004) with 16GB RAM and a i7 CPU.
I watched the ressource monitor a while and every little freeze is accompanied by a clearly noticable CPU peak (of the same core). I also noticet that there are many tcp-connections by ip4-loopback that are made by every GP instance (between 240-280 each!), also there is a permanent network traffic of >3MB/s happening in both directions. Maybe there are some limits that are exceeded by all this?
I also had stopped my Antivirus & Firewall, with no effect on this.
Just to chime in here … GP does not “freeze” but the knob movement glitches for some reason.
Most likely the underlying parameter changes are ok, but we have no way of knowing really.
The network traffic is not coming from GP if you disabled OSC so it must be coming from the plugins themselves.
We do not know what does loading the 32 instances of that plugin does.
Can someone replace those plugins with say our gain control and see if this still happens.
