I must admit Iām cheating around a feature of GigPerformer that is very useful most of the time: latency compensation.
All my rackspaces send their audio to the global rackspace via a dry bus and two send buses to global chorus and reverb. My main global reverb and other plugins in the chain introduce a lot of latency. Latency compensation, however, causes all other (dry) signals passing through the global rackspace to adjust accordingly. Since my global effects are send effects only, the delay of all other signals is unnecessary in this specific case.
Knowing that GigPerformerās latency compensation only works if a wired signal path exists, I use GPrelayer to transmit the sound āwirelesslyā for a couple of centimeters of the signal chain. Relayer doesnāt report latency so GP doesnāt know of the 3.2 ms added by the reverb and therefore wonāt delay my dry signals. This gives me a much more direct feeling while playing but admittedly feels a little bit like cheatingā¦
This could also be used in a local rackspace, for example, if an audio chain played by keyboard A should not be delayed by keyboard B playing a different audio chain that has built up quite a good amount of latency due to many plugins in that chain.
Or the Autotune on the mic channel should not delay the keyboard channelsā¦
This is indeed an interesting trick that @edm11 introduced to some āhappy fewsā some time ago. But he forgot to reveal his trick to the world, whereas you did!
Multi-core should not have to do anything with this: the host queries the plugin about the latency. But the host can simply ignore it.
(Recently I was thinking (just as a proof of concept) about creating a wrapper plugin that masks the reported value and that simply replaces it by ā0ā. But I building it into the host would be the better choice)
Yes there should be a way to change the default latency of a plugin.
Also, the tooltip should display the total latency of a plugin (in addition to the latency of the plugin itself) accumulated from its predecessor plugins.
I have always struggled with using two instances of GP. One with a very low buffer for realtime playing and one with a very high buffer to host a lot of instruments. Could your Trick be used to use just one instance of GP with a very high buffer setting and being able to use a certain vst for realtime playing with almost no latency? This would be amazing.
When you use vst plugin in the instance with high latency and another with low latency for live playing, then you will get delayed sound from the instance with high latency.
Or doe I miss something?
Iām afraid it only tricks Gig Performer not to artificially delay some audio streams āwaitingā for higher latency plugins in other audio streams (which is generally a good thing).
This means however that your computer needs to be able to run everything at the current (low) latency setting even though some audio is delayed on purpose.
The instance with high latency is only for playback, the low latency is for realtime playing. So it doesnāt matter in my case if the high latency instance has a delayed sound. Maybe one day in the future GP is able to have a kind of local āpipelineā with ultra low latency within the context of a global high latency setting - I am just dreamingā¦
