# Kontakt RAM usage between multiple instances?



## Oliver.T (Mar 13, 2021)

Hi all!
As I am working slowly to find the optimal way to build an orchestral template in OTR, I stumbled upon an unexpected behaviour of Kontakt (for me at least). It appears that the values for the RAM footprint in the expert view/Engine are the same in each simultanious instance of Kontakt. And with every new patch loaded the numbers grow in every instance simultaniously and identically, regardless which instance I load it to. So, contrary to my knowledge so far, my reasoning is now that Kontakt somehow handles the RAM globally, on some "root level", and not per instance. 
At first I was very pleased by this, beause it seams that if two of the same patches are loaded even in different Kontakt instances, Kontakt shares the RAM footprint, and not just for the samples, but also for everything else. In other words, if I copy an instance with some patch(es) on it, the second instance doesn't take up RAM (except the base footprint per instance). This contradicts with some info that I gathered through time, mostly here, so prease, correct me if I'm wrong.
But the main, to me rather disconcerting thing, is that if I freeze or deactivate an instance I get no benefit RAM-wise whatsoever. It seems that Kontakt leaves the content from the deactivated instance allocated to RAM regardless!? And in the engine view of any one of the remaining active instances I see roughly the same numbers as before deactivating, only some nonsignificant amount lower, like 30-40MB.
Only if each and every single instance of Kontakt is deactivated, freazed, or removed completely, than the RAM footprint drops to "base" value of a Reaper empty project. And this would actually be a (rather cumbersome and extremely non-practical) way around this. Everytime I want to alleviate the RAM footprint I have to freaze/deactivate everything (unloads everything from RAM), and than activate just the instance needed (loads in RAM only that one active instance). But I think it's obvious that this is far from the solution. Its almost unimaginable to do this every time I want to make some memory space, and as soon as I start activating more instances, it snowballs right back into RAM hell, and fast. 
I really hope I'm missing something, please someone tell me how dumb I am for not figuring it out! By the way, I use the latest Kontakt 6.5.2. Thanks


----------



## Oliver.T (Mar 13, 2021)

Edit: sorry for my hastely drawn conclusions, I have just now made some more tests, and it seems that only the sample content is shared between instances. However deactivating a track with an instance, while another exact copy of the track is still active (and both globally purged) doesn't seem to do much. When added, first multi patch (purged) adds roughly 4.5Gb, the second (copy/pasted) adds only 3.5Gb, but after a few times activating/deactivating, it rises to roughly 4.5Gb too. 
Deactivating just the second instance alleviates only about 1.5Gb, which is dissapointing. Deactivating just the first alleviates onli a freakin 150Mb!? When both are deactivated it goes to base Reaper footprint (around 750-800Mb), so it must be that most of the memory still hangs in the still active instance. 
When activating just one instance, after the two being deactivated, it goes to just adding 4.5Gb, same as at the beginning. So after everything is being deactivated, only then are we at base RAM! And after that, with every new instance it starts to snowball again. 
Arithmetically this makes close to no sense to me, and I cannot find the logic behind this. What's worse, even the good side of it (as I wrote in my first post) came up to be a testing error on my behalf... 
I really hope someone much wiser than me will have some answers...


----------



## stixman (Mar 13, 2021)

Follow the hobbit to the lair of the evil dragon


----------



## jcrosby (Mar 14, 2021)

Oliver.T said:


> Hi all!
> As I am working slowly to find the optimal way to build an orchestral template in OTR, I stumbled upon an unexpected behaviour of Kontakt (for me at least). It appears that the values for the RAM footprint in the expert view/Engine are the same in each simultanious instance of Kontakt. And with every new patch loaded the numbers grow in every instance simultaniously and identically, regardless which instance I load it to. So, contrary to my knowledge so far, my reasoning is now that Kontakt somehow handles the RAM globally, on some "root level", and not per instance.
> At first I was very pleased by this, beause it seams that if two of the same patches are loaded even in different Kontakt instances, Kontakt shares the RAM footprint, and not just for the samples, but also for everything else. In other words, if I copy an instance with some patch(es) on it, the second instance doesn't take up RAM (except the base footprint per instance). This contradicts with some info that I gathered through time, mostly here, so prease, correct me if I'm wrong.
> But the main, to me rather disconcerting thing, is that if I freeze or deactivate an instance I get no benefit RAM-wise whatsoever. It seems that Kontakt leaves the content from the deactivated instance allocated to RAM regardless!? And in the engine view of any one of the remaining active instances I see roughly the same numbers as before deactivating, only some nonsignificant amount lower, like 30-40MB.
> ...


Samples are shared among instances. As far as samples being unloaded when deactivated, this all comes down to your DAW. Logic for example doesn't use any RAM for a deactivated track until activated. I believe Cubase and Studio One behave the same way (but not 100%), Live on the other hand keeps eating memory even if you deactivate the plugin. CPU goes down, but RAM usage sticks... Then again Ableton do a lot of things sloppily 

As far as additional RAM... Yeah that sounds correct. Last time I checked this it was about 30 MBs and change per Kontakt instance. I don't have a technical explanation outside of the fact that kontakt has a lot of resources that need to be immediately available upon activation. Scripts, graphics, quickload info, a database, probably even some information about the script loaded, and/or some information about the memory allocation the patch requires. Pretty sure its an unavoidable reality regardless of DAW... And probably because of memory allocation at the OS level, not Kontakt's actual code per se...

The tradeoff is that some DAWs (Logic for example) run Kontakt much more efficiently with one instance per track. Other DAWs handle multi-timbral instances of Kontakt more efficiently. That said I tested this recently with a VEP template that was getting near the knife's edge when I had an almost full arrangement and I found even VEP handled discrete instances more efficiently than multi-timbral. (Even after trying all of the usual suspects... Various thread numbers in VEP, multi-threading off in kontakt, even different thread numbers enabled in Kontakt, etc. I basically exhausted every variable I could think of)...

I had one instance with a bunch of Damage 2's and VEP couldn't play back a single channel of the muti-timbral instance without immediately choking, whereas the discrete instances could play a few channels before tapping out.

Basically if you haven't done comparisons yet, see if Reaper handles multi-timbral instances of Kontakt more or less the same as discrete instances.. If there's virtually no difference than your best solution's probably to use multi-timbral instances wherever needed...


----------



## Oliver.T (Mar 14, 2021)

Thanks for answering @jcrosby . Its good that someone at least confirms some of my suspicions. I is also my reasoning that sample memory is being shared, and most other things not. The samples actually work for me as expected RAM-wise, purging and all. 
Even accepting that however, my main concern is the inabillity to alleviate some of the RAM by deactivating a single instance(s), while having others active. It appears that there is no discrete amount of RAM that is allocated to a single instance, and this one only. It seams to me that as long as a single one instance is active, Kontakt will cling to each and every RAM piece that had ever been loaded previously in the project. It doesn't matter which Kontakt instance this memory has been loaded into, they need only to exist in the same project. And than it's like a global, project-level RAM pool, that either stays completely full with all the crap you've loaded into it, or flushes flat to zero. It seems that even content from patches that are once loaded, but deleted afterwards still hangs in RAM. 
I beleave it is not the case that Reaper doesn't unload RAM when deactivating tracks, because with all the instances deactivated or freezed the memory goes back to base. So, that is why I suspect that it's Kontakt-related. Maybe i'm wrong. 
I have been researching a bit since, and found a thread on this topic, at least very similar: 





Huge issue with Kontakt not unloading RAM


Hi everyone, I'm having a really bad time with Kontakt since yesterday, when I first noticed the RAM load of a track instance didn't go down anymore when disabling or freezing the track in Cubase. I tried more scenarios to try identifying the problem and it's crazy. In Cubase : - Opening /...




vi-control.net




It is a Cubase issue, however @storyteller, the guy behind OTR gets involved, claiming the same issue. They say at the end that it's Kontakt issue, and Kontakt 6.5 update should resolve it (apparently not?) 
Also I read on few places that this could be Win 10 thing, RAM still hanging in cashe, in case it's needed again, and as soon as some other process demands it, it unloads the cashe and reallocates resources. I have yet to investigate that.


----------



## storyteller (Mar 14, 2021)

There is something still weird with Kontakt and ram allocation. I was originally thinking it might be a Reaper issue... or maybe a Reaper + OSX issue, but I don’t think it is anymore. To @Oliver.T’s point, Reaper is not releasing ram when Kontakt is deactivated or frozen. And, there is some additional weirdness going on with individual instances vs multitimbral. While it is true that individual instances will add a slight overhead to each track, if I currently take, say, Berlin Woodwinds and load up every articulation on individual tracks, it takes well over 20GB of ram, compared to the multitimbral setup of 13GB. Same thing with any other library. This was not the behavior until recently (I am not sure where it went sideways though. I just noticed it when I posted in that last thread).

Strangely, once a track is frozen or deactivated in reaper, you can reclaim some of the ram by using a ram manger and continually purging the ram. It will NOT reclaim the ram with one memory purge attempt though. You have to try to do this multiple times in a ram manager app and it still will not reclaim the whole amount.

I’m currently back to this being a Kontakt issue... but I also haven’t had a chance to test all of the possibilities on different OSs though.


----------



## Oliver.T (Mar 14, 2021)

Thanks, @storyteller ! Have you perhaps invastigated a bit if its OS' cashe ram management thing, and therefore benign (meaning the memory just sits there in cashe, but it flushes as soon as you load something else that needs more memory space)? Being that you're on Mac, this is a real long shot... Or perhaps Kontakt behaves in similar way, cashing the memory? I try to think a practical way to test this...
And if it's a Kontakt issue, I wonder how so few people actually reported this problem?...

Edit: just to add a perspective, there are at least few reports of this behaviour in Reaper, but also at least one in Cubase so that points to Kontakt as the culprit. On the other hand, I found report of similar behaviour in older versions of Reaper (5, I think), that does not involve Kontakt, other plugins rather - like Omnisphere and some effects - that contradicts the assumption above.
Also, at least in my case, the sample content seams to work properly: the reported sample memory gets flushed when purging. In my test case, say with Spitfire Chamber Strings multi, with everything being loaded in one instance and using (all palletts + perf legato + legacy legato), sample memory is around 3.5Gb and all the other stuff more than 4.5Gb, so when it's purged it reports 4.5Gb + about 0.8Gb base OTR memory. 
And the worst thing of all is that even the removed patches are being kept in memory except samples.


----------



## storyteller (Mar 14, 2021)

Oliver.T said:


> Thanks, @storyteller ! Have you perhaps invastigated a bit if its OS' cashe ram management thing, and therefore benign (meaning the memory just sits there in cashe, but it flushes as soon as you load something else that needs more memory space)? Being that you're on Mac, this is a real long shot... Or perhaps Kontakt behaves in similar way, cashing the memory? I try to think a practical way to test this...
> And if it's a Kontakt issue, I wonder how so few people actually reported this problem?...


It does report as "cached" in the ram management, but when I initially was working through the design of OTR, I know for a fact that the ram was reported as "released" when tracks were disabled or frozen. It hasn't been until recently I've had to dig into this issue since my template has been "set it and forget it" over the years. But the ram usage started becoming noticeable lately which is why I've had to start exploring this.

It *might* be possible that this is some underlying OS mechanism with Apple since they are moving to the "unified memory" on the M1s. Perhaps they changed the reporting and caching process over the years to prepare for the migration to their new architecture. All I know now is that I "run out" of ram a lot more quickly now and I see the compressed section begin to go up at that point. Kontakt USED to report its ram as "WIRED" which would flush on a track freeze or deactivation since the "wired" ram was now "unwired." 

In further testing, it appears Kontakt 5.8 and 6.x behave similarly, albeit not identically which is now making me think this has been embedded in OS updates throughout the years.

At the end of the day, I guess it really matters whether or not performance is the same, regardless of what is being reported. That is more difficult to test, but maybe we can get to the bottom of it.


----------



## Oliver.T (Mar 14, 2021)

storyteller said:


> At the end of the day, I guess it really matters whether or not performance is the same, regardless of what is being reported.





storyteller said:


> It hasn't been until recently I've had to dig into this issue since my template has been "set it and forget it" over the years. But the ram usage started becoming noticeable lately which is why I've had to start exploring this.





storyteller said:


> All I know now is that I "run out" of ram a lot more quickly now and I see the compressed section begin to go up at that point.


So, from this I gather that you already experienced the diminishing performance. I am farely new to OTR and Reaper too, so I can't speak from my experience.


storyteller said:


> It *might* be possible that this is some underlying OS mechanism with Apple since they are moving to the "unified memory" on the M1s. Perhaps they changed the reporting and caching process over the years to prepare for the migration to their new architecture.


True, but could it be that Win 10 also exibits the same or similar issue with Kontakt? I am by no means tech guy, and haven't delved into the technical stuff of Kontakt before, as I never before have been working with templates, but this behaviour of Kontakt+Win is rather unexpected to me. At this point I really suspect Kontakt to be the main culprit.

The ram menaging thing that you do seems to me like the best workaround candidate at this point in time. I have yet to find some app and further investigate if it gets the job done on Win 10. I'll post my findings here. 

Also, I would like to express my deepest gratitude for OTR. I am still learning it (and Reaper at the same time), but as I delve deeper it seams to be the Holy Grail that I've been looking for for a long time!


----------



## stigc56 (Mar 14, 2021)

Sorry to ask, but what is OTR?


----------



## Oliver.T (Mar 14, 2021)

stigc56 said:


> Sorry to ask, but what is OTR?


It is a customization of the Reaper platform that adapts it for work with orchestral templates. Preorganized folder structure, ready-made but also customizable audio/midi routing matrix, stereo and quad mixing, automated batch export for stems, VCA control, custom menus for bouncing, visibility, really usefull midi editing features, many custom actions (MIDI/OSC assignable), ready-made track templates and the ability to make your own, track packs... and much more! Really cool stuff, courtesy of @storyteller 
http://otr.storyteller.im/


----------



## Joakim (Mar 14, 2021)

I'm struggling trying to understand the issue here. Depending on which mode you run a plug-in in it will behave slightly different.

If you right click a plug-in in the list where you add them from, there you can change their "bridging/firewall" behaviour individually.






If it runs as a "Separate process" the sample memory will be shared, and you will have to completely unload all instances of Kontakt that uses the same sample library for it to finally be unloaded.

If you run your Kontakt as a "Dedicated process"(This is the most crash resilient mode) they will all be completely individually managed, the samples will not be shared between the same libraries and each track you "freeze/unload/deactivate" will unload that Kontakt instance from memory. But this leads to overall more memory usage if you have the same library loaded in more than one place.

You should probably not use "Native only" as it behaves similarly to "Separate process" but if the plug-in crashes it might take the entire DAW down with it.

It behaves exactly as expected for me when unloading tracks(only some negligible amount of data remains in RAM until you remove the entire plugin from the track), Windows 10, Kontakt 6.3.1


----------



## storyteller (Mar 14, 2021)

Oliver.T said:


> So, from this I gather that you already experienced the diminishing performance. I am farely new to OTR and Reaper too, so I can't speak from my experience.
> 
> True, but could it be that Win 10 also exibits the same or similar issue with Kontakt? I am by no means tech guy, and haven't delved into the technical stuff of Kontakt before, as I never before have been working with templates, but this behaviour of Kontakt+Win is rather unexpected to me. At this point I really suspect Kontakt to be the main culprit.
> 
> ...


Well, I will say that if you make sure to do a global purge within Kontakt after you load an instrument, you can reclaim that memory usage. For example, if you load a lib that takes up 1gb of ram, immediately purge the samples. Then, deactivate the track. The 1gb is now floating somewhere out in the “cache” within the OS so you can either reclaim it by using a ram management app, or you can just rely on the OS to manage it. If you save your project at this point and close out reaper and reopen reaper and your project, you will see that your template is not consuming that 1gb of ram. When you activate the track, you will also see that Kontakt will NOT try to load 1gb of samples. So your ram usage stays clean.

This is NOT how it used to behave. It used to load the instrument into ram as “wired” ram. This basically builds a stronghold or a fort around that amount of ram so that it cannot be used by anything else. When you deactivated the track, that ram was released and the OS would show your ram usage as if you had never loaded the instrument. This caching thing that is going on is the culprit right now. Maybe it was a new feature in a Kontakt update, but K5.8 is exhibiting similar behavior too. I did make OSX hard crash to cold reboot with K5 in testing though. If you use a ram management app to purge the ram, K5 sometimes just blips and crashes. Again, this was not the behavior before so I really don’t know what has changed... whether it is the Kontakt code or what, I’m not sure. Maybe it was that Intel exploit which was mandatorily patched by both Microsoft and Apple a few years ago. I think that exploit supposedly dealt with stack overflows in the ram, so maybe this was the fix at an OS level?

*Edit: Also, OTR 2.0 is in the works. Can’t share much right now, but it is going to be a VERY nice overhaul to OTR. Hopefully I can get it released soon!*


----------



## Oliver.T (Mar 14, 2021)

Joakim said:


> If you run your Kontakt as a "Dedicated process"(This is the most crash resilient mode) they will all be completely individually managed, the samples will not be shared between the same libraries and each track you "freeze/unload/deactivate" will unload that Kontakt instance from memory.


@Joakim , thank you for this tip! While researching this issue I've stumbled upon this, however I've forgotten about it. I am new to Reaper, so it's a bit all at once for me. However, I tried it and it works as you say. I noticed however that there is some difference between deactivating different multis: some unload right away, and some cling a bit, and than disappear. Those that cling appear grayed out in Resource monitor/Memory lane and I presume they are already flushed from memory, because after a short while the entire process is gone from the list. It could be that somehow Kontakt used to have the "Dedicated process" setting as a default before, but has changed it since... or maybe Reaper changed something in the default settings that affects handling Kontakt?? I could easily see myself missing something like that... However, it works and I guess I wouldn't mind not sharing the sample pool between instances (for now at least), because the whole point was to claim the RAM back by deactivating/freezing tracks.


Joakim said:


> I'm struggling trying to understand the issue here. Depending on which mode you run a plug-in in it will behave slightly different.


My main issue was that as I was loading patches and than unloading them, the memory content would not release properly, leaving fairly big chunks of the unloaded patches into ram. And I am not talking about samples, but the other stuff. I am well aware that two identical patches would share the same sample pool, so in order to release it from ram, I have to purge both. I am not an expert by a long shot, but I do think there is something there. I think @storyteller is much more credible source than me. 
Also I see you are using Kontakt ver: 6.3.1, maybe this is why you are not experiencing the issue...
Many thanks though, this really is great solution! Cheers


----------



## Oliver.T (Mar 14, 2021)

storyteller said:


> The 1gb is now floating somewhere out in the “cache” within the OS so you can either reclaim it by using a ram management app, or you can just rely on the OS to manage it.





storyteller said:


> This is NOT how it used to behave. It used to load the instrument into ram as “wired” ram. This basically builds a stronghold or a fort around that amount of ram so that it cannot be used by anything else. When you deactivated the track, that ram was released and the OS would show your ram usage as if you had never loaded the instrument.


So, it might just be a OS cache thing, and I/we are overreacting...? :D Well, in my defense, I wanted to plan ahead and build my template as efficiently as possible. I was so happy when I found OTR, I had all these plans for my template... and then this thing made me panic a bit.


storyteller said:


> Also, OTR 2.0 is in the works. Can’t share much right now, but it is going to be a VERY nice overhaul to OTR. Hopefully I can get it released soon!


No doubt it will be awesome! To be honest, I just found out that 1.8 is out. Already downloaded it and read what's new. I have yet to update and see for myself. Can't wait for 2.0 though! If I may, I really think you should integrate Reaticulate in OTR. The thing is killer! Although I have done so manually, and it works flawlessly so far, so no need for much work here. But maybe you and @tack would think of something even more awesome :D


----------



## storyteller (Mar 14, 2021)

Oliver.T said:


> So, it might just be a OS cache thing, and I/we are overreacting...? :D Well, in my defense, I wanted to plan ahead and build my template as efficiently as possible. I was so happy when I found OTR, I had all these plans for my template... and then this thing made me panic a bit.
> 
> No doubt it will be awesome! To be honest, I just found out that 1.8 is out. Already downloaded it and read what's new. I have yet to update and see for myself. Can't wait for 2.0 though! If I may, I really think you should integrate Reaticulate in OTR. The thing is killer! Although I have done so manually, and it works flawlessly so far, so no need for much work here. But maybe you and @tack would think of something even more awesome :D


Thanks! Reaticulate is fully integrated in 2.0  He gave me the blessing to include it some time ago, but I was waiting for the changes I was making in 2.0 to fully integrate it. Let me know if you have any questions with OTR as you are building your template. Whatever the issue may be with Kontakt, it hasn't affected overall performance that I can tell, but watching my ram meter get maxed out is a little unsettling. Ha. I do think it is likely a cache thing though. Just be sure to purge your instrument in Kontakt before disabling it the first time as you are setting up your template. That will keep the ram usage as low as possible in the disabled state and as low as possible when it is activated. You'll only need to worry about the Kontakt purge sample thing when you are setting up your template the first time. You would have needed to do that regardless of the current ram issue we are discussing.


----------



## jcrosby (Mar 14, 2021)

Oliver.T said:


> It seems that even content from patches that are once loaded, but deleted afterwards still hangs in RAM.


Scratch my long reply.. It's pretty much been explained above. What you're seeing is file caching. It's is totally normal, and is OS specific not Kontakt-related.

This link looks like it should explain things pretty clearly...








Memory Caching


Memory caching is a technique in which computer applications temporarily store data in a computer’s main memory to enable fast retrievals of that data.




hazelcast.com


----------



## Oliver.T (Mar 15, 2021)

jcrosby said:


> Scratch my long reply.. It's pretty much been explained above. What you're seeing is file caching. It's is totally normal, and is OS specific not Kontakt-related.
> 
> This link looks like it should explain things pretty clearly...
> 
> ...


Yeah, I get it now... As I said at the beginning, I hope someone would tell me how dumb I am for not figuring it out :D I read your long reply too, and this before:


Oliver.T said:


> So, it might just be a OS cache thing, and I/we are overreacting...?





storyteller said:


> Whatever the issue may be with Kontakt, it hasn't affected overall performance that I can tell, but watching my ram meter get maxed out is a little unsettling. Ha. I do think it is likely a cache thing though.


My panic attack has subsided :D Thanks to all for clearing that up for me.


----------



## jcrosby (Mar 15, 2021)

It's definitely counter intuitive until you learn about file caching! I didn't really understand this until a few years ago after reading up on memory compression. 
Cheers!


----------



## mscp (Mar 15, 2021)

One Kontakt 6 instance without loading anything in it takes up ~600 megs over here. I've tried to understand why but I kind of gave up.


----------



## EvilDragon (Mar 16, 2021)

Do you have a lot of things in your database? Empty Kontakt instance is roughly 200 MB over here.


----------



## mscp (Mar 16, 2021)

EvilDragon said:


> Do you have a lot of things in your database? Empty Kontakt instance is roughly 200 MB over here.


It may? lol.
I'll have a look later on.


----------



## Oliver.T (Mar 16, 2021)

Phil81 said:


> It may? lol.
> I'll have a look later on.


Yeah, that does it. Recently I too removed everything from database, I think it's now about 170Mb.


----------

