There are two comments I frequently get from new users of Logic who have come from other DAWS:
- Wow, I can load a lot more virtual instruments (software instruments in Logic parlance) than I could in my other DAW.
- How come when I load a multi-timbral instance with 6 patches in Kontakt or Play or Omnisphere, it only seems to use a single core and that core then overloads?
The answer is that both are part of Logic Pro's basic architecture, which puts any instruments that are armed into 'Live' mode at your audio cards buffer and puts other instruments that are playing but not armed into a higher buffer. The result is that you can indeed therefore load more software instruments but it makes Logic Pro not very multi-timbral friendly.
Years ago I had occasion to speak with a member of the development team and ask him about this and the answer I got went something like this: 'We believe that the multi-timbral workflow is a dated concept carrying over from the MIDI tone module days that has persisted because computers are not yet powerful enough. With the increasing computer power available, we recommend using a single track for each patch.'
I made the argument that many people like working multi-timbrally and that I did not think that was going to change. Whether my point resonated or not, the basic architecture remains the same in Logic Pro X.
Let's explore the ramifications of this. I am using a 2011 Mac Mini i7 2.0 Quad Core with 16 GB of RAM for what I will now explain.
In Pic 1, you can see I have four instantiations of EastWest's Play, each with a single legato slur accent patch from Hollywood Orchestral Woodwinds playing. I have an audio track selected, so none of them are armed.
Core distribution is just fine and these are very big and demanding patches. I now arm one of the software instrument tracks and in Pic 2, you can see that the fourth core is indeed taking a bigger hit, but still doing pretty nicely.
In Pic 3, I have armed all four tracks, essentially the equivalent of loading the four patches in a single Play instance, and as you can see it's pretty much all going to the fourth core.
While I am working at a 256 audio buffer size and nothing else is going on, clearly, we can see that separate instances is a very good workflow for core distribution.
What about RAM usage? Doesn't having four Play instances instead of one eat up a lot of RAM?
As you can see in Pics 4 and 5, the answer is a resounding no. Four empty instances eats up very little more RAM than one. (When using a software instrument like Omnisphere this might be a different story, as in and of itself, it loads up more RAM.)
So what about loading them in one instance, does it in fact all go to a single core? As you see in Pic 6, the answer is yes.
At this point that is not a problem, but as I add more and more software instruments to the project, it is almost certain to become one. Oh well, no real problem, right? We should just use a separate instance for each instrument.
For me, that is an unacceptable solution as I may well be using five or six articulations for each instrument, which means I could need around 50 instances just for the woodwinds! Some people have no problem with dealing with two hundred plus tracks, but I do and so do many others.
You see why I say it is a conundrum. How can we deal with this issue with Logic Pro X? There are several alternatives.
The first alternative, and my choice, is to use a secondary host like Vienna Ensemble Pro, because unlike Logic Pro, it spreads the patches within a multi-timbral instance throughout the cores nicely and if I balance my templates properly it helps a lot. Plus, I do not have to reload the instruments when changing projects.
This is not for everyone however. It involves some expense, a dongle, and an additional learning curve. Also, some people use such a differing palette of instruments from project to project the template paradigm is not for them.
Another solution is to use as many keyswitch patches as possible on individual instances. Libraries like Kirk Hunter's Concert Strings II for example have patches that have all the articulations it provides within a single patch that you can keyswitch through, so five instances covers your string section.
The problem is, maybe you do not own and/or like any libraries that have a lot of these kind of patches. EastWest's Hollywood Series indeed has very few keyswitch patches. Also, keyswitch chasing in Logic Pro can be a little annoying and some people just hate the keyswitches workflow.
If none of the above works for you, your solution may be a balancing act, a compromise if you will.
In Pics 7 and 8, I have used EWQLSO Platinum Woodwinds. I have four instances of Play, each with four loaded patches (articulations) assigned to discrete MIDI channels, for flute, oboe, clarinet, and bassoon, a total of 16. As you can see, even with 1 track armed the core distribution is fine and with the audio track selected it is almost perfectly balanced.
But Jay, I hear you saying, you have sixteen tracks? I thought you wanted to avoid that?
I am glad you asked because there is where Logic Pro X has given us a method that previous versions of Logic Pro lacked: track-based folders called Track Stacks!
We have always had region-based folders in Logic Pro which were handy for many things, but this is a different ball game.
I rename the tracks and regions to reflect my articulations then under the Track menu, I choose Create Track Stack, or press Shift-Command-D. This brings up the dialog box you see in Pic 9.
We can choose between a Folder Stack and a Summing Stack and with the disclosure triangle open, we can see a description of each. For this purpose a Folder Stack is what we need. I do this for all four instruments and now I have four neat folders named Subs 1-4. See Pic 10.
I rename them appropriately and now I see only the four tracks. Clicking the disclosure triangle of any or all of the Folder Stack allows me to see the contents. See Pic 11.
These are not the only possible solutions. You may indeed find or devise others that suit your personal taste better but this is hopefully a useful overview of some methods for dealing with this somewhat problematic issue for those who have not decided on one method.