# Huge issue with Kontakt not unloading RAM



## Emmanuel Rousseau (Nov 18, 2020)

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 / enabling a Kontakt instance : RAM loads.
- Freezing / disabling the track : RAM doesn't unload.
- Deleting the instrument INSIDE Kontakt (using the "Reset Multi" function) : RAM doesn't unload.
- Deleting the entire Instrument track : RAM doesn't unload.
- Closing Cubase : RAM unloads.
- Opening / enabling a SINE instance : RAM loads.
- Freezing / disabling the SINE track (or removing the instruments inside SINE) : RAM unloads as usual.

In Kontakt standalone :
- Loading an instrument : RAM loads.
- Deleting the instrument (using the "Reset Multi" function) : RAM doesn't unload.
- Closing Kontat : RAM unloads.

This whole thing came out of nowhere after years of good service. I'm using Kontakt 6.4.2 on PC.

Any help hugely appreciated, this thing is a nightmare ! I have an immense load of work awaiting 

Many thanks !

Emmanuel


----------



## EvilDragon (Nov 18, 2020)

Kontakt's memory allocation didn't change in years (I think the last time it was updated was in 3.5 when 64-bit was introduced), AFAIK.


----------



## Emmanuel Rousseau (Nov 18, 2020)

EvilDragon said:


> Kontakt's memory allocation didn't change in years (I think the last time it was updated was in 3.5 when 64-bit was introduced), AFAIK.



Yeah it really doesn't make any sense :/ The latest version was already installed quite some time ago and the issue appeared yesterday.


----------



## Emmanuel Rousseau (Nov 18, 2020)

labornvain said:


> After you've frozen/disabled then saved, have you tried restarting Cubase and reloading the project?
> 
> Just curious.



Yes, when restarting Cubase and reloading the project, RAM is unloaded ! But this doesn't happen until I close Cubase. As I said, even removing the patches inside Kontakt doesn't remove the corresponding RAM.


----------



## EvilDragon (Nov 18, 2020)

OK so that's Cubase's memory management being screwy. But also, there's a bunch of different memory readouts in Task Manager...






Which one are you looking at?


----------



## Emmanuel Rousseau (Nov 18, 2020)

EvilDragon said:


> OK so that's Cubase's memory management being screwy. But also, there's a bunch of different memory readouts in Task Manager...
> 
> 
> 
> ...



Thank you @EvilDragon going to have a look tomorrow morning. 
Same thing happens in Kontakt standalone mode so I don't think Cubase is at fault here (for once! :D)


----------



## soundtrax (Nov 20, 2020)

EvilDragon said:


> Kontakt's memory allocation didn't change in years (I think the last time it was updated was in 3.5 when 64-bit was introduced), AFAIK.


I looks like there have been made changes from 6.2.2 to 6.4.2 regarding the memory allocation. At least here on my mac, I can confirm that 6.4.2 standalone and also the VST doesn't unload RAM anymore. 6.2.2 works fine.


----------



## EvilDragon (Nov 20, 2020)

Actually yeah, now I see it too. 6.3.x was also fine, so this was introduced with 6.4.0. I made @Yaron_NI aware.


----------



## Rasoul Morteza (Nov 20, 2020)

It's what I've been saying since early September...






The Purge...


No I'm not talking about the movie. Could someone please confirm that purging samples doesn't affect the actual amount of memory in use unless you entirely restart the host?(!) Purging samples, deactivating the track and even deleting the damn track doesn't release/flush the memory initially...




vi-control.net


----------



## Emmanuel Rousseau (Nov 20, 2020)

Damned ! I'm almost relieved you guys having the same issue :D At least it's not my system. Fingers crossed for a quick update !


----------



## Lionel Schmitt (Nov 20, 2020)

Breaking libraries (Spitfire, Slate and Ash etc - fixed but still... beta testing is a thing) and busting non supercomputers' memory is a great way to convince developers to stay with Kontakt.
Solid job guys.


----------



## EvilDragon (Nov 20, 2020)

Implying no beta testing happens. Understand that not everything can be found in time for release.


Anyways, I've been investigating this a bit, and it's not exactly a memory leak. Kontakt reserves the memory, and it does get reused if you load something else.


----------



## Emmanuel Rousseau (Nov 20, 2020)

EvilDragon said:


> Implying no beta testing happens. Understand that not everything can be found in time for release.
> 
> 
> Anyways, I've been investigating this a bit, and it's not exactly a memory leak. Kontakt reserves the memory, and it does get reused if you load something else.


Yes, it seems to acte like a memory cache, but I really can't see how it is an innovation... :/


----------



## toddkreuz (Nov 20, 2020)

I bought the update from Kontakt 4 to 6, so i have no original installer for Kontakt 6.

Does anybody have a 6.3 installer? The latest version is piling up ram until it crashes,
and i can't get anything done.


----------



## EvilDragon (Nov 21, 2020)

whitewasteland said:


> Yes, it seems to acte like a memory cache, but I really can't see how it is an innovation... :/



Nobody said this is innovation. It's quite clearly a bug, and Kontakt team has been made aware.


----------



## Emmanuel Rousseau (Nov 21, 2020)

EvilDragon said:


> Nobody said this is innovation. It's quite clearly a bug, and Kontakt team has been made aware.


Sorry man, I am french and my humor is terrible.


----------



## Smoy (Jan 18, 2021)

Hi everyone,
I've just run into this bug now and my workflow is basically screwed up because of that.

Did anyone found a workaround?


----------



## EvilDragon (Jan 18, 2021)

The behavior will be fixed in the upcoming 6.5 update.


----------



## Smoy (Jan 18, 2021)

Thanks @EvilDragon
Guess I'll roll back until the update, no super critical librairies are 6.4 mandatory on my end


----------



## storyteller (Jan 26, 2021)

EvilDragon said:


> The behavior will be fixed in the upcoming 6.5 update.


Do you know when we should expect the 6.5 update?


----------



## EvilDragon (Jan 27, 2021)

Soonish.


----------



## EvilDragon (Jan 27, 2021)

And the update is now live!


----------



## storyteller (Jan 27, 2021)

Well - after a quick test, it appears that it is pseudo-releasing the memory, but still not doing what it is supposed to do.

On OS X, it still shows as memory allocated to the app... in this case Reaper. I have to "purge my ram" in a ram management app several times to recover it fully. (And I have to punch the purge button numerous times in succession after each recovery for it to completely reclaim) But - I still managed to lose 2GB of ram by simply enabling a stack of disabled tracks, disabling them, re-enabling them, disabling them, enabling another small stack, disabling those, and then trying to purge my ram with a ram management app.

If you don't use a ram management app, it appears to the OS that Reaper is holding onto the whole sample pool memory allocation from Kontakt which is not the behavior Kontakt exhibited in previous releases. I will try updating to the latest Reaper and also rolling back Kontakt to confirm....

*UPDATE: *_Reaper 6.21 did improve the recoverability, but I still lose 1GB in this process. I suppose that is not horrible, but it is interesting none the less. Not sure how it will translate over a huge session. I also don't know if the misreporting of ram use to the OS will cause problems with moving it into a "compressed" state and not being recoverable... so the jury is still out for me as of yet. I will update further as I test in a large template._


----------



## soundtrax (Jan 27, 2021)

storyteller said:


> On OS X, it still shows as memory allocated to the app... in this case Reaper.


No memory issues here with K 6.5.0 and Cubase (MacOs Mojave) - when I delete Kontakt instances or NKIs in one single instance, the RAM gets released.


----------



## EvilDragon (Jan 27, 2021)

storyteller said:


> Well - after a quick test, it appears that it is pseudo-releasing the memory, but still not doing what it is supposed to do.


I assume you already double-checked that the plugin updated properly by clicking on KONTAKT logo in top left?

The memory load/unload behavior was completely reverted to the state prior to 6.4.0.


Also, in Reaper, how's this option in Preferences->Plugins->VST set up for ya?


----------



## storyteller (Jan 27, 2021)

EvilDragon said:


> I assume you already double-checked that the plugin updated properly by clicking on KONTAKT logo in top left?
> 
> The memory load/unload behavior was completely reverted to the state prior to 6.4.0.
> 
> ...


Kontakt is v6.5(R108), but I literally don't have that checkbox or option in Reaper preferences between the UAD and Enable Aria lines... There is just a blank space in the preferences. What wizardry are you using to reveal that option over there?


----------



## EvilDragon (Jan 27, 2021)

I guess being on Windows?


----------



## storyteller (Jan 27, 2021)

EvilDragon said:


> I guess being on Windows?


Well, I loaded it up in Windows (through Parallels) and enabled that check box in the Windows build of OTR (they share the same Reaper folder for compatibility for OTR distribution across platforms). I thought maybe toggling that preferences file through Windows might also affect OS X performance through a hidden toggle of sorts... but it didn't. Oh well. Still seems like an issue on OS X though... Maybe a Reaper bug instead of Kontakt? hmmm....


----------



## EvilDragon (Jan 28, 2021)

storyteller said:


> Maybe a Reaper bug instead of Kontakt?


That's what I'm thinking, possibly.


----------



## Emmanuel Rousseau (Jan 28, 2021)

I don't know why I didn't get any notifications for my own thread but anyway : updated Kontakt and this issue is now fixed indeed here  Thank you @EvilDragon !


----------



## storyteller (Jan 28, 2021)

EvilDragon said:


> That's what I'm thinking, possibly.


I posted over on the reaper forum in the bug section so at least they’ve been notified. it does seem to recycle the ram inside the app, but just never fully reports it as released Until you close Reaper.


----------



## Cory Pelizzari (Feb 2, 2021)

I've been having an issue where certain patches (from libraries like Rhythmus, Damage 2, Taiko Creator etc) seem to max out my physical memory percentage in task manager with only 8 patches (even though only 1G is loaded into Kontakt), whereas other libraries (like Studio Strings Pro, Afflatus, X3M Percussion etc) can have 30 patches loaded (with 6G loaded in Kontakt for example) and not have much of an impact.

Does anyone know precisely why this happens? I don't want to upgrade to 32G of RAM and realise these libraries just use it all up regardless.


----------



## EvilDragon (Feb 2, 2021)

That's because the instruments you load into Kontakt don't load _just_ samples. They need memory for a number of other things: group and zone memory, each and every effect and modulator loaded also need some memory, each voice of polyphony needs some voice memory for DFD, and so on.

You can see this additional (object and voice) memory listed in Expert->Engine tab.


----------



## Emmanuel Rousseau (Feb 3, 2021)

It seems like there is still some RAM "kept" by Kontakt in 6.5 - much less than in 6.4
I'd be interested to know if this behavior can be reproduced with 6.3 !

I've made a post about this in the main Kontakt thread, here is the link for anyone interested.
https://vi-control.net/community/threads/kontakt-updates-current-version-6-5-0.95552/post-4756338


----------



## Al Maurice (Feb 3, 2021)

I found a similar issue with the latest version of Kontakt (v 6.5), for certain libraries loading large patches -- after a while Kontakt becomes upresponsive for me, then it drops a core dump and my DAW crashes.

The only way round it was to use smaller patches, or to purge the samples; so only the ones being used are loaded.

I hope they resolve this soon.


----------



## EvilDragon (Feb 3, 2021)

That does sound scary, but is filled with unknowns. "Certain libraries" which libraries? "large patches" which patches? "after a while" how much time are we talking about? How many Kontakt instances in the project? Which DAW, OS etc?


----------



## Yaron_NI (Feb 10, 2021)

Al Maurice said:


> I found a similar issue with the latest version of Kontakt (v 6.5), for certain libraries loading large patches -- after a while Kontakt becomes upresponsive for me, then it drops a core dump and my DAW crashes.
> 
> The only way round it was to use smaller patches, or to purge the samples; so only the ones being used are loaded.
> 
> I hope they resolve this soon.


Hey Al, can you provide more details please as EvilDragon mentioned and in addition - are you experiencing the same also with 6.5.1? Did you experience it with previous versions?


----------



## ScoringFilm (Feb 10, 2021)

@Yaron_NI I don't think you are being ignored; it might just take those on the other side of the globe a while to wake up! Your presence here is much appreciated.


----------



## Akat1 (Feb 10, 2021)

I knew something was awry, I believe it was the update before this last one, when the little loading bar no longer was there when loading large libraries. The larger libraries like the Cremona series would instantly appear when double clicked or dragged, then the bar would move to the right over a few seconds. Now the library will appear, but no bar, UI unresponsive but can sometimes still play. Though it has obviously not loaded all the samples. Purging doent seem to really help, its quite random actually. And it seems to effect certain libraries more often. After purging, Session Strings Pro II might load correctly, then back to Cremona and its back to its shenanigans. I have 64 gigs of Ram, and this should not be a problem. Prior to the update, I could load a 5 instrument multi consisting of all 4 Cremonas and The Orchestra 2 in about 15 seconds. Now I load one and wait for the Windows alert beep to tell me its ok to get back to music making, now that (not responding) has resolved itself. Weirder still, small 3rd party libraries will do the same. Even some of the tiny freebie ones, I drag one or and wait. I'm sure it will be addressed. Would be frustrating in a live situation though.


----------



## EvilDragon (Feb 10, 2021)

Cremona loads just fine over here... Wonder if something happened to the NKI itself.


----------



## Akat1 (Feb 10, 2021)

It does it with Elysion, Spitfires CDT and pretty much everything to different degrees. Even a quick load Factory Selections like the Grand Piano and Tenor Sax I set up to mess with the set up of my Midi guitars. I dont sweat it much at the moment. It all happened the update before this last one. I built my system, and its blazing fast. I can render a 10 minute vid in about 2 minutes. I have zero issues with my DAW loading or using other vsts or vstis. Ozone 9 takes a few seconds to load but thats its. Im sure things will work out.


----------



## EvilDragon (Feb 10, 2021)

Did you set up exclusions for your sample drives to Windows Defender (if you're on Windows)? This is a must.


----------



## Akat1 (Feb 10, 2021)

Interesting, never thought Windows Defender could hinder Kontakt performance. But I believe it now that its been mentioned. Windows does like to involve itself in every registry access. And worth addressing. How would I go about this, I assume it would be different because sample files arent streams of exe.'s or network access points. I have 1 sample drive. Though at the pace Im buying up these libraries, more will be needed.


----------



## Akat1 (Feb 10, 2021)

Oh, just like any other exclusion. Nothing special for Kontakt. Question is do I want to exclude the whole drive or just the sub folders. Doesnt matter. Will try this at lunch.


----------



## EvilDragon (Feb 10, 2021)

If you have dedicated sample library drives, just exclude them whole.


----------



## Akat1 (Feb 10, 2021)

I did, didnt seem to matter. Then I opened up Access and noticed 6.5.1. It seems to have cleared things up.


----------



## Yaron_NI (Feb 14, 2021)

so.... to clarify, all good now for everyone here yes?


----------



## David Kudell (Apr 23, 2021)

Hey all, so trying to figure this out myself. When I enable Kontakt instrument tracks in Cubase, it loads them into RAM. Great. Then when I disable them again, the RAM doesn't clear. So I have 38GB of RAM still being used with no instances of Kontakt loaded anymore. Is there a way to purge the RAM without having to restart Cubase every time?


----------



## Yaron_NI (Apr 23, 2021)

David Kudell said:


> Hey all, so trying to figure this out myself. When I enable Kontakt instrument tracks in Cubase, it loads them into RAM. Great. Then when I disable them again, the RAM doesn't clear. So I have 38GB of RAM still being used with no instances of Kontakt loaded anymore. Is there a way to purge the RAM without having to restart Cubase every time?


which kontakt version?


----------



## David Kudell (Apr 23, 2021)

Yaron_NI said:


> which kontakt version?


Latest one 6.5.2 Mac OS Mojave 10.14.6


----------



## Toecutter (Apr 23, 2021)

Yaron_NI said:


> so.... to clarify, all good now for everyone here yes?


@Yaron_NI Kontakt 6.5.2, memory is still not fully released when I remove an instrument like it used to be in 6.3. This issue has been reported many times and while it got better, it's still not optimal like 6.3. Will it ever be fixed or something we have to live with?


----------



## zedmaster (Apr 23, 2021)

I noticed the same in Studio One (Win10). I disabled all tracks on my template, but S1 had a high amount of RAM usage displayed in my task manager. Kontakt 6.5.2


----------



## EvilDragon (Apr 23, 2021)

Toecutter said:


> Will it ever be fixed or something we have to live with?


The memory allocation code was reverted to exactly the same state as before 6.4. If it doesn't behave the same, I guess the only explanation is OS is dealing with things differently somehow for whatever reason. But the issue was definitely fixed in the codebase by reverting to the pre-6.4 state, memory allocation-wise.


----------



## Toecutter (Apr 23, 2021)

EvilDragon said:


> The memory allocation code was reverted to exactly the same state as before 6.4. If it doesn't behave the same, I guess the only explanation is OS is dealing with things differently somehow for whatever reason. But the issue was definitely fixed in the codebase by reverting to the pre-6.4 state, memory allocation-wise.


That's the thing, if OS was doing something different it would affect 6.3 and older versions too right? I just compared 6.3, 6.2, 6.1... to 6.5.2 and the only version not releasing all the memory is 6.5.2, so the only explanation is that the problem is still in 6.5.2. Can you please check? You will see what I mean


----------



## storyteller (Apr 23, 2021)

Are we all on OS X that are experiencing this? I posted earlier that ram memory apps used to classify the ram usage from Kontakt as "WIRED" and then it would release it when tracks were disabled. Currently, OS X no longer frees up the ram from WIRED but instead dumps the disabled tracks from WIRED memory into "App Memory" which can be paged, compressed, etc. That "App Memory" is what makes it look like OS X is not releasing the ram. It is... but it is not reporting it as released. I really don't know what that means performance wise in the longterm, but OS X does seem to reallocate the residual ram from disabled tracks to anything else that requires it in the DAW. The latest version of Kontakt DOES show WIRED memory now for loaded instruments. Previously in the last couple of releases, the ram usage was only reported as "app memory" which was causing the issues people were experiencing.


----------



## EvilDragon (Apr 24, 2021)

Toecutter said:


> so the only explanation is that the problem is still in 6.5.2. Can you please check? You will see what I mean


Over here memory is properly released in 6.5.2 (W10 2004).


----------



## Toecutter (Apr 27, 2021)

EvilDragon said:


> Over here memory is properly released in 6.5.2 (W10 2004).


I can't get it working, tested on two computers W10 20H2 and 1909, the results are the same down the last byte  Thanks anyway!

Anyone else still having problems with Kontakt not releasing all RAM when you remove an instrument?


----------



## EvilDragon (Apr 27, 2021)

BTW, which metric are you monitoring in Task Manager? There are 5 columns related to memory on "Details" page.


Memory – Working Set – is the total amount of memory used by the process which is private and unique to the process as well as shared memory used by the process such as shared libraries.
Memory – Private Working Set – is the amount of memory used by the process which is unique to the process and cannot be accessed by other processes.
Memory – Peak Working Set – is the most memory, both unique and shared, which has been used by the process since it started. This is reset each time the process ends.
Memory – Commit Size – is the amount of virtual memory which is reserved, or committed, for the process.
Page Faults – is the amount of times memory has been fetched from virtual memory because it was not found in physical memory. This is a counter and similar to *Memory – Peak Working Set * in that it is reset each time the process ends.


----------



## Toecutter (Apr 27, 2021)

EvilDragon said:


> BTW, which metric are you monitoring in Task Manager? There are 5 columns related to memory on "Details" page.


Thanks for having a look! Private Working Set, the one that is active by default.

I tested two of my most RAM intensive libraries and the results are always the same:

6.3.0 Joshua Bell Violin
E 195,924K
L 2,454,744K
*U 225,712K*

6.5.2 Joshua Bell Violin
E 178,280K
L 2,442,984K
*U 803,396K*

6.3.0 Modern Scoring Strings Violins
E 195,796K
L 3,728,288K
*U 347,872K*

6.5.2 Modern Scoring Strings Violins
E 177,648K
L 3,626,496K
*U 1,497,884K*

E=empty Kontakt
L=loaded nki
U=unloaded

The big problem is that if I remove MSS violins (still using 1,5GB) and then load Joshua Bell next like I would do while auditioning sounds, Joshua Bell now uses 3,2GB instead of 2,4GB! Imagine if I keep changing instruments, RAM uses never stops increasing. I'm surprised nobody else is noticing this? I tested on two different windows computers. Can you please test again? @Yaron_NI


----------



## Emmanuel Rousseau (Apr 27, 2021)

@Toecutter : I'm sorry for the late reply but I still have some weird Ram management going on! I thought it was gone but it seems like it's just "differently wrong" 

I'll make tests tomorrow to share values like you did.

Edit : BTW. To be confirmed but I think the Ram finally gets released at some point, but just not right away. This afternoon during a project my Ram pool went from something like 90% to less than 70%... Without unloading anything!


----------



## Toecutter (Apr 27, 2021)

Emmanuel Rousseau said:


> @Toecutter : I'm sorry for the late reply but I still have some weird Ram management going on! I thought it was gone but it seems like it's just "differently wrong"
> 
> I'll make tests tomorrow to share values like you did.
> 
> Edit : BTW. To be confirmed but I think the Ram finally gets released at some point, but just not right away. This afternoon during a project my Ram pool went from something like 90% to less than 70%... Without unloading anything!


Thanks Emmanuel! Please do, the more people chiming in the better chance we have to sort this out  

If more people want to help and test, you can tell straight away by loading RAM intensive instruments like Embertone, Cinesamples Cinestrings... and looking at task manager. I shared my tests in this post https://vi-control.net/community/th...-not-unloading-ram.101272/page-3#post-4815142

I left Kontakt 6.5.2 running for a couple hours and RAM didn't get released after I removed MSS violins, not a single byte. 1,5GB sitting there not being used. Kontakt 6.3 releases instantly, it's 6.4 and higher that has issues. 6.4.x does not release the RAM at all. 6.5.x releases 60%, it's better but not fixed here.


----------



## philthevoid (Apr 27, 2021)

Emmanuel Rousseau said:


> @Toecutter : I'm sorry for the late reply but I still have some weird Ram management going on! I thought it was gone but it seems like it's just "differently wrong"
> 
> I'll make tests tomorrow to share values like you did.
> 
> Edit : BTW. To be confirmed but I think the Ram finally gets released at some point, but just not right away. This afternoon during a project my Ram pool went from something like 90% to less than 70%... Without unloading anything!


Yep! I've been noticing that behaviour too. I am working on a project and when I start it up, I see my RAM go up to 90% used. Then I can just leave it there for a little while, go make some tea or whatever, then it'll eventually fall down to around 60% RAM used without me even touching anything.

My hypothesis is that I am using several instances of Cinematic Studio Series instruments among others. They let you unload specific articulations to free ram if you know you won't need it. It works well since Kontakt 6.5 but I have a feeling it loads everything when I launch my project, then it *later* releases the articulations that are turned off.

To me, the Kontakt 6.5 did fix the original issue described in the first post of this thread but it is still not behaving like it used to. At least it's not a major concern anymore for me, just a bit odd.
W10 20H2


----------



## Emmanuel Rousseau (Apr 28, 2021)

On my side, Private Working Set also :

6.5.2 Joshua Bell Violin
E 127,100 Ko
L 1,667,548 Ko
U 775,420 Ko


----------



## stargazer (May 2, 2021)

Haven’t installed 6.5.3 yet.
If I do, and run into problems, is it easy to roll back if I keep (and rename) an old version, or do I have to delete some pref files, too?


----------



## Toecutter (May 3, 2021)

Emmanuel Rousseau said:


> On my side, Private Working Set also :
> 
> 6.5.2 Joshua Bell Violin
> E 127,100 Ko
> ...


wow I missed this, thanks for testing! This is very similar to my results https://vi-control.net/community/th...-not-unloading-ram.101272/page-3#post-4815142

I change a lot of instruments mid project and lose a lot of RAM because of this. @Yaron_NI and @EvilDragon please have a look at this again, the issue is still there. Hopefully it can be solved by the time 6.6 is released?


----------



## Emmanuel Rousseau (May 3, 2021)

Toecutter said:


> wow I missed this, thanks for testing! This is very similar to my results https://vi-control.net/community/th...-not-unloading-ram.101272/page-3#post-4815142
> 
> I change a lot of instruments mid project and lose a lot of RAM because of this. @Yaron_NI and @EvilDragon please have a look at this again, the issue is still there. Hopefully it can be solved by the time 6.6 is released?


Yes, our values are different for the same sample library, probably because of how we have set our buffer settings in Kontakt, but the "ratio" is the same ! This is definitely not fixed :(


----------



## Yaron_NI (May 6, 2021)

Hey all,

I would like to understand the issue you are facing a bit better.

As some mentioned here, memory handling is much more than a pure number in Task Manager or Activity Monitor. The memory can be allocated from various sources and used in various ways, and the number you see there is not always the actual physical RAM used by a program.

I would like to find out from you, the users - is anyone facing actual issues in their workflow or are we only talking about a number in the display? If you are facing issues, could you please describe them in detail so we could better understand.

The issue that we do know that was causing actual workflow problems with 6.4.x has been completely reverted in 6.5.x, there were other optimisations that lead to what you see in the Manager/Monitor, but do these cause real world issues?

Thanks


----------



## philthevoid (May 6, 2021)

Hi Yaron!

Not talking for others but in my case, I didn't run into any real world issues.
I was under the impression that it could be "just a number" like you're basically saying.

That being said, it can be misleading. I have a feeling it is not helping people manage their RAM usage as they never know if they are really close to hitting the limit or if it's just showing it like that while in fact they have plenty of room left.

Thanks!


----------



## Yaron_NI (May 6, 2021)

philthevoid said:


> Hi Yaron!
> 
> Not talking for others but in my case, I didn't run into any real world issues.
> I was under the impression that it could be "just a number" like you're basically saying.
> ...


Thanks for your reply!

I totally get where you're coming from, but for example also Chrome can at times show for me when I have many open tabs 50gb in the monitor, while this is obviously not the case and I do not even have that physical memory.

I agree we could do an even better job at managing memory, and we do have ideas, but what is important to find out is if people are reporting workflow issues that we are somehow not understanding.


----------



## David Kudell (May 6, 2021)

Hi @Yaron_NI, I haven't worked on any projects recently where I've approached my 128GB RAM limit, so I can't say quite yet whether the RAM is really being taken up or whether it's just the way my Mac is reporting the number. 

I run a big template but all tracks are disabled by default so it depends on the project how much RAM gets used. I think the geek in me just wants to see the RAM number go down when I disable a bunch of tracks, but I guess it's possible that it's just the way the usage is being reported. Closing Cubase will make the RAM number go down again...but just disabling the tracks and keeping the project open doesn't make the number go down. 

I should be starting a project soon where I can put it to the test and hopefully see if the memory is actually being used or not. I'll report back then.


----------



## Toecutter (May 6, 2021)

Yaron_NI said:


> Hey all,
> 
> I would like to understand the issue you are facing a bit better.
> 
> ...


Thanks Yaron! For me it s an issue because RAM keeps increasing when I change instruments in Kontakt and eventually I will run out of RAM on my laptop. This wasn't an issue in 6.3. I go into more details here https://vi-control.net/community/th...-not-unloading-ram.101272/page-3#post-4815142
Windows 10 pro 1909 and 20H2, standalone Kontakt or VST.


----------



## Emmanuel Rousseau (May 6, 2021)

@Yaron_NI : Are the numbers in Kontakt's Engine tab a more "serious" indication than those in the Task Manager ?


----------



## zolhof (May 6, 2021)

Hi @Yaron_NI , thank you for looking into it!

I can see this becoming an issue with 16GB and even 32GB of RAM, depending on how the user works. I've done a lot of tests for Spitfire in order to figure out their own memory issues with BBCSO, so I'm confident that the numbers I'm seeing on the Resource Monitor are the actual physical RAM used by Kontakt, and not being fully released when an instrument is removed. Please have a look at the following screenshots:

Cubase 11.0.20 + empty Kontakt 6.5.3 *447MB







*

Modern Scoring Brass, 18 nki *22GB








*


After removing all 18 nki *10.5GB









*

As shown, 10.5GB of RAM are permanently lost, no matter how long I wait, even hours. "Object Memory Total" seems to be the culprit, since it never gets released by Kontakt after I remove or change an nki, compared to version 6.3.1 where it's fully released from RAM. The only way to recover the memory in version 6.5.3 is to manually remove Kontakt OR disable the instrument track on Cubase and enable it again. That is why folks working with disabled track templates will probably never notice this behavior because RAM is properly released by Cubase when you disable an instrument track. The same behavior is seen in Vienna Ensemble Pro and Kontakt standalone.


----------



## Korreyshortime (Aug 13, 2021)

Hey, first time in 10+ years EVER commenting on these sort of boards but this problem has driven me to it!

Has anybody figured out the solution to this? After purging / deleting my Kontakt instances in Logic, 16gb was still in the RAM? Upon closing and reopening it freed up 11gb of RAM... this realllllyyyy doesn’t make sense.

Did anybody find a solution that doesn’t involve resetting the DAW?


----------



## philthevoid (Aug 13, 2021)

Yeah, it doesn't make RAM management easy but I don't think a solution has been found yet.

Still, Yaron_NI stated this:
"the number you see there is not always the actual physical RAM used by a program."

And basically asked if we were experiencing any real-world issues with that. In other words, if you keep unloading instruments and loading them again, that number keeps going up, right? But do you REALLY eventually run out of memory? Or does that number adjust itself when it's about to run out? Nobody really answered that so far, except maybe Toecutter but it feels more like he assumed he would run out of memory rather than him saying he actually did.


----------



## EvilDragon (Aug 16, 2021)

philthevoid said:


> But do you REALLY eventually run out of memory? Or does that number adjust itself when it's about to run out?



This is the burning question and both myself and @Yaron_NI would like to know the answer to it.


----------



## toddkreuz (Aug 16, 2021)

i'm using an older version till it gets sorted.


----------



## Gusteeno (Aug 21, 2021)

I just bought a new 2020 iMac 10-core i9 (Big Sur) specifically for the 128gb RAM because this issue was driving me nuts on my older 2017 iMac 4-core i5 64gb RAM. Spent $4,000 because I thought having more RAM would keep me from maxing out my RAM, but after loading my 300 track orchestral template in Ableton (all Kontakt 6.6.0 instances disabled AND purged) I'm STILL at 83% RAM! Such a bummer after spending so much money. REALLY hoping this can get figured out soon, but seeing as how this forum has been going for nearly a year it's not looking good...

Anyone figure this out yet?


----------



## Wirebird (Aug 21, 2021)

For what it’s worth, I have the same problem with Kontakt using Ableton Live (Win 8.1). Once a patch is loaded, the RAM it uses will stay used, regardless of replacing or unloading the patch, or even removing Kontakt from the track. The only thing that will clear the RAM to what is actually currently used, is quitting and reopening the Ableton Live document.
This makes trying out many presets at a time a hassle.


----------



## EvilDragon (Aug 21, 2021)

We'd still like to know what happens when you reach max RAM usage, does the number adjust itself and you can actually keep loading stuff, or not?

Modern memory allocators work a bit differently than those from 40 years ago.


----------



## Gusteeno (Aug 21, 2021)

Wirebird said:


> For what it’s worth, I have the same problem with Kontakt using Ableton Live (Win 8.1). Once a patch is loaded, the RAM it uses will stay used, regardless of replacing or unloading the patch, or even removing Kontakt from the track. The only thing that will clear the RAM to what is actually currently used, is quitting and reopening the Ableton Live document.
> This makes trying out many presets at a time a hassle.


Always good to hear you're not alone, and/or just doing something wrong, haha. Thanks


----------



## Wirebird (Aug 21, 2021)

EvilDragon said:


> We'd still like to know what happens when you reach max RAM usage, does the number adjust itself and you can actually keep loading stuff, or not?
> 
> Modern memory allocators work a bit differently than those from 40 years ago.


In my case (Kontakt/Ableton Live/Win), things eventually get more sluggish, until Live freezes, with the only option left to force quit. Even if I have unloaded every Kontakt patch and just keep loading new ones, one at a time replacing the previous, it will eventually freeze Live. Having Live crash with very few tracks and effects and only one instance of Kontakt with at the time only one patch, pretty much sums it up (in my configuration). No memory is ever released by Kontakt. This is verified in resource monitor, and I’ve tried everything I could come up with to find a way around it. I’m so used to it by now, so I’m just careful with which patches I load and plan ahead.


----------



## Gusteeno (Aug 22, 2021)

EvilDragon said:


> We'd still like to know what happens when you reach max RAM usage, does the number adjust itself and you can actually keep loading stuff, or not?
> 
> Modern memory allocators work a bit differently than those from 40 years ago.


My response is much the same as @Wirebird where once the RAM percentage hits about 93% it becomes sluggishly unusable and then freezes the entire computer without the ability to force quit. Instead I have to restart my computer.


----------



## EvilDragon (Aug 22, 2021)

OK thanks for that info.

I'll also try in my machine, but it could take a while because I have 64 GB of RAM


----------



## Guffy (Aug 22, 2021)

What is the latest working version of kontakt? I'm on 6.3 something and really want to upgrade because of the "The state of some instances of Kontakt cannot be recalled correctly, please open any instance of Kontakt to resolve the problem" bug, but if i have to trade it for a major ram bug, idk..


----------



## Toecutter (Aug 22, 2021)

EvilDragon said:


> We'd still like to know what happens when you reach max RAM usage, does the number adjust itself and you can actually keep loading stuff, or not?
> 
> Modern memory allocators work a bit differently than those from 40 years ago.


No, it runs out of memory and crashes all DAWs I tested. Cubase 11 crashes, Studio One 5.3 crashes, Digital Performer 11 crashes, Vienna Ensemble Pro 7 crashes. There are tons of information in this thread showing how Kontakt from 6.4 up isn't releasing RAM. This is not a modern memory allocation thing, it's bugged and can be reproduced. It's wasted memory that leads to the system becoming very unstable and eventually crashing.

I have a lightweight 32GB laptop that I use for meetings and showing demos that used to be perfect for that. Now I can't change Kontakt instruments if I need to show a director different sounds, arrangements, because I risk crashing the session (you know how these meetings go, the last thing I'm worried about is RAM not getting flushed XD). It happened a few times and it wasn't cool. Yea I can go back to Kontakt 6.3 but then several libraries won't work.

It shouldn't take more than 5 minutes to reproduce what we've been reporting here for months. @Yaron_NI said that NI was investigating so I thought you guys knew by now about the instability- crashes issues and what happens when you reach max RAM usage, sorry if I didn't make it more clear.


----------



## Toecutter (Aug 22, 2021)

Wirebird said:


> For what it’s worth, I have the same problem with Kontakt using Ableton Live (Win 8.1). Once a patch is loaded, the RAM it uses will stay used, regardless of replacing or unloading the patch, or even removing Kontakt from the track. The only thing that will clear the RAM to what is actually currently used, is quitting and reopening the Ableton Live document.
> This makes trying out many presets at a time a hassle.





Wirebird said:


> In my case (Kontakt/Ableton Live/Win), things eventually get more sluggish, until Live freezes, with the only option left to force quit. Even if I have unloaded every Kontakt patch and just keep loading new ones, one at a time replacing the previous, it will eventually freeze Live.





Gusteeno said:


> My response is much the same as @Wirebird where once the RAM percentage hits about 93% it becomes sluggishly unusable and then freezes the entire computer without the ability to force quit. Instead I have to restart my computer.


Yep that's exactly what is happening to me in Cubase, Studio One, Vienna, Digital Performer etc. Memory keeps getting used when I replace patches and eventually the session crashes because RAM is not released like it used to in Kontakt 6.3.


----------



## Gusteeno (Aug 22, 2021)

EvilDragon said:


> OK thanks for that info.
> 
> I'll also try in my machine, but it could take a while because I have 64 GB of RAM


Shouldn’t take long at all. Just create 10 Kontakt instances and copy paste until you max out. Took 300 tracks for me with 128gb RAM. So should be nearly half that for you I would guess?


----------



## storyteller (Aug 22, 2021)

VEPro doesn't fully release ram in a disabled state either. It frees up *some* ram, but a very small amount compared to the memory that remains in "wired" and "applications" status in my Ram Management utility. Only after I've disabled instances... and then wait a few moments... then I can recover ram from the app and wired segments of ram by clicking on the recycle ram button in the ram management utility. Understandably, this is a no-go for anyone's workflow when using disabled templates.


----------



## EvilDragon (Aug 22, 2021)

Guffy said:


> and really want to upgrade because of the "The state of some instances of Kontakt cannot be recalled correctly, please open any instance of Kontakt to resolve the problem" bug



That's not a bug, that's the new "missing samples" behavior. As has been explained a number of times 



Gusteeno said:


> Shouldn’t take long at all. Just create 10 Kontakt instances and copy paste until you max out.



That's kinda not the scenario here - the scenario is loading an instrument then removing it then loading it again then removing it, testing how much RAM is released or not etc.

Just duplicating instances is a completely different thing.


----------



## Guffy (Aug 22, 2021)

EvilDragon said:


> That's not a bug, that's the new "missing samples" behavior. As has been explained a number of times


Oh, well i meant the fact that cubase is crashing whenever this window pops. I believe you confirmed that to be a bug that would be fixed.
Wouldn't be surprised if it was a cubase issue (not exactly a shortage of those )
Anyways, didn't mean to hijack the thread, carry on.


----------



## Gusteeno (Aug 23, 2021)

EvilDragon said:


> That's kinda not the scenario here - the scenario is loading an instrument then removing it then loading it again then removing it, testing how much RAM is released or not etc.
> 
> Just duplicating instances is a completely different thing.


Whoops, forgot to mention the most important part... at the end of duplicating until you max out, then delete them all and you will see (at least in my case) that all of the RAM that was loaded will still be in use.


----------



## jcrosby (Aug 23, 2021)

Guffy said:


> Oh, well i meant the fact that cubase is crashing whenever this window pops. I believe you confirmed that to be a bug that would be fixed.
> Wouldn't be surprised if it was a cubase issue (not exactly a shortage of those )
> Anyways, didn't mean to hijack the thread, carry on.


I'm getting hangs in Logic from this god-awful feature using the current version...


----------



## Gusteeno (Sep 5, 2021)

I reverted back to 6.3.2 because I read a few users say that the memory management issue wasn't present in that update... but alas, it's still doing the same thing. RAM isn't completely unloaded when looking at iStats when purging samples, only about 20% of it is. Even though in Kontakt it says all of the memory has been freed up (from 6gb down to 0gb). 

It's only unloading if I completely delete the track with the kontakt instance. Is that normal behavior in a DAW to only release the memory if the track is deleted, or is it actually suppose to release the RAM used by the library after simply purging the samples? Thanks


----------



## SharpDal (Oct 30, 2021)

I might be wrong here but I think this may be a bit more wide spread problem than just Kontakt since at least for me Spitfire Player has the very same behaviour but only on a Mac. I have two systems, M1 MacBook Pro (Big Sur, 8gb) and desktop PC (Win10, Ryzen 1800x, 64gb). DAWs I have are Cakewalk, Ableton Live Lite, Reaper and Logic Pro.

On PC only Kontakt leaves behind a significant amount of trash in memory after deleting the tracks and instruments no matter which DAW, with Spitfire Player (Abbey Road ONE) everything works as expected.

But on my MacBook though, the very same issue applies across the board, also with Spitfire's own sampler. At first I thought it's probably something VST related but AU versions of the same plugins have the very same behaviour, at least on my machine.

I just have Kontakt and Spitfire stuff so it would be very interesting to see if other samplers like Sine or Synchron are affected by this or is this problem with Spitfire's sampler just my machine and/or totally unrelated. Just my two cents.


----------



## David Kudell (Oct 30, 2021)

SharpDal said:


> I might be wrong here but I think this may be a bit more wide spread problem than just Kontakt since at least for me Spitfire Player has the very same behaviour but only on a Mac. I have two systems, M1 MacBook Pro (Big Sur, 8gb) and desktop PC (Win10, Ryzen 1800x, 64gb). DAWs I have are Cakewalk, Ableton Live Lite, Reaper and Logic Pro.
> 
> On PC only Kontakt leaves behind a significant amount of trash in memory after deleting the tracks and instruments no matter which DAW, with Spitfire Player (Abbey Road ONE) everything works as expected.
> 
> ...


I'm starting to think it could be the DAW also, because if you close the DAW, all the RAM becomes free again. Obviously the DAW grabs RAM when you load a sample library, but when you go to disable the track, if Cubase or Logic or whatever doesn't bother to tell MacOS or Windows that it doesn't need that RAM anymore, perhaps that sample data just stays there in RAM in a kind of no-man's land?


----------



## Gusteeno (Oct 30, 2021)

David Kudell said:


> I'm starting to think it could be the DAW also, because if you close the DAW, all the RAM becomes free again. Obviously the DAW grabs RAM when you load a sample library, but when you go to disable the track, if Cubase or Logic or whatever doesn't bother to tell MacOS or Windows that it doesn't need that RAM anymore, perhaps that sample data just stays there in RAM in a kind of no-man's land?


That's a good point, but I wonder why that was never an issue with the DAW's back before this was a known issue? Surely ALL DAW's didn't change the way they deal with RAM all at the same time.


----------



## David Kudell (Oct 30, 2021)

Gusteeno said:


> That's a good point, but I wonder why that was never an issue with the DAW's back before this was a known issue? Surely ALL DAW's didn't change the way they deal with RAM all at the same time.


True, but are we sure that's the case? I never really noticed how it worked before.


----------



## SharpDal (Oct 30, 2021)

David Kudell said:


> True, but are we sure that's the case? I never really noticed how it worked before.


Well, if someone here has a time capsule buried under the dust to try out some older DAWs and plugins... Anyways I'm going to do some serious testing with anything free I can grab tomorrow to get specifics down, if I recall right at least Sine has some free libs. This really triggers my investigation mode.


----------



## SharpDal (Oct 31, 2021)

*SYSTEM*
MacOS BigSur - 11.6
MacBook Pro - M1 - 8GB

*USED PATCHES*
Kontakt Player 6.6.1 Spitfire Symphonic Strings - Ensemble multi
Sine Player 1.0.6 Layers - Full Orchestra
Spitfire Player 1.1.0 Abbey Road ONE - Full Orchestra

*TEST PROCEDURE*
M Created an empty project file
M(n) 1 plugin instance / track, duplicated 16 times**
m(n) All tracks deleted one by one, except the first one, only removed the plugin instance
Repeat two more times (in total 48 plugin instances created and deleted)
M Save, close the DAW and open the project file to check nothing extraordinary is loaded in RAM

** Live Lite has only 8 tracks so one instrument rack and two plugin instances per track

*WHAT WERE THE EXPECTATIONS*
- RAM usage should not exceed a certain point, no matter how many cycles repeated
- Deleting all the tracks and plugin instances should restore the memory usage back to the starting point

*WHAT REALLY HAPPENED*
- Every sampler leaks memory
- The worst one is Kontakt in VST3 format, virtually no RAM gets released
- Otherwise no major differences between plugin formats or samplers…
- …although Kontakt in AU and VST2 formats is still quite worse than Sine or Spitfire Player
- Note that used patch in Spitfire Player is significantly smaller -> Flattens the “saw”

*SUMMARY*
- DAW independent behaviour
- Avoid Kontakt in VST3 format to minimize the problem
- No matter what DAW or plugins you use, the load/freeze workflow will eventually eat the RAM
- Because the very same patch was duplicated, this problem is probably much worse in real life scenarios

*EDIT:* This data is evil, see the post #102


----------



## jcrosby (Oct 31, 2021)

Is it possible this is due to a change in the way each OS is handling virtual memory?

Macos for example will keep things in ram while working in a given program to speed up load times and improve performance for RAM intensive tasks, BUT if the data has been flagged as not needed (disabled tracks or purged VIs for example), macos will flush the unneeded stuff out of memory to make room for new memory once you start to actually need to make use of the space that has been flagged as _available_.

I haven't noticed this issue personally, (on 10.15 not BS), just tossing out ideas you might want to investigate just to make sure all hope isn't lost currently...


----------



## SharpDal (Nov 1, 2021)

jcrosby said:


> Is it possible this is due to a change in the way each OS is handling virtual memory?
> 
> Macos for example will keep things in ram while working in a given program to speed up load times and improve performance for RAM intensive tasks, BUT if the data has been flagged as not needed (disabled tracks or purged VIs for example), macos will flush the unneeded stuff out of memory to make room for new memory once you start to actually need to make use of the space that has been flagged as _available_.
> 
> I haven't noticed this issue personally, (on 10.15 not BS), just tossing out ideas you might want to investigate just to make sure all hope isn't lost currently...


Something like this is actually the case. I did further tests and it seems that OS never begins to write swap files unless the amount of samples reaches a certain point, somewhere around 3.5 - 4 gigs depending on the used libraries and plugins. It still reserves the memory and keeps it tied to a certain process though, at least with Reaper.

With this knowledge I wrote another test script that duplicates and removes the exact number of tracks. I ran the script, watched the memory pressure curve and swap stats and found that for Spitfire and Sine instances the curve was perfectly flat, a little bit wave was drawn if the used patches were bigger than 70 - 100 MB. But no memory accumulation, expect in the process tied memory reading, which apparently is not reliable at all. *DO NOT TRUST IT!!!*

With an empty Kontakt instance I could reach a quite a lot duplicate/remove -cycles before swap writes:
- 3000 instances in AU format
- 2800 instances in VST format
- 2000 instances in VST3 format

And this is where this gets interesting…

With an SSS Ensembles multi patch loaded I could duplicate and remove somewhere around 100-110 Kontakt VST3 instances before the swapping. But in AU and VST format the script reached easily 2000 Kontakt instances and it never even began to swap, at least if you can trust the Activity Monitor. The trust is a fragile thing…

So it seems that even though this memory leak affects all three formats, only in VST3 format the library associated data is drawn in data accumulation. This is true and tested for this one patch only though, no idea what are the effects between different libraries and patches or how multiple different patches loaded simultaneously or within the same project will affect, it’s simply a bit too slow to test.

So most likely no hope was lost in the end.


*TL;DR:*
- Use Kontakt in AU or VST format
- Kontakt in VST3 kills the load/freeze workflow
- Sine and Spitfire Player are rock solid


----------



## storyteller (Nov 1, 2021)

I've been trying to watch the page file as well. I don't use the VST3 version of Kontakt yet (VST regular for me), but I haven't seen the page file budge much either. I have, however, seen the memory for an app go into the "compressed" state. At first I thought that was bad... but the more I've been testing it, the more it seems like it actually doesn't affect the performance. Closing projects and tracks doesn't "uncompress" all of the memory though... Some compressed memory remains.

A slightly different example... on my VEPro servers with 128GB of ram each, it seems like I can load upwards of 200GB worth of sample content before the page file kicks in. It seems like macOS is doing something really special with compression that allows me to use way more samples than I thought possible. However, when the page file kicks in, performance is atrocious. No page file and everything seems to play back completely as expected.

So, in a nutshell, I think compressed memory is okay performance-wise. If we are hitting the page file, then it is unusable.

And then again, there is this issue seen in Monterey... so we may not all be losing our minds.








Users Reporting 'Memory Leak' Issues After Updating to macOS Monterey


Some users who recently upgraded to macOS Monterey are experiencing a bug known as a "memory leak," a scenario in which a specific macOS...




www.macrumors.com


----------



## jcrosby (Nov 1, 2021)

SharpDal said:


> Something like this is actually the case. I did further tests and it seems that OS never begins to write swap files unless the amount of samples reaches a certain point, somewhere around 3.5 - 4 gigs depending on the used libraries and plugins. It still reserves the memory and keeps it tied to a certain process though, at least with Reaper.
> 
> With this knowledge I wrote another test script that duplicates and removes the exact number of tracks. I ran the script, watched the memory pressure curve and swap stats and found that for Spitfire and Sine instances the curve was perfectly flat, a little bit wave was drawn if the used patches were bigger than 70 - 100 MB. But no memory accumulation, expect in the process tied memory reading, which apparently is not reliable at all. *DO NOT TRUST IT!!!*
> 
> ...


Sorry, I meant to write memory compression not virtual memory. What can I say... I'm a space case.

:emoji_alien:

Why you'd see a difference between VST2 & VST3 I have no idea. But given how new the VST3 version is it's not unreasonable it might be a bug.

It sounds like what is supposed to happen is that the patch script is reserved in memory once. Each duplicate references the original script, and the remaining memory is consumed by resources needed for each discrete instance of Kontakt. Maybe the VST3 is loading the script with each instantiation, but that's only a guess....

In terms of physical memory differences shown in the plugin vs Activity Monitor this is probably memory compression doing what it does best... The plugin may require _X_ amount of space, but the OS is capable of compressing that data down to a smaller footprint to make use of memory more efficiently....

Activity Monitor is fine. It's part of the OS, and an accurate reflection of how resources are being consumed. If anything I'm less likely to trust any numbers number shows in a plugin, and instead check activity monitor as the OS most likely can compress memory down further than the plugin may actually report.

I'm confused as to where the evidence for a memory leak comes from though, (outside of the VST3 issue you're seeing). Each instantiation of Kontakt eats somewhere between 35 and 45 MB IIRC. Multiply that by the number instances and that's pretty hefty footprint...

*EDIT*: ^ What they said  I was typing when storyteller's post went up...
It sounds like the memory differences are compressed memory doing its thing.
And that there may be an issue with the VST3... Maybe it's a leak, or maybe it's writing the script for each instance loaded every time (SSS in your case) when it shouldn't be. If you're on Monterey that could play a role as well... Either way it sounds like the solution is to avoid the VST3 version for now.


----------



## EvilDragon (Nov 1, 2021)

jcrosby said:


> or maybe it's writing the script for each instance loaded every time (SSS in your case) when it shouldn't be.



There is no logical reason why this sort of thing would only happen in VST3 and not other plugin types. It's a very specific thing to be special cased (and even then, VST3 plugin layer lies on top of the whole Kontakt engine, so it doesn't really affect how that engine allocates memory).


----------



## jcrosby (Nov 1, 2021)

EvilDragon said:


> There is no logical reason why this sort of thing would only happen in VST3 and not other plugin types. It's a very specific thing to be special cased (and even then, VST3 plugin layer lies on top of the whole Kontakt engine, so it doesn't really affect how that engine allocates memory).


That makes sense. I'm just tossing out ideas as to why they'd only see 100-ish instances of the VST3 version which does seem odd, but it was just a guess...


----------



## SharpDal (Nov 1, 2021)

jcrosby said:


> That makes sense. I'm just tossing out ideas as to why they'd only see 100-ish instances of the VST3 version which does seem odd, but it was just a guess...


I may have understood incorrectly but I didn't mean concurrent instances but in a row: make an instance -> duplicate it -> remove the duplicate -> duplicate again -> remove the duplicate... and so on repeated until the swapping begins. Memory footprint shouldn't rise but with Kontakt it does = pure definition of memory leak. VST3 leaves much more garbage behind than VST or AU, hence the 100 vs 2000 instances before the swapping begins.

And while you do this dance between duplication and removal the memory number associated with Reaper's process in Activity Monitor just keeps reaching the levels that should literally be impossible, was something like 30 gigs on my 8 gig system, swapping was 0 bytes. Definitely a false reading.


----------



## jcrosby (Nov 1, 2021)

SharpDal said:


> I may have understood incorrectly but I didn't mean concurrent instances but in a row: make an instance -> duplicate it -> remove the duplicate -> duplicate again -> remove the duplicate... and so on repeated until the swapping begins. Memory footprint shouldn't rise but with Kontakt it does = pure definition of memory leak. VST3 leaves much more garbage behind than VST or AU, hence the 100 vs 2000 instances before the swapping begins.
> 
> And while you do this dance between duplication and removal the memory number associated with Reaper's process in Activity Monitor just keeps reaching the levels that should literally be impossible, was something like 30 gigs on my 8 gig system, swapping was 0 bytes. Definitely a false reading.


Ah ok. I thought you meant concurrent instances all being hosted at the same time.


----------



## Gusteeno (Jan 14, 2022)

Bumping this thread because the problem still persists (Mac OS X 11.6.1 Intel i9 128gb RAM Ableton Live 11) and I'm wondering if anyone with a Mac can verify if upgrading to Monterey had any affect on Kontakt not fully unloading the RAM in the DAW or not. I doubt it changed, but I'm still so bummed I can't use my 300 track kontakt template (all instances purged) due to this issue and am hoping NI has been actively trying to figure this out for a future update. Anyone have any thoughts on this? @EvilDragon


----------



## fabian (Jan 14, 2022)

Emmanuel Rousseau said:


> 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.
> 
> ...


have you tried reinstalling Kontakt ? (but keeping the libraires) ...


----------



## EvilDragon (Jan 14, 2022)

Gusteeno said:


> if upgrading to Monterey had any affect on Kontakt not fully unloading the RAM in the DAW or not.



OS update has nothing to do with this.


----------



## Gusteeno (Jan 14, 2022)

EvilDragon said:


> OS update has nothing to do with this.


Ok. Any chance you could elaborate on the RAM issue a little more than that?


----------



## Lhotse (Jan 29, 2022)

Any news about this RAM not unloading issue, please? This is driving me crazy really. Kontakt 6 v6.6.1


----------



## EvilDragon (Jan 29, 2022)

VST3 memory not being released will be fixed in the next version of Kontakt.


----------



## rMancer (Feb 19, 2022)

EvilDragon said:


> VST3 memory not being released will be fixed in the next version of Kontakt.


I am still having an issue here with this after the 6.7.0 update, regardless of VST2 or VST3.

Disabling and re-enabling a Kontakt instance causes it to take up more RAM than it did before. The amount seems to be based on the libraries loaded.

Testing with just Scarbee Vintage Keys A-200, with the "Allow complete unload of plug-ins" enabled in Reaper settings.


Load up empty Kontakt in blank project. Reaper RAM use reads 382MB.
Load Scarbee A-200. RAM use reads: 477MB.
Disable Kontakt. RAM use reads 283MB.
Reenable Kontakt. RAM use reads 486MB.
Disable Kontakt. RAM use reads 291MB.
Reenable Kontakt. RAM use reads 494MB.
Disable Kontakt. RAM use reads 301MB.
Reenable Kontakt. RAM use reads 502MB.
Disable Kontakt. RAM use reads 309MB.
Reenable Kontakt. RAM use reads 508MB.
Repeat 10x. RAM use now reads 579MB.
Repeat 10x. RAM use now reads 657MB.
Repeat 10x. RAM use now reads 722MB.
Repeat 10x. RAM use now reads 788MB.
(RAM use with Kontakt disabled at this point reads 671MB)
Delete Kontakt. RAM use still reads 671MB.
Add a new Kontakt and load Scarbee A-200. RAM use reads 796MB.
Iterate another 30-ish times, and now I'm reading 1000+MB RAM use.
(looking at Reaper's Performance Meter and Windows Task Manager and the values are more or less the same in both)

The amount of increase seems to depend on the libraries in the patch. More/heavier libraries lead to bigger increase per iteration.

I am not getting this behavior from other plugins I've tested (Superior Drummer 3, Spitfire player), which leads me to believe that the problem may be with Kontakt rather than Reaper alone. If the meters can be trusted, it seems like the only way to get my memory back after deleting a Kontakt patch or track is to reboot Reaper. I'm trying to build a template this week and this whole deal of not being able to accurately gauge how much memory I actually have free is pretty annoying.


----------



## EvilDragon (Feb 19, 2022)

That is a different scenario than the one that was problematic before (and was fixed in 6.7), which is loading an instrument in a Kontakt instance, then removing it, then loading it again, would just take twice the amount of RAM than before (whereas it should've used about the same).


----------



## rMancer (Feb 19, 2022)

So the issue I've described (Kontakt's "ghost" footprint bloating my system memory usage) is normal/expected behavior? Seems like if I delete or disable a Kontakt instance, I should get _all _of that memory back. That's the way it works with other plugins, anyway. As it stands, I could theoretically max out all ~24gb of available system memory without even having a single sample loaded. Obviously that's an unrealistic scenario, but based on my experiments, it seems possible, just by adding and removing enough Kontakt instances.

(I should note: repeating the process I outlined above, even without loading a library, still increases the RAM used. i.e. if I add an empty Kontakt and then remove it, each time it takes up ~3mb more than it did the time before).


----------



## EvilDragon (Feb 19, 2022)

That would depend on which specific memory manager they use. Memory manager that Kontakt used was changed in 6.4 to a more modern one, which doesn't necessarily work optically as user would expect (the memory _is_ being marked as free, but actual freeing of memory is deferred to when that memory is actually needed by another process). Now, there _were_ some real issues with VST3 memory deallocation prior to 6.7, and that was resolved.

Do let me know if you actually manage to grind your system to a halt or not with this method you outlined. An easy test to eat up gobs of RAM is to set up an empty instrument with a few groups set to TMPro and increasing TMPro polyphony in Instrument Options->Voicing.


----------



## rMancer (Feb 19, 2022)

EvilDragon said:


> That would depend on which specific memory manager they use. Memory manager that Kontakt used was changed in 6.4 to a more modern one, which doesn't necessarily work optically as user would expect (the memory _is_ being marked as free, but actual freeing of memory is deferred to when that memory is actually needed by another process). Now, there _were_ some real issues with VST3 memory deallocation prior to 6.7, and that was resolved.
> 
> Do let me know if you actually manage to grind your system to a halt or not with this method you outlined. An easy test to eat up gobs of RAM is to set up an empty instrument with a few groups set to TMPro and increasing TMPro polyphony in Instrument Options->Voicing.








After adding and removing enough (completely empty) Kontakts, here is my empty Reaper project with a single empty Kontakt instance, using almost 12gb of RAM.


----------



## rMancer (Feb 19, 2022)

Update: I did manage to grind my system to a halt just by adding and removing empty kontakts (got the "about to run out of memory, soldier") thing, and my whole system locked up once I hit the 32gb limit. I had to hard-reboot my computer. And not a single sample was ever loaded...

The process was: Start with 1 track with empty kontakt. Add 30 more tracks with empty Kontakt, remove those 30 tracks, then repeat (add 30, remove them, add 30, remove them, etc). I never had more than 31 Kontakt instances in the project at a time.

As long as there was at least 1 Kontakt in the project still, the memory never got fully unloaded. But if at any point I delete that first track (the one that wasn't part of the 30 add/remove cycle), the memory does seem to be unloaded (not quite all the way, but I could reclaim the 20gb or whatever of "ghost" memory by deleting that last instance).


----------



## EvilDragon (Feb 19, 2022)

OK, thanks for the info!


----------



## EvilDragon (Feb 21, 2022)

@rMancer OK I've now tried to repro your steps.

While I did get the same behavior of increasing RAM at every cut-paste, when reaching the max RAM that I have (64 gigs, that took a while), I did not get any message about crashing, instead already taken memory was reused/reallocated, which is the intended behavior of this new memory manager.


----------



## rMancer (Feb 21, 2022)

EvilDragon said:


> @rMancer OK I've now tried to repro your steps.
> 
> While I did get the same behavior of increasing RAM at every cut-paste, when reaching the max RAM that I have (64 gigs, that took a while), I did not get any message about crashing, instead already taken memory was reused/reallocated, which is the intended behavior of this new memory manager.


Hmm, I'm hesitant to try to reproduce it again on my end, given the frozen system and hard reboot last time.

One thing I did notice is that it _seemed _to work as intended at first; when I first hit the limit, memory seemed to be reallocated. But after repeating the copy/paste process a few more times once I was already at the limit, that's when I got the error messages, and then the total lockup.

But thank you anyway; I realize it's kind of an extreme/edge case, and even more so if you can't reproduce it. I've already caved and have got another 32gb of RAM on order anyway, due here on Thursday


----------



## Azunald (Jun 12, 2022)

Hey guys,
I am facing the same issue for some days now (didn't notice at first). This is such a pain....

I'm on Windows 11, intel i9 - *64Go* RAM. Cubase 11 Pro - Kontakt *6.7.1*
Basic memory usage = 6Go without anything ongoing.
After loading my project in Cubase = 46.9Go RAM. First trick, I already purged all instruments before so that only the samples I am using in the track are loaded.

After re-purging all instruments in Kontakt.... 37.2Go RAM used. Until... after like 10-20 minutes, my RAM dropped to 24.5Go as I was writing this comment.

And I won't tell you about my VE Pro template (also purged) killing my RAM when linked to Cubase when no/zero/none instrument has samples loaded. So I cannot use it any longer.

I unistalled Kontakt & some orchestral libraries, installed them again... nothing changed.

Do you have any news or should we takle NI's Support Team about this?

Thanks


----------



## EvilDragon (Jun 12, 2022)

This is definitely a case for NI support.


----------



## TomaeusD (Sep 3, 2022)

I was having the same issues as @Azunald in Cubase 12 - purging all samples didn't actually purge memory. This happens in both 6.7.0 where elease notes say samples held for VST3 was fixed, but it wasn't. Updating to 6.7.1 seemed to fix it, though - although it seems like one instance of Kontakt still takes up more RAM than I remember.

EDIT: It looks like each empty or purged instance of Kontakt now takes up about a gig which is unfortunate. Using VST2 version does not change anything.


----------



## EvilDragon (Sep 3, 2022)

Depends what sort of instruments you load, samples are only one part of the RAM load equation. If the instruments are extremely "thick" in amount of groups/zones/modulators/persistent variables in scripts/use a lot of TMPro voices/have large max polyphony, even fully purged they can take a solid chunk of RAM.

However, *empty* Kontakt instances don't take up 1 gig over here. Each additional instance I load is around 60-80 MB of RAM, empty. Oh, but if you are a heavy user of the Database, then yeah that one would take more RAM (if it has a ton of stuff in it), however this would still be only a one time RAM tax, only one instance requires to reserve memory for the database, this is then shared with all other Kontakt instances ran in the same host process.


----------

