Does it bother you to play at 256 buffer? Does it go away? (More ram is always helpful too).
There’s honestly no need to be at 48k for live situations. 44.1k is sufficient. It takes a bit of strain of the processor.
I use 44.1 and 256… perfect ratio for keyboards. No strain on CPU at all… Very cool machine after 6 -7 hours or more turned on.
2 Likes
When you use AES then 48k is a must.
Don’t use AES
FTFY 
1 Like
Me too.
Very interesting discussion regarding buffersizes and latencies. Unfortunately I don’t know Mac OS, I use GP on a WIN10 Laptop with buffersize 128 in live performances for many years. But unfortunately my gig files only run in GP main instance not opening any other instances, so using only 1 CPU core (of 6).
These days I did some tests trying to reduce buffer size by splitting the VSTIs among a couple of instances. This reduced the per-core-Cpu-load which allowes to me to further reduce buffersize to 96 or even less. But it’s of course some work todo when I want to split a gig an distribute VSTIs on other instances to make use of more CPU cores. Is this not necessary when running GP on Mac OS, is this only a Windows issue?
By the way, today I found a way how to automatically split VSTI’s a gig file across multiple instances.
This is also a Mac thing … It’s not an issue as such. It’s just the way GP is designed so as to be much more stable. 
Don’t leave us hanging there… let us in on the secret … haha. 
Hi Miguel, is it permissible to discuss details about GP’s data formats here, or is this some kind of reverse engineering guidance, which would be prohibited?
mmmm … maybe you should discuss with the Devs first if you think it may be prejudicious to the company. They’ll guide you no probs
Yes good idea! It’s about modifying the gig file and using the modified files in GP. May be the devs can tell me, if I’m allowed to discuss this here (even if my idea is complete nosense )?
You can discuss anything that is public information. That said, there is no guarantee around the format of the XML file and we reserve the right to change it at any time without notice.
Oh yes of course, any changes to your format may require changes to the solution. So we do consider the XML format of the gig file as public information since it’s not encrypted (except the plugin states which is not in my focus)? So can I discuss this here?
Yes, anything readable is fair game subject to
a) It can change at any time
b) We absolutely won’t provide tech support for an XML file changed outside of GP
Yes of course, a) and b) are absolutly self-evident. Thank you!
Okay, so I’ll now briefly describe my idea of automating the distribution of plugins across multiple instances, at least to a large extent. However, I want to clarify that I do not take any responsibility for the use and implementation of this idea. I see this merely as an exchange of information and ideas. But the responsibility for implementing these ideas and using this information lies with each individual who uses it.
I also must clarify that I am still a gig performer version 4 user. As far as I know, this idea hasn’t been implemented in version 5 yet, but if it has, I apologize in advance for wasting your time.
The Idea
In a first attempt, I split the main gig file into smaller “partial” gig files containing only individual, computationally intensive VSTIs, so that I could then run them on separate instances. However, this is very tedious and makes it difficult to maintain songs in GP since they need to be managed by maintaining multiple rackspaces in multiple gig files.
Now here’s the idea: First, the MIDI input messages (if the MIDI driver isn’t multi-instance capable) must be forwarded from the main instance to the other instances via virtual MIDI loops. You can do this in the main instance, for example, in the global rackspace, and have the main instance receive the MIDI inputs from the virtual MIDI loop in its GIG file in all rackspaces.
Then you rename all (CPU intensive) Plugins you want to be processed by other instances with a prefix like I<n>_. E.g. your blocks named Piano, Rhodes, Organ will be renamed to I1_Piano, I2_Rhodes and I3_Organ to be processed on 3 Instances I1, I2 and I3.
Then you save the GIG file. From the saved GIG file, you then create a temp copy in which all (non-internal) plugins whose names do not begin with “I_” are set to “bypass=1.” Then further copies of this temp file are created for instances, e.g., I1, I2, and I3, in which only VSTI plugins that are to be processed in the respective instance are again set to “bypass=0” and the others still are kept to “bypass=1.” Same for the main instance where all instances whose names are not prefixed by I<n>_ are set to “bypass=0” again.
If possible, you can do this when saving using GP Scripting. However, I haven’t yet verified whether everything needed is available in scripting. If it’s not possible, you could start an external shell script (via GP scripting) and pass the gig file name. This external script can then create and modify the copies and start the corresponding instances using the “-in=” option.
Disabling the blocks with a shell script (e.g., a batch file on Windows) is relatively easy, because gig files are simple, easy-to-read XML. Using an XML (command-line) editor, you can relatively easily change certain data, for example, setting the “bypass” attribute in the path /GIGRACK/RACKSPACE/PROCESSOR/ to “0” if the name of this block begins with I1_, I2_, or I3_. I initially did this with “sed” and “grep” because I wasn’t yet familiar with the XML editor, but now it seems very easy to do.
You also have to take care not to set any internal plugins (attribute “manufacturer” is “Deskview Technologies”) for e.g. Midi Inputs and output or mixers, since they are not CPU intensive and the are needed to connect and mix the VTSI Plugins in main and alle the other instances.
Then all the instances can be started using the “-in=” option using their respectively modified copy of the original gig file. An nice thing is, that loading multiple copies of the same instance is making use of shared memory because these this is piossible in dll code and data. So you lukily do not need 5 times the memory when you load same type of plugin in 5 instances.
Sorry that this idea is described now only very roughly since I need to leave for rehearsal now. May be we can discuss this later when you think I have forgotten something or this is completely nonsense.
I do not understand. Do you mean that you load all instances with the same argument for -in=? So for example starting with -in=myrunner multiple times?
As far as I know, multiple instances of GP visible as such in the activity monitor will not share libraries or data, no matter whether they have the same arguments or not.
I guess, I must be misunderstanding you.
Sorry for my bad English writing, I mean loading copies of the same plugin in multiple instances.
Each instence will load a different copy of the original gig file where all Plugins/VSTI blocks are bypassed, except the ones the should run in the instance. The user defines this by prefixing the instance name in the name of the block, e.g. renaming Piano to I1_Piano. In gig file I1.gig the bypass attribute of piano block is set to 0, in all other copies I2.gig amd I3.gig it is set to 1.
But this renaming of the blocks may also be done by another script by e.g. renaming all blocks in all rackspaces with names is like piano, grand piano, Yamaha C7,… with this prefix I1_ in order to let them run on Instance I1.
1 Like
Here is an update on the crackling -
Soundpaint Samples (Saxophone) - seems to crackle in songs with a bunch of plug ins - the total CPU usage is around 35% -
Once I replaced it with SWAM saxophone - the crackling dropped significantly - (now its there for a few bars and then disappears)
Im going to swap out the same rackspaces with pianoteq (from my arturia piano stack) and see if that further reduces the issue.
It seemed to be with my piano stack (Arturia Piano V3 and CP-70 together) and soundpaint - sampled sax
Someone mentioned that Arturia while great value and sounds - seems to be processor heavy in certain plugins (hence buying Pianoteq to replace the stack
How much ram do you have? Soundpaint is sample heavy.
So, maybe the crackling is due to page filing (swapping out ram where there is insufficient ram).
Arturia and Pianoteq pianos use very little ram, as I understand it.