Global Rackspace to load multiple Arturia Analog Lab instances?

I dont think this has specifically been answered or talked about.

I’m building a new synth based rack. All of my synths come from the Arturia collections. I do see a noticable difference in size and load time if I used the inidividual synths instead of Analog Lab.

BUT… My songs will never have more than 4 synths in them, and I probably use about 20 different synths through a gig (25 or so songs).

Stop me if Im wrong, but wouldn’t it make sense to put (4) instances of Analog Lab in the Global Rackspace and just use those for every song? Im assuming you chould change the patches for every new song and it would still work for the global rackspace. (4) instances of analog lab seems to run fine and load times arent too bad, but here is the alternative, I think…

Right now Im guessing I will have 25 x 3 (75) or more instances of these synths running if I just load them up in each rackspace per song. It preloads up the entire gig at once, correct? I could literally have 100 instances of these synths running. I’ve only gotten through 3 rackspaces and its alread up to 10 synths.

Hope all the makes sense.

With such a concept you will loose patch persist.

1 Like

Im not sure that would ever affect me. I use Livetraker to run our gig. So in between each song it has to take a break and switch to the next song. We either have fillers / samples or talk but we never run two songs together. If we did we would have to do it as one long song because of the way Livetraker works.

Is there anything else it could affect?

And what if I did decide to hold down a note, but planned it so that exact same patch is used in the next song? Woud it still glitch out or would that work? Or is that note now going to hang forever?

Do you never change sounds to be played on the same Keyboard while you play a song?
I could not live without that feature, because I am using S88 MK II as the only keaboard.

I do alot of splits and have two keyboards onstage. So currently no BUT as I start automating more of our show (were doing an 80s new wave tribute) and start to cover more keyboard parts at one time (Im combining live with tracks right now since 80s had SO many keyboard tracks).

So I will need to think about this and I appreciate your help.

I’m thinking going all virtual synths may not work for me. I changed my mind about two weeks ago when I really started programming these songs out and realized theres no way I was going to emulate all this 80s stuff with a single keyboard. And then found arturia and realised there is everything I need in one place.

Even splitting up into two gigs over the night, its going to be way too much. My laptop is an i7-8550, 16 gb ram and all SSD, but I dont think its going to be able to handle it. Maybe Im wrong? I dont get how other people are doing it. Maybe they’re not using as many synths as I am?

I am using only plugins with and with many different sounds.
And when a plugin uses too much CPU I just revamped it and use Kontakt.

Thanks Paul…

Still trying to wrap my head around a couple of things…

If I just load 4 instances of Analog Lab into every song, is Gig Performer going to preload it 4 x (however many songs there are)? Or just 4 times because each song uses 4 instances? Or is it not smart enough to figure that out? How about with predictable loads enabled?

Could a work around be I just create one rack and then then use variations for each song and its part? Would that accomplish the same thing? If so, it would also mean Gig Perfomer has the functionality it just isnt designed that way. I might have like 50 variations in a single rack but if it works…

My last post wasnt clear… I meant without using the global rack.

You are thinking too complicated.
Just build a rackspace with plugins for sounds you need.
With patch persist you can seamless switch between sounds.
And when RAM is limited, take a look at predictive load.

3 Likes

I will move forward and take your advice. Im also adding another 32Gb to my laptop to get me to 48GB total, just in case.

Thanks

2 Likes

I play in a cover band where my song list is something like 80 songs.
Every song is made with song parts, every part has one rackspace with some synths.
I put in global rackspace only a mixer to tune volumes in case a song has more sounds.
Every keyboard patch is a rackspace.
When I load my gig, it can take 2 minutes.
But after that I have no issues.
My suggestion is to try a simple rack approach as I mentioned.
It works.
My computer is a MacBookPro 2020 with M1, 16 giga ram

1 Like

I would like encourage you to first try if you ever will encounter any memory issues with your given 32GB… if everything runs fine, you definitely have no problem which would make it necessary to buy more RAM.
Don’t worry if much of the RAM is used by your plugins and GP… this is why it’s there! RAM should be used! If you have more RAM than ever will be used, it’s useless (literally).

I have some similar concerns and issues with Arturia Plugins. I play in a tribute band and the number of synths/keyboards used is huge over the set. That is, I create a rackspace for a song and switch through the variations throughout the song, so all the required plugins and patches for a song are preloaded. The problem in part comes from Arturia plugins not being able to receive program changes, so each sound requires a new synth, so if two patches from the same plugin are used on one song, it has to be loaded as two plugin instances. Even with the predictive loading turned on and down to 3, I still find memory issues (especially when editing). This number ramps up quickly when you get two or three complex songs preloading. My MAC Pro runs out of memory (48Gb), or more correctly starts playing with swap files, when just using the variations in GP (I daren’t even try it on my Macbook Pros with just 16Gb).

I have solved the editing issue in that I create a new gig, so when building a rackspace, I work on just one song. This stops the preloading issues when editing. I then export the rackspace and pull it into a gigfile used to build the set. Using the setlist to create and tweak the final versions of a song.

As I see it at the moment I have two options. Load my patches into a concert within Arturia Analogue Lab, this will then let me select using program change thus lowering the instance count, but relies on two disconnected systems to be maintained. Or split my songs into multiple rack spaces that I can step through so the preloading is not trying to load 40+ Arturia instances into memory. The second has a knock-on that I do not allow my previous/next to go beyond a rack space to save sudden preload hits if I get a bounce on switching.

I am desperate to get using GP but I am staying with Mainstage until I can get round these issues, I don’t know what MS does differently to GP, but it runs fine on my Macbook Pros, with the same (ish) plugins loaded (I say ish as the few native MS plugins is did use I am having to replace).

I guess there is no right or wrong way to go about doing these things, but I was hoping to free myself from the MS pain when switching rigs, Rig Manager was one of the main reasons for shifting to GP. This is not about asking someone to fix anything, more about am I thinking about GP use in the correct way?

I am debating running on two Macbook pros one per board, but I lose the backup system, unless I buy more computers!!

From Memory Usage there should be no difference.
Are you sure you use the same amount of plugins and the same versions etc?

Yep, I have all my patches set up in an Arturia bank file. All the GP rack spaces use the same bank file to get the patches from. The only real change is the native MS plugins are being replaced. The Artuia installation is the same V8 collection on all my machines. The inability of Artuia to let you bank switch means I have to load multiple instances in MS as well.

In my experience it is better to use the single plugins and not Analog Lab as an additional container.

That was my gut feel on this. I noted from the Joe Luca interview that he used multiple rackspaces within the context of a single song, and he is using a machine with 64Gb. But I also believe he does not use the preloader so everything must fit in 64Gb

Further thoughts on this issue. In MS a for me song is a “set” with “patches”, the equivalent in GP is a “rackspace” with “variations”. In MS I can use an alias at any point to get the same sound eg. piano. This is used along with the other plugins required by the song. This uses just a single instance of the aliased plugin and costs zero additional memory. In GP the separation for a song is the “rackspace” and as I understand it each rack space will require a separate instance of a common plugin, along with the ones unique to the song. Have I surmised correctly?

If so this seems to suggest some plugins are being loaded several times when using the same sound? If this is the case I will have something like 15 pianos loaded when I would only need just one. This would also be true for some Organ sounds and string pads. As the OP of this thread was suggesting would some common sounds in the global rackspace work to reduce the memory overhead?

You can use multiple instances of GP or use the global Rackspace.
But loading multiple instance of the same plugin is not really an issue.
Except you are using a Sampler with huge amount of Samples which need RAM.
I am using Kontakt, and it streams from disk and you can optimize memory usage.

Sure you can load a plugin in the global Rackspace, but you have to think about bypassing, unbypassing that when not needed or needed.

For my opinion effects like Chorus, Reverb or Delay or Master Compressor/Limieter are candidates for
the global Rackspace, but plugin that produce sounds like Piano,Strings, Organ,Synths etc are better placed in the local rackspaces.

It is when with about half my set loaded my memory usage is hitting 40GB, editing becomes almost impossible and any more and the swap file pain becomes unbearable. Some are sample based, the Arturia pianos are quite heavy on memory usage, hence the concern over technically redundant plugins.