Reusing global AU instrument instances

I am new to GP and do not know what you can and can not do with GPScripts, hence asking. I understand now that widgets can not be iterated which means that scripting can not solve what was discussed.
I don’t think I am trying to “Mainstageify” GP in this case. The feature I am asking for does not work in Mainstage either and it has been one of my pains there. I was just hoping to maybe find that GP had a way around it.
I think the test I did with 10 instances of piano+rhodes combined with predictive loading setting of max 5 proved that reusing vst/au instances would be benificial.
Since I am considering migrating from Mainstage (which will take quite some effort) I would like to do it in a sustainable from the start. I guess it can be interpreted as premature optimization.
The @rank13 solution would be perfect - I am new to GP and do not know what you can and can not do with GPScripts, hence asking. I understand now that widgets can not be iterated which means that scripting can not solve what was discussed.
I don’t think I am trying to “Mainstageify” GP in this case. The feature I am asking for does not work in Mainstage either and it has been one of my pains there. I was hoping to maybe find that GP had a way around it.
I think the test I did with 10 instances of piano+rhodes combined with predictive loading setting of max 5 proved that reusing vst/au instances would be benificial.
Since I am considering migrating from Mainstage (which will take quite some effort) I would like to do it right from the start. I guess it can be interpreted as premature optimization.
Fg
I am new to GP and do not know what you can and can not do with GPScripts, hence asking. I understand now that widgets can not be iterated which means that scripting can not solve what was discussed.
I don’t think I am trying to “Mainstageify” GP in this case. The feature I am asking for does not work in Mainstage either and it has been one of my pains there. I was hoping to maybe find that GP had a way around it.
I think the test I did with 10 instances of piano+rhodes combined with predictive loading setting of max 5 proved that reusing vst/au instances would be benificial.
Since I am considering migrating from Mainstage (which will take quite some effort) I would like to do it right from the start. I guess it can be interpreted as premature optimization.

Sorry for copy/paste error on this post (edited on phone). I can’t find the pen-icon to correct it.

If the Local Rackspace widgets you want to “iterate” are mapped to Global Rackspace widgets and have all a GPScript Handle Name, then from a Global GPScript you will be able to check the presence of these widgets and set a default value to the Global Rackspace widget. And if they are present they will automatically set the local value to the global widget.

In order to edit your posts:
image

Thanks but sorry, no pen-icon. Is it because of being new on the forum maybe?

Just a thought: Have you considered using the setlist mode with it’s songs and songparts? As far as i know, this will only reference to existing rackspaces and variations, so that a single rackspace (if it is layed out smart enough) can be used for many songs, while the corresponding fine adjustments for the sound will come from the variations.
This would reduce the number of duplicate rackspaces massively.

1 Like

Thanks for the tip! I guess songs and song parts are links to rackspace/variations plus a “snapshot” of the values of the local widgets (when you do “Capture variation into this part”). I like this feature but it would not affect the problem discussed I think. The number of rackspaces will be the same regardless if you use variations or “song snapshots” to alter it.

What exactly is the problem beyond the fact that GP is not MS?

What exactly was the purpose of your test and what was your conclusion?

This is the problem:
When reusing a global instanced AU/VST instrument in a new rackspace, and the reused AU/VST shall have some alteration of some parameters that are not yet exposed through widgets, I end up with unpredictable alterations of that instrument in other existing rackspaces using it. The reason for it happening is that the newly exposed parameter is not reset to its original value when switching to the already existing rackspace. Hence, I was asking for if it would be possible to send the default value to the AU of all parameters that are not altered locally, when loading a rackspace/variation.

1 Like

Ok the solution could be:
Load the preset in the global rackspace and then let the widgets do their job.
But I have no clue if that really works and is stable.

I was told to let GP handle optimization and instead add instrument instances over and over again where alterations are needed. Hence I created 10 instances of the same rackspace containg UVI and Kontakt with my sample content loaded.
The purpose of the test was to see GPs predictive loading in action. My conclusion was that it did work, but not seamlessly in my case. When toggeling to a new rackspace I sometimes got a moment of no response and sometimes the Apple appeared. Therefore I did abandon the wish to have single global AU instances reused.

Typo correction (still no pen-icon for editing posts found).
I meant to write “Therefore I did NOT abandon the wish to have single global AU instances reused.”

Was it the next rackspace in the list or some randomly chosen rackspace?

It was the next in rackspace list.

Did you use purge sample pool in Kontakt to save ram usage?

Then there should not have been any delay.

This suppose that you are playing songs sequentially, not that you are browsing rackspaces sequencially, but too quickly.

And of course if you have enough RAM, use it to load the while gig file. :wink:

2 Likes

No I did not purge sample pool in Kontakt. I did not think it made sense in this case since I want to be able to use the full keyboard for the Rhodes without having to think about if some range was purged out or not in the particular rackspace I am using for the moment.
Purging was a great tip though. I would probably use it for e.g. a large string library where only a few notes and articulations are in use.

I don’t think I fully understand but it sounds like something that you would do on the rackspaces that gets the unwanted, unpredictable alterations. The problem is that it is hard to tell which rackspaces that are affected. Also, managing existing rackspaces when creating new ones is what I wish I could avoid.

I just joined this forum because I had the same questions. I am extremely frustrated as a new GP user (and a frustrated MainStage user). Like you, I want to tweak a parameter in something that’s in the GR (Global Rackspace) and only tweak it for when a given regular rackspace is loaded.

For example, I added a reverb to the GR so I could use that same reverb universally. I added a knob to a panel in the GR to control the reverb time, and I want that to vary from rackspace to rackspace.

So, I map the knob in the GR panel to a global parameter. Next, I have to go to every single danged regular rackspace, edit the wiring to add the To Global Rackspace widget, edit the panels to add a knob and then map the knob to the new global parameter. Then I have to get out of edit mode, make sure the new knob is set to the value I think is equivalent to a default, and save. You have to do that for every single rackspace, just because you want to vary a value of a widget in the global rackspace for just one regular rackspace. It’s kind of crazy, and it makes global rackspace only really useful for things that don’t change from rackspace to rackspace, song to song.

Yes, putting Kontakt in the GR may be considered premature optimization. Sure. But until you have been on a gig and have had the leader call off a song, only to wave the band off from starting because your horn samples are still loading, you haven’t experienced the real and predictable pain of loading separate Kontakt instances on a per-song basis.

I’ll have to look into that 2nd instance strategy. I am a newbie and I don’t know exactly what that implies, but I am guessing that maybe through some MIDI magic, you wire up rackspaces to route MIDI to another instance, like when you need those horns right away.