What's new

Should my MacBook Pro M2 be performing better?? Or is this how VST life goes with only 16GB

I'm controversial round these parts in that I am a firm advocate of using some of these techniques anyway (low preload buffers, disabled tracks, mic mixes) and working this way I rarely creep above 32gb of RAM even on big orchestral projects. If you had that I'd urge you to stick with what you have. 16gb though is a much tougher ask so good luck!
Then I'll join you in controversy (albeit with only 16GB) :) , especially on buffers and disabled tracks: using high preload buffers on Apple silicon is almost sabotage, since it ignores the architecture's strengths and leans on its main weakness. I wish VIs would ship with more sensible per-architecture defaults.

Logic's lazy loader is far too eager for my taste - e.g. click your string section track stack, and everything will load. More careful clickers might be fine, but I couldn't work without disabling all sampled instrument tracks in templates.

1. Find out what's eating all the RAM. Use Activity Montor to check how much Logic is using, and measure the changes as you add your instruments.
I'm a big fan of test-then-fix, but correctly interpreting memory stats requires a fair bit of expertise (e.g. how/when memory is returned caused some confusion on another thread.) IME, the memory consumption reported in the plugin is usually good enough... just need to check whether the consumption is per-instance or across all instances. (Spitfire is the latter.)
 
Only if it suits your work methodology, freeze tracks when you've done fiddling them to save ram and CPU...
 
IME, the memory consumption reported in the plugin is usually good enough... (Spitfire is the latter.)
The main thing to remember with that is that most plugins (certainly Kontakt) only report the memory used by samples. Plugins / libraries / instruments can consume vastly more than this.

Generally I find like-for-like is useful in Activity Montior / Resource Manager - see what your plugin reads when empty, than what it reads when an instrument is loaded. But you're right in that it call can be a dark art - in Windows I often find VE Pro reports double the amount of RAM used when first loaded than it does after 20 mins or so. All kinds of crazyness going on under the hood outside our control.
 
If you haven't already done so, try increasing the I/O Buffer Size in Audio Preferences and set Process Buffer Range to Large.
 
The main thing to remember with that is that most plugins (certainly Kontakt) only report the memory used by samples. Plugins / libraries / instruments can consume vastly more than this.
Generally I find like-for-like is useful in Activity Montior / Resource Manager - see what your plugin reads when empty, than what it reads when an instrument is loaded.
Where are you seeing that? There will always be overhead, but this should be small compared to the samples, and certainly not vastly more. The difference may appear to be much larger when looking at some memory metrics in Activity Monitor, etc, while loading/unloading single instrument, though: that's exactly the problem with that kind of testing.

You can still use Activity Monitor to detect VIs with memory bugs, though, e.g. by looking out for memory usage that ticks ever upwards.
 
Where are you seeing that? There will always be overhead, but this should be small compared to the samples, and certainly not vastly more. The difference may appear to be much larger when looking at some memory metrics in Activity Monitor, etc, while loading/unloading single instrument, though: that's exactly the problem with that kind of testing.
No, the overhead from non-sample sources can be vastly more than sample ram, especially with low preload buffers.

I love Audiobro, but their more recent instruments are absolute goliaths with no samples loaded. With Modern Scoring Brass, their Horns 1 patch consumed a staggering 1.2gb with no samples loaded on the first instance, then another 544mb for each succsssive one. Their support were very helpful and gave me some detailed instructions on how to edit the instruments to get the resource use down to more manageable levels. Here's what Sebastian K said the three main areas that consume RAM in Kontakt are:

1. Sample preload
2. Instrument map (zone data, group data, routing, mods, effects, etc.)
3. Persistent script data + UI caching and drawing
He continues (this is referencing Modern Scoring Brass):

The second item (instrument map) is the area that is likely the largest culprit that folks don’t think of and likely the most relevant here. There’s a ton under the hood that is put into memory. With MSB Horns a large amount of that data is just the sample references and zone data (since each horn/horns is sampled very deeply). That’s also why there is a significant difference between the All Mics and 1 Mix patches in terms of RAM when purged. It’s less than 25% of the zone data that has to get pushed into memory.
There were some specifics with MSB that made this such an extreme case, but it just goes to show how huge other considerations can be.
 
No, the overhead from non-sample sources can be vastly more than sample ram, especially with low preload buffers.
Or a shallow-sampled triangle :) Yes, of course any ratio can happen, but it seemed silly to consider examples that were trivial, mad or broken...
With Modern Scoring Brass, their Horns 1 patch consumed a staggering 1.2gb with no samples loaded on the first instance, then another 544mb for each succsssive one.
...or two of the above. Folks don't think of the instrument metadata weighing 1Gb because it's absurd. A third of the product's RAM spec goes on a single patch before samples are loaded? Did the instrument come with an operating system, or a free human genome or something?
 
Or a shallow-sampled triangle :) Yes, of course any ratio can happen, but it seemed silly to consider examples that were trivial, mad or broken...

...or two of the above. Folks don't think of the instrument metadata weighing 1Gb because it's absurd. A third of the product's RAM spec goes on a single patch before samples are loaded? Did the instrument come with an operating system, or a free human genome or something?
I'm honestly not sure what you're arguing here. I'm just telling you how it is.

Time was when the only thing to consider with Kontakt instruments was sample RAM. 15-20 years ago nkis were simple little things - UIs just vanilla Kontakt, scripts tiny, small numbers of zones.

Many modern instruments are like skyscrapers compared to mud huts. I just loaded NI's Arkhis - subtracting the amount of RAM that Kontakt itself uses on a first launch, it's 829mb. Kontakt itself reports (and Activity Monitor confirms) that the sample RAM uses with minimum preload buffers is 2.4mb - 0.2% of the RAM needed. And that's with samples fully unpurged.

It's surprising that so few people realise any of this, and just accept what Kontakt (or other sample player) reports at the header as the beginning and the end of it. Some synths can be real resource hogs, especially their first instances - VPS Avenger uses over 1GB of RAM on an init patch.

There are caveats - as I mentioned earlier RAM use reported by the OS is not a brick wall, some of it is what is reserved and not necessarily needed. Over time, figures can drop in my experience. And Apple's memory management can do all kinds of cool tricks to make those hard limits surprisingly flexible. But it doesn't change the basics, you will need a lot more RAM than that which is simply reported by the sample player.

This has all been something of a tangent from the OP, but it's nevertheless a critical one. You have to do some testing with the instruments you need to find what is actually possible with modest resources.

EDIT - I just did a comparison between LASS 2.5 and LASS 3 for a fully purged set of 5 instruments. LASS 2.5 is 760mb, LASS 3 is 2.5gb. Convenience comes at a pretty big cost.
 
Last edited:
16gb M2 Pro Mini here.
Another addition to the controversy. ;)

I can run a decent amount of Spitfire orchestra here without issues. In terms of buffer sizes etc, I use whatever 50% is of the default values in the Spitfire plugin. Any lower and I have issues with the multi-tongue patches.

Usual caveats about multiple mics etc, all covered in posts above.
 
Just want to check you don’t have more than one project open at a time - because you mentioned switching between projects?
 
  • Like
Reactions: Vik
I fell down this horrible wormhole of Virtual Instruments
Ah, that explains it. I knew I had seen you before. Hi!
next thing I know, hundreds of dollars (or more) later, here I am building fricken orchestras????.
With only 16 gb RAM, maybe you shouldn't even build orchestras/templates. But you may have made a very smart choice. You have bought two of the most advanced sampled string sections on the market: the Abbey Road V1 and cello, hopefully during a campaign. (The Spitfire cello and V1 file size is around 180gb on your hard drive – so the OS needs to fiddle around a lot in order to try to handle these instruments properly, but don't worry – these will be useful for many years to come.) And since truly powerful Macs are very pricey, it's good to start with something which lets you start to work right now (one track at a time), and sell that Mac + buy something more powerful later.

Performance is definitely unsatisfactory with some of these Spitfire Cello/ 1st Violins libraries in particular.
I don't have these (yet?), but in your case, I'd probably use them (for now) with only one mic option enabled, and only create the tracks you need – when you need them.

Maybe you even could consider a more bread/buttery library for now (for a much lower price than that V1/cello). Still, you can use the V1 for V1 and V2, and maybe the cello for viola as well (?) – or the V1 for viola unless you need the lowest half octave, and use Logic's factory library (or some other free libraries – there are loads of them out there) for bass (and viola).

Since which library and Mac you use of course is a lot less important than starting to develop music making skills – and since most well known existing symphonies out there are written without a computer and on a piano which most of the time wasn't really well tuned or well tempered, I wouldn't worry in your situation.

As others have told you experimenting with lower preload buffers is also recommended, but even on a 64 gb Mac Pro I had to raise my Kontakt buffer settings from 6k (I had reduced them from the 60k factory default) to something higher – for better performance.

It's good that you have the project(s) you actively work with internally, since another thing you IMO should consider is to have most of your tracks (actually all, except the one you are working on right now) 'frozen'. It sounds boring, I know, but freeze/unfreeze is fast on a M2 Mac, and mainly working with frozen tracks may represent a major improvement.

I even spent more money on more CORES, thinking that would future-proof things, but apparently that's not so important with this orchestral stuff, right?
More cores is a very good idea for orchestral stuff, but how many performance cores, and how many efficiency cores do you have? For this kind of work, what we want is many performance cores.

Re. Logic's audio settings: it's definitely worth trying out all the I/O buffer size options, but ARM Macs are different than Intel Macs. In some cases, higher buffer settings may mean less good performance, on others not.

Remember to not have an active track selected when you play back or edit: create dummy track with nothing on and have that selected – an important trick many users with really powerful Macs also use.

Is Processing Threads (still in Logic's audio preferences) set to automatic, or have you changed it? Have you tried all the three Process Buffer Range settings (Small, Medium, Large)? Sometimes, Large helps, but on some ARM Macs, Small occasionally helps too.

Maybe it's tempting to sell your M2 Mac (while you still can get a good price for it) and buy something with more RAM, but once you reach the RAM amount often considered as a healthy minimum (at least on Intel Macs, 64 gb), prices increase.

And it's already 2024, so 3nm Macs will maybe already this year get competition from 2nm chips, there will probably be M3 iPads and MacBook Air models on the market within circa a year – and this won't stop. Personally, I got into the recording studio thing since I knew a student who had spent so much time on building that studio, learning about which gear he needed etc, that he didn't have time to use it since he also needed to study. He just gave me the keys and ended ip never making music. Don't fall into that trap he fell into! :)
 
Last edited:
I'm honestly not sure what you're arguing here. I'm just telling you how it is.
More exclaiming than arguing: those amounts of memory just don't make sense for the data you're describing, by a couple of orders of magnitude. I don't know if there's a missing detail in the memory figures you're quoting - you don't say which... resident dirty footprint? - or if Audiobro made a mistake in their work, or if this is somehow a feature of Kontakt. I'd hoped to poke around a memory map at some point today to see which, but no time so far.
 
More exclaiming than arguing: those amounts of memory just don't make sense for the data you're describing, by a couple of orders of magnitude. I don't know if there's a missing detail in the memory figures you're quoting - you don't say which... resident dirty footprint? - or if Audiobro made a mistake in their work, or if this is somehow a feature of Kontakt. I'd hoped to poke around a memory map at some point today to see which, but no time so far.
Gotya.

It's not really a mistake, it's just the inevitable consequences of vastly more complex instruments. As I mentioned, Arkhis from NI is very heavy resource-wise too, plenty of others. Audiobro is the most severe case for me personally, I think their instruments are the most complex under the hood.
 
It's not really a mistake, it's just the inevitable consequences of vastly more complex instruments.
Ok, but are you echoing AB’s explanation, or do you know that because you know how that memory is being spent (and, again, which memory metric you’re quoting?) I really do want to understand where that memory is going because the amounts are so far from any sanity check I can come up with… and these are impactful amounts too.

If AB’s explanation just boils down to “it’s complex”, then that seems a bit of a “don’t worry your pretty little head about it” explanation… and I refuse to be patronised by a trumpet ;)
 
Ah, that explains it. I knew I had seen you before. Hi!

With only 16 gb RAM, maybe you shouldn't even build orchestras/templates. But you may have made a very smart choice. You have bought two of the most advanced sampled string sections on the market: the Abbey Road V1 and cello, hopefully during a campaign. (The Spitfire cello and V1 file size is around 180gb on your hard drive – so the OS needs to fiddle around a lot in order to try to handle these instruments properly, but don't worry – these will be useful for many years to come.) And since truly powerful Macs are very pricey, it's good to start with something which lets you start to work right now (one track at a time), and sell that Mac + buy something more powerful later.


I don't have these (yet?), but in your case, I'd probably use them (for now) with only one mic option enabled, and only create the tracks you need – when you need them.

Maybe you even could consider a more bread/buttery library for now (for a much lower price than that V1/cello). Still, you can use the V1 for V1 and V2, and maybe the cello for viola as well (?) – or the V1 for viola unless you need the lowest half octave, and use Logic's factory library (or some other free libraries – there are loads of them out there) for bass (and viola).

Since which library and Mac you use of course is a lot less important than starting to develop music making skills – and since most well known existing symphonies out there are written without a computer and on a piano which most of the time wasn't really well tuned or well tempered, I wouldn't worry in your situation.

As others have told you experimenting with lower preload buffers is also recommended, but even on a 64 gb Mac Pro I had to raise my Kontakt buffer settings from 6k (I had reduced them from the 60k factory default) to something higher – for better performance.

It's good that you have the project(s) you actively work with internally, since another thing you IMO should consider is to have most of your tracks (actually all, except the one you are working on right now) 'frozen'. It sounds boring, I know, but freeze/unfreeze is fast on a M2 Mac, and mainly working with frozen tracks may represent a major improvement.


More cores is a very good idea for orchestral stuff, but how many performance cores, and how many efficiency cores do you have? For this kind of work, what we want is many performance cores.

Re. Logic's audio settings: it's definitely worth trying out all the I/O buffer size options, but ARM Macs are different than Intel Macs. In some cases, higher buffer settings may mean less good performance, on others not.

Remember to not have an active track selected when you play back or edit: create dummy track with nothing on and have that selected – an important trick many users with really powerful Macs also use.

Is Processing Threads (still in Logic's audio preferences) set to automatic, or have you changed it? Have you tried all the three Process Buffer Range settings (Small, Medium, Large)? Sometimes, Large helps, but on some ARM Macs, Small occasionally helps too.

Maybe it's tempting to sell your M2 Mac (while you still can get a good price for it) and buy something with more RAM, but once you reach the RAM amount often considered as a healthy minimum (at least on Intel Macs, 64 gb), prices increase.

And it's already 2024, so 3nm Macs will maybe already this year get competition from 2nm chips, there will probably be M3 iPads and MacBook Air models on the market within circa a year – and this won't stop. Personally, I got into the recording studio thing since I knew a student who had spent so much time on building that studio, learning about which gear he needed etc, that he didn't have time to use it since he also needed to study. He just gave me the keys and ended ip never making music. Don't fall into that trap he fell into! :)
Thanks for this great information!
 
Ok, but are you echoing AB’s explanation, or do you know that because you know how that memory is being spent (and, again, which memory metric you’re quoting?) I really do want to understand where that memory is going because the amounts are so far from any sanity check I can come up with… and these are impactful amounts too.

If AB’s explanation just boils down to “it’s complex”, then that seems a bit of a “don’t worry your pretty little head about it” explanation… and I refuse to be patronised by a trumpet ;)
It does track - when I deleted the zones I didn't need under the hood in the nkis, the memory consumption dropped dramatically. Two instances of Horns 1 (for longs and shorts) were nearly 2GB, it dropped to 880mb or something. Still quite hefty, but it does still have to function after all...
 
It does track - when I deleted the zones I didn't need under the hood in the nkis, the memory consumption dropped dramatically.
Yes, deleting stuff from memory will usually have that effect. It's the magnitude that needs to be explained.
 
Yes, deleting stuff from memory will usually have that effect. It's the magnitude that needs to be explained.
Just to be clear - this is deleting zones in Kontakt, which in turn reduces memory. Of course the ordinary user cannot do this blindly, in the case of Audiobro they gave specific instructions so I only had zones for longs in the longs patch, and zones for shorts in the short.

As to magnitude, I've said it every which way now - these instruments are absolute goliaths. Take a look under the hood at what is going on. It's insanely complex - we all rely on great scripting, tons of velocity layers and mic positions, scores of UI gizmos on top. And it's maths, each layer multiplies the total, it doesn't add to it.

Pretty much any modern serious instrument is going to have a footprint that will greatly exceed the minimum preload buffers. Symphobia's lovely all-in-one patch takes 1GB before you load a single articulation. I still have their 1.1 instruments and any basic instrument patch is 25mb.

That's a pretty good illustration of how instruments have changed over the past decade. And that's a good tip for those who need to conserve RAM - do your homework if you can to help you decide which libraries to buy, or which patches to use. It's not easy though, as this thread proves it's hard to get this info and many people don't have any idea that it is even an issue.
 
Just to be clear - this is deleting zones in Kontakt, which in turn reduces memory.
I understood.

As to magnitude, I've said it every which way now - these instruments are absolute goliaths. Take a look under the hood at what is going on. It's insanely complex
But these are just tautologies: "they're big because they're big"; "they're big because they were smaller and got bigger". An explanation, on the other hand, would look like "each zone entry refers to a sample's full pathname and there's no dedupe" (though that would require ~3million entries to get to 1.5GB.)

I've worked on plenty of systems more complex than this, and even those involving some flabby interpreted DSL had a significantly smaller footprint.

I mean, wouldn't it be a bit annoying (yet useful) to discover it was 1.5GB of sample filenames?
 
Top Bottom