# Kontakt instrument pre load buffer size



## jtnyc (May 17, 2019)

Hi -

I noticed my Kontakt instrument pre load buffer size box is unchecked. I suppose it's always been that way. Can anyone tell me if that's the default position. If not, should it be checked? If so, is the default of 60kb a good place for it to be? I googled and I see a lot about how it works and different settings for different drives etc, but I'm still wondering if I need it on at all. Do nki's have built in pre load sizes that are best for that specific instrument, making it best to leave the box unchecked?

Thanks for any info -


----------



## keepitsimple (May 18, 2019)

You gotta experiment and find out for yourself. I leave it unchecked.


----------



## EvilDragon (May 18, 2019)

By default it's unchecked, yes. Default of 60 KB is for very old hard drives. If your libraries are all on SSDs you can freely push it to the lowest value.

Great majority of NKIs has that parameter set at the default 60 KB, as well, which is really not taking modern SSDs into the account.

Since I run a mix of SSDs and HDDs, I have it set at 18 or sometimes 24 KB and it's all dandy. Shame Kontakt doesn't allow setting this per drive, that would be ideal.


----------



## jtnyc (May 20, 2019)

I'm still running my samples off of 7200 platter drives. Things run ok. I'm was just wondering if checking the box and adjusting the size might improve things.

Still not sure - I did fool around with a bit, but I wasn't clear on which way to go, bigger or smaller. Couldn't really tell. Maybe I have to try again.


----------



## EvilDragon (May 21, 2019)

Bigger: more RAM usage but drives get time to breathe. Smaller: less RAM usage but drives don't get a breather. Unless it's an SSD because they eat everything up.


----------



## Carson (May 21, 2019)

EvilDragon said:


> Bigger: more RAM usage but drives get time to breathe. Smaller: less RAM usage but drives don't get a breather. Unless it's an SSD because they eat everything up.


I always get excited when you speak  Does smaller have any effect on CPU? For live performance, would you recommend lowering the number? We use SSDs.


----------



## Steve Steele (May 21, 2019)

Check out my video on the subject. I believe the Preload Buffer section starts at 9:57. I go into quite a bit of detail. Hope it helps.


----------



## Carson (May 21, 2019)

You rock. Answered my question.


----------



## BezO (May 21, 2019)

@nightwatch I remember watching your vid a while back and it helped a great deal (2017 MBP, 2.8 GHz i7, 16GB RAM). But one aspect I never implemented was the manual RAM management starting at 20:53. How do you open that screen to enter the terminal command? And is that something I need to turn off afterwards? If so, how would I do that? Or is it OK to just exit?

Also, is there a RAM usage % I should try to stay under? Luckily I don't do full blown orchestral compositions like many of you, but I'm consistently tapping 11-12GB of my available 16GB. But I typically have breathing room on the CPU usage.


----------



## EvilDragon (May 21, 2019)

You don't really have to watch out a particular % of RAM. Obviously if you're close to full RAM you should close something, but other than that, nope. It's not like CPU. 


And yes, if you lower the DFD buffer size, obviously there will be more read requests towards the HDD/SSD, but this is something modern CPUs can handle without an obvious penalty just because you're reading from the drive more often. In fact, it is the fact that SSDs allow you to stream a lot more concurrent voices (due to their much faster random seek times and in general vastly improved random read speeds over traditional HDDs) compared to HDDs, and of course, when you play (a lot) more voices they will require more CPU to _process them_. The actual disk I/O request penalty is _negligible by comparison_.


This article (actually, the linked PDF in the article) should help in understanding DFD. Yes, it's from Kontakt 2 times and before SSDs, but it's still valid. 

https://support.native-instruments.com/hc/en-us/articles/209544589-What-is-DFD-


----------



## Carson (May 21, 2019)

Very helpful


----------



## BezO (May 21, 2019)

@EvilDragon yes, very helpful! Thanks!


----------



## EvilDragon (May 21, 2019)

It was funny reading this part again:

"4 Gigabyte is actually the limit for any 32-bit application. To this date no operating system even allows a single application this total amount."


----------



## Steve Steele (May 21, 2019)

BezO said:


> @nightwatch I remember watching your vid a while back and it helped a great deal (2017 MBP, 2.8 GHz i7, 16GB RAM). But one aspect I never implemented was the manual RAM management starting at 20:53. How do you open that screen to enter the terminal command? And is that something I need to turn off afterwards? If so, how would I do that? Or is it OK to just exit?
> 
> Also, is there a RAM usage % I should try to stay under? Luckily I don't do full blown orchestral compositions like many of you, but I'm consistently tapping 11-12GB of my available 16GB. But I typically have breathing room on the CPU usage.



With computers that have under 32GBs of RAM I recommend manually (actively) taking control over the way macOS handles memory swapping. 

Mainly for older systems like MacBook Pros and other systems who’s architecture only allowed for a max of 16GBs of RAM, Apple added “memory compression” and “cached memory” to the OS. These are great features for these systems. But I f you have a Mac Pro or any other Mac that can access 64GBs of RAM or more this isn’t something that needs to be considered (although I still purge a lot and I have 96GBs of RAM currently in my Mac Pros).

macOS uses memory compression and caching to re-launch recently used applications quickly and to instantly wake up from sleep. 

However you may not care about these features. Even though macOS intelligently cleans up after itself and otherwise takes care of itself, you can, via the Terminal app, nuke data in memory that may either cause macOS to page files or slow down the time it take for macOS to clear the cache and allow that space to be reclaimed as memory not used. 

Here are the instructions. DISCLAIMER: Using the “sudo” command makes you the root user, (the God of your computer that can destroy everything with one wrong keystroke - actually it’s not quite that bad but can be if you enter the right or wrong command). You have been warned. Only proceed with sudo if you understand the command you are entering. Sudo “tells” the OS to “just do it.”

1. In the Finder, under the Go menu open the Utilities Folder (or type Shift-Command-U).

2. Open the Activity Monitor and click on the Memory tab. Look at the bottom where “Memory Pressure” and “Cached Files” is listed. Move Activity Monitor to the side for a moment. 

2. Open the Terminal app. Don’t be afraid.

3. Copy and paste this command into Terminal without the quotes, “sudo purge”. Terminal will ask for your User Password. Type your password (you won’t see any feedback), hit Enter and...

4. Within seconds the Cached Memory and Memory Pressure size in the Activity Monitor shrink depending on how many apps and files you’ve had open throughout the day.

You can quit Terminal if you like. There is no further action required after using sudo purge. Nothing to “turn off.” Just quit the Terminal or keep it running. Doesn’t matter. You have made no changes (like a preference setting). Purging WILL NOT affect any running apps, only Cached data. It’s perfectly safe. If you’re paranoid you could save every app that is currently open before purging but it’s not necessary. macOS is a “protected memory” OS. UNIX baby!

This will instantly and manually reclaim memory for inactive memory. Apple says you may experience a slight slow down in the Finder but you won’t. The Kernel and other System and User processes quickly reclaims what they need. 

I hope this helps. 

Regards,
Steve Steele


----------



## Steve Steele (May 21, 2019)

nightwatch said:


> Check out my video on the subject. I believe the Preload Buffer section starts at 9:57. I go into quite a bit of detail. Hope it helps.




The only piece of advice that I now recommend for any sample library that has multiple mic positions (Spitfire, Berlin, just about everything these days), is to turn ON Kontakt’s Multiprocessor Support. _Without_ this on, if many mics are turned on Kontakt will overload a single core extremely fast. 

Rule of thumb. One instance of Kontakt without Multiple Processor Support threads to a single core. You could have 12 cores yet one of them is getting overloaded, because with MPS off Kontakt mostly attempts to work off of one core. 

This will be discussed in an upcoming video. Remember, my Kontakt video is almost four years old (although most of the advise still applies).

Regards, 
Steve


----------



## Carson (May 21, 2019)

nightwatch said:


> The only piece of advice that I now recommend for any sample library that has multiple mic positions (Spitfire, Berlin, just about everything these days), is to turn ON Kontakt’s Multiprocessor Support. _Without_ this on, if many mics are turned on Kontakt will overload a single core extremely fast.
> 
> Rule of thumb. One instance of Kontakt without Multiple Processor Support threads to a single core. You could have 12 cores yet one of them is getting overloaded, because with MPS off Kontakt mostly attempts to work off of one core.
> 
> ...


Any benefit to turning MPS off?


----------



## BezO (May 21, 2019)

nightwatch said:


> With computers that have under 32GBs of RAM I recommend manually (actively) taking control over the way macOS handles memory swapping.
> 
> Mainly for older systems like MacBook Pros and other systems who’s architecture only allowed for a max of 16GBs of RAM, Apple added “memory compression” and “cached memory” to the OS. These are great features for these systems. But I f you have a Mac Pro or any other Mac that can access 64GBs of RAM or more this isn’t something that needs to be considered (although I still purge a lot and I have 96GBs of RAM currently in my Mac Pros).
> 
> ...


Greatly appreciated!

I'm strongly considering and upgrade, likely to an iMac Pro, as this is getting serious for me again. Until then, these optimizing features will be in full effect.


----------



## EvilDragon (May 22, 2019)

Carson said:


> Any benefit to turning MPS off?



Some hosts might not like it. Test how it works with and without it. It works great in Reaper over here, I'd never want to turn it off.


----------



## Carson (May 22, 2019)

EvilDragon said:


> Some hosts might not like it. Test how it works with and without it. It works great in Reaper over here, I'd never want to turn it off.


Thanks ED!


----------



## topaz (May 23, 2019)

Did some tests here on Cubase 10 OSX 10.13.6 and MPS on gives way better results


----------



## Carson (May 29, 2019)

This may have saved my gig/a lot of work. Playing one of the Swing More! multis in MainStage - after a bit (if staying on the same patch ie practicing) CPU would start to spike, and get some crackles. Didn't happen with any other libraries, which are mostly Spitfire libraries. I ticked the box and slightly upped the buffer size. Seemed to have helped a bunch - placebo?


----------



## EvilDragon (May 29, 2019)

Probably not placebo. Higher DFD buffer size means somewhat less CPU usage and less strain on hard drive - but higher RAM load.


----------

