Hi,
what should be proper syntax for ReplacePlugin() command as for the “string” field?
For instance, I would need to change one VST plugin for another AU. Should it work like this…?
ReplacePlugin(Pianoteq, “Modartt Pianoteq 4 (VST)”
ReplacePlugin(Pianoteq, “Modartt Pianoteq 7 (AudioUnit)”
Thank you
Jiri
I cannot answer your question, sorry (I just learned that we have this function…).
But I’m interested in what you want to achieve by replacing a plugin by script at runtime?
BBB
My idea was if one can maintain the same setup (audio/MIDI wiring etc), but occassionally change one plugin (e.g. reverb). This could be useful within variations or even global rackspace (with “reverb section”).
After changing the plugin, its preset could be loaded. This works for me, but I couldn’t get any result from ReplacePlugin() command.
Thanks
I had never tried ReplacePlugin before, and also can’t get it to work.
I would like to strongly advice you to first push the regular GP functions to their limits and you will probably conclude that this kind of exotic scripting idea is probably not necessary, not to say dangerous because replacing plugins on the fly while playing is probably not something for which you can guarantee an absolute safety. 
Sure, pushing regular functions to their limits is what I do anyway 
But this function could be useful, like LoadGPPreset which is one of the best new functions I think and can have huge impact on overall workflow and number of plugins used.
Thanks
Hm, I would do this “traditional”: put two (or more) plugins in parallel (or serial), and switch them off (or bypass) instead of replacing them?!
Yes, this is what I was trying to do recently: to have “reverb unit” in global rackspace which is able to switch between 7 different reverb plugins. In my setup, this could save 50+ instances of reverb in 80+ rackspaces. Unfortunately, it is not so simple as to create one long serial chain of plugins and bypass them on the fly because there is cumulated latency between the plugins in the chain. E.g. CSR reverbs, which sound great, do it. They must be connected in parallel, but this also means that there must be some switching plugin between them otherwise there is a mismatch in audio path, wrong volumes etc. And of course, a lot of scripting…
Now imagine the difference: to have just one instance there, which could replace the plugin currently in need. Then load its preset and this could be maximally simple and effective. So this was my dream…
Well, you could do a mix of both worlds: switching your different reverb plugins on one hand, and loading presets by GPScript?
About the additional latency in serial config I’m not sure: if a plugin is in bypass, there should be no additional delay from in to out?!
I personally would go the parallel solution with a mixer and some “radio” buttons, or a dial in my global rackspace.
I’ll try to darft a gig when I’m back home!
Per the documentation,
Load a GP plugin preset in the background - seriously experimental and probably very unsafe
Per the documentation
Replace the plugin in the specified block - experimental
In particular, anything marked experimental can go away without warning in a future update — never depend on such functions please. Basically, in such cases, All Bets Are Off!
The string argument is the full path to the location of the plugin.
But as I said, it’s very experimental and will probably go away. I see too many ways that this function could just crash the whole system.
I might be missing something, but of you run them parallel, then connect them all to the same target (bypass all but the one you need of course), why would there be a mismatch in audio path?
Of course I have seen this warning, I was trying it like an experiment. But I could say that all the plugins were perfect with LoadGPPreset, no crash whatsoever. Maybe there should be a lot of beta testing this function with different plugins. I have tried very different kinds of plugins - Pianoteq 7, Blue3 organ, Kontakt 4 and Independence samplers, several reverbs, even Audio File Player with multi track audio files - so far everything was perfect. It would be pitty to see this function going away.
Replacing plugin is perhaps more dangerous and I understand that it should not be relied upon.
Because the plugin is bypassed, but not the routed audio itself. So in order to maintain proper volume and routing behavior, I used to direct audio via multi channel audio mixer, which was directing signal to different reverb plugins. The route to actual reverb was soloed, the rest was muted.
Well, theoretically not, but I have tried it with CSR reverb plugin making just very small latency (0.1 ms) and finally the difference was audible. This issue is discussed elsewhere here in the forum.
Yeah, me too — but it needs to be tested with thousands of plugins to determine how safe it really is.
So, one volunteer here
OK, you also said audio path, that’s what confused me. Makes sense. So along with bypassing, you could group mute buttons of the mixer, so in the same bypass action, automatically those bypassed signals would also be muted. Seems more reliable to me than swapping plugins.
Yes, you’re right. It was basically my approach.
Just for your curiosity, I have tried to do simple setup with one rackspace + 2 variations and one reverb plugin to test this command. The code goes like this:
Var Reverb : PluginBlock
On Variation (oldIndex : Integer, newIndex : Integer)
Var name : String = GetVariationName(newIndex)
path : String = "/Library/Audio/Plug-Ins/VST/"
Select
name == "Default" Do
ReplacePlugin(Reverb, path + "OrilRiver.vst")
name == "Variation 1" Do
ReplacePlugin(Reverb, path + "OldSkoolVerb.vst")
End
End
In case of VST and VST3 plugins, ReplacePlugin() really switched between plugins several times and then stopped to do it. In case of AU (Components), there was no reaction.