I have another question - maybe someone has already described this here - but I have not found anything directly in the forum when searching. The problem is this: I have Rackspaces in which various software Synthesizers are located. Each Rackspace has a number of variations.
The goal is now to send different PC messages to the respective synthesizers in each variation and the whole thing is best with a button for each synth in the respective panel (so that it can be easily operated)
Please be aware that if you do this, you cannot guarantee that switching from one variation to another will be glitch free as the time it takes for a plugin to respond can vary from instant to many seconds (the latter if the plugin has to load different samples, for example)
The delay is not a problem - in case of doubt the plugin does that. The problem is the memory. In the racks are combinations of sample based and VA synths. If I pack the synths into different rackspaces and copy them for each sound, the memory is used up quite quickly and that takes then really a long time to load the rackspace despite predictive loading in the worst case. Therefore, in my case, it is better to control the VA synthies via PC’s, and not to reload a complete rackspace for each new sound.
Since the variations unfortunately do not remember the internal parameters of the plugins (that would be a feature request… ) this can - as I can currently judge - only be done via the way of the widgets that save the state (in this case the PC) in the panel of the variation. Of course there is also a way to code it hard - but that is much too cumbersome to try out the sounds.
Therefore, a simple rotary control in the panel, which then generates the PC’s in any way in a wiring object is the idea. Maybe there is allready such an object and I was too stupid to find it - otherwise I would have to build one - and there would be the question how?
I had already made an attempt to do it the way you suggested with the lyrics window. But that doesn’t seem to work, because wireing objects obviously can’t access panel objects…
Yes… great idea… but what if the nice plugin (in this case the FM8) have hundreds of controllers - but the developers from Native Instruments just thought: “Mhh well - there is no need for a “PC” controller because everyone can send a PC easily over midi…?
To be honest - I think they’re right - at last if you think in there product universe. But yes - you’re right - this is the normal way to control the things that have a controller
That’s the way it would be done.
But be aware that there are many plugins out there which don’t support receiving PCs!
In that case you’d have to use the GP-internal preset system, which maybe was the even more universal approach (i personally consider this to be more reliable than some proprietary plugin functions). Just some additional thoughts…
Yes - that actually depends on the plugins. Especially Native Instruments is a bit tricky, because of course they want to sell their Komplete controllers and they don’t make it that easy, especially with the reactor-based sounds - but luckily you can help yourself. The usual Synties can actually all PC’s. In addition to the FM8, I also have Bazille and ZebraHZ in use - it works flawlessly - even without glitches when switching.
If switching the internal plugin parameters with variations would work, that would actually be my preferred approach. The point is just that this is unfortunately not supported by GP. The apparently “official” GP way is “Take Rackspaces” and live with the consequences (lack of RAM memory).
The problem is that variations only save the widget- but not the internal plugin settings.
The advantage of the solution via Rackspaces is certain that there are no glitches and you can even finish the old sound. The disadvantage of the method, however, is that it can become enormously memory-intensive if there are many rackspaces - especially if sample-based plugins such as Alica Keys are added.
I have to try to see if the local GP port trick also works in the global panel. Then I could pack the synths that I always need into the global panel and control them via the normal panels via PC - that would possibly save even some memory… Well, let’s see…
Well, i do use variations to switch between previously saved GP-Presets of a plugin (i.e. the B3-X from IK-Multimedia). I use a knob widget and some scripting to call the presets.
It does work (not seamlessly thogh), but the handling of the GP-presets as i do it in the mentioned rackspace is not as straight forward as it sounds, because the number of presets is evenly distributed over the range of the knob widget.
This works flawlessly as long as you don’t change the list of presets, because the assignment of a preset to the corresponding widget value stays the same - but if you add or remove a preset from the whole list of available GP-Presets, the assignment of widget position and GP-Preset won’t correspond anymore.
Another (scripted!) approach could be to call a GP-Preset by its name, which would have to be the same as the corresponding variation name (or vice versa). That way you could add or remove Presets at will…
Ohh - yes… But this lesson about the PC lists you also will learn very fast even if you are using “normal” outboard equipment… The good think is, that I can export the PC lists from all of the synths I use (otherwise I wouldn’t use them…) So I have a PC list for each synth for each show. I had this also done for the “normal” hardware before GP, because this is probably the most essential preparation. Programm it, test it, and the never touch it anymore…
With GP this is meanwhile luckily much easier, because you don’t have to care about the accessibility on the master keyboard - just to HW controller button for the setlist (up and down) and your done :-).
I smell problems if we send pc to the vst.
They tend to be unstable that way.
I personally warn against that method.
Although I did explore it 5 months ago.
Rackspace is better and assign your pc to the rackspace. Way more stable.
does a GP user preset save the internal state of plugin?
sending PC to plugins is not recommended as it cannot guarantee stability.
if it works for you - good - but generally try to stay away from sending PC to plugins.
I did notice some plugins that were behaving like that (where the internal state of some presets was not saved in the rackspace)
It was Arturia ARP2600 V3.
When I contacted Arturia they did not solve the issue.
So could this be a problem with the plugin?
GP requests the state of the plugin from the plugin and stores it as an opaque blob of data when you save the gig file. When you open the gigfile that blob of data is sent back to the plugin as-is.
If the plugin doesn’t 100% restore state, then it’s not handling that state mechanism correctly.
Have a look at my latest rackspace design, which makes use of the variation’s names to call up GP-Presets… you can use this for any plugin - not only the B3-X!
Basically it’s the same mechanics as i use in my rig for the B3-X sounds, but this one is much more thought through and flexible. I just haven’t managed to exchange the rackspace in my own rig.
If I change the structure of stomps and their order, those changes are not saved between rackspaces. because of that, I use change presets from PC messages
Sorry, my mistake. I mean, GP doesn’t save the internal state of Amplitube (which stomps are present, their order…) between variations. Of course it does between Rackspace changes because there are different Amplitube instances inside each rackspace.
oh so a stomp is like a different preset.
and that’s why you have to change presets via program change.
i understand.
the alternative would be to add multiple instances of amplitube each with their own presets, then bypass the ones you don’t want in different variations - that’s if you use one rackspace.
) this can - as I can currently judge - only be done via the way of the widgets that save the state (in this case the PC) in the panel of the variation. Of course there is also a way to code it hard - but that is much too cumbersome to try out the sounds.
