What's new

Kontakt 7 - Updates (current version: 7.10.7)

All I'm hoping is that they are working in the background to fix the huge RAM overhead with Kontakt 7. That's the biggest issue for me with it. It keeps me from creating a template with some libraries being laid out with one instance per articulation for layering purposes. It's just impossible with Kontakt 7.
Same. I’m finding it’s slower to load, uses more RAM, and crashes sometimes. Where K6 had none of these issues.
 
It keeps me from creating a template with some libraries being laid out with one instance per articulation for layering purposes. It's just impossible with Kontakt 7.
I don't know what DAW you're using, but disabling tracks helps a lot. My entire template in Reaper is disabled and the track I need can be enabled in milliseconds. That might help you solve your Kontakt 7 issue.
 
  • Like
Reactions: Vik
I don't know what DAW you're using, but disabling tracks helps a lot. My entire template in Reaper is disabled and the track I need can be enabled in milliseconds. That might help you solve your Kontakt 7 issue.
The problem is that Kontakt 7 specifically bloats the project file size way too quickly. So even disabled it has massive overhead in filesize for some reason.
 
I had also these kernel panics with my Mac Studio M2 Ultra. Strangely enough, this only happens with certain screen resolutions, so I avoid these. May you give this a try.
Here`s a discussion about these kernel panics:
https://community.native-instrument...ng-kernel-panic-shutoff-on-mac-studio-kt-8785
Wow, thank you @Baktus for that link - this seems like exactly the sort of problems I'm having. One user even reported the same "it was working, I changed nothing, now it crashes hard" situation that I have.

Interesting that it may be related to monitors / resolutions / connection method. On my m1max laptop with no external monitors all is well. The crashes are only happening on my m2ultra Mac Pro with one 4k monitor and one fancy new Dell u4025qw (5k2k). Both are connected via 35' HDMI 8k cables, but I do have one of those fancy Corning optical TB3 cables I can try. Today I will fiddle with that stuff before going into Recovery Partition mode.

Users both here and on that NI Forums thread about the kernel panic issue are also complaining about much heavier RAM demands of k7 vs k6+k5, even with the same instruments loaded, which is also concerning. I haven't noticed this yet as I've been unable to effectively use k7 in any real workload.

I only "need" k7 to get access to a few recent libraries, but all told - I can live without.
 
The problem is that Kontakt 7 specifically bloats the project file size way too quickly. So even disabled it has massive overhead in filesize for some reason.
Kontakt always did this - depends which NKIs you load into an instance, they get stored in the project file ultimately. This way you can always recall the project exactly as you left it - it doesn't depend on the state of the NKI on the hard drive.

Kontakt 7 is not any worse in this regard, it works as it always did. In fact, recently there was an edge case fix that prevented bloating the project filesize if you attempted to load a project that contained references to missing samples. So, it's actually more efficient in that regard than it ever was.

As for RAM usage: new browser has a database and this database needs some memory. But this database is only loaded once, all Kontakt instances are sharing it.

even with the same instruments loaded, which is also concerning
I suspect those users might not have the same setting for global DFD buffer size override set. This setting is not carried over between major versions of Kontakt, one needs to set it manually.

And the rest of extra RAM usage is as above - the new browser. But this is a one-time cost, as already mentioned.
 
I tried disconnecting my fancy new 5k2k monitor, and only using one old 4k connected via HDMI and k7.10.5 still instantly hard-crashes. I did not delete all the prefs and app support folders though, would this be a critical step if the issue is in fact display-related?
 
Did you try to change the resolution and/or colorspace? But your crashlog points at a problem when attempting to create the database file, so I think the display stuff is a red herring.

Did the K7 folder in App Support get recreated? Do you see the .db3 file (even if it's a small one) in there?
 
The k7 folder in main Library>Application Support>Native Instruments did get created, but only contains a single folder called "presets", with another empty folder inside it called "Output Section", but there are no files in either folder.

The k7 folder in Users>Library>Application Support>Native Instruments also got created, and it contains the usual hailstorm of stuff - the only .db3 file is called "komplete.db3" and there is another folder called LibrariesCache which has 366 items totaling 115mb.

I've also tried booting up with only a single 4k display, at the default resolution of 4k; then with the resolution at 2560 x 1440 and 1920 x 1080, all at 30hz. In all cases, standalone k7.10.5 crashes but does not kernel panic and restart the machine, it's just a "normal" app crash. In all cases, Logic fails to validate the k7 AU so I cannot test inside the DAW. k7 actually crashes the auval app.

So I think you're right - in my case the problems are not related to display type / resolution / connection method. But k7 is dead in the water at the moment. The previous v7.8.1 still works on my m1max laptop and I'm not updating that one until we figure out what's up.
 
Try renaming the db3 file instead of deleting the whole folder, and I guess you did this already but double-check the permissions to that folder...
 
Try renaming the db3 file instead of deleting the whole folder, and I guess you did this already but double-check the permissions to that folder...
Renaming the .db3 file to.... what, exactly? Do you mean leave it in place and give it a nonsense name so that k7 will ignore it, or what?
 
Okay, tried that. Same result as before - standalone k7 draws the main window, mouse freezes, then hard black-screen crash and instant restart.

Interestingly, when I went into Users>AppSupport>NI, instead of just a single .db3 file named "komplete.db3" there were two other .db3 files present that I had not seen before, named "komplete.db3-shm" and "komplete.db3-wal".

I renamed all three of them, but left their suffixes intact and left them in the folder, and left the folder window visible so I could watch for any changes as k7 launched. As k7 launched I saw it create all three files anew, but after it crashed and the computer restarted, those files were no longer present - only my renamed versions were still there.

So then I tried moving the renamed versions out of the folder and launching k7. Same result, it attempted to create all three, restarted the computer, but after restart the "komplete.db3" file WAS present, but the other two with the -shm and -wal suffixes were not present.

The komplete.db3 file size is only 8k; the -shm file size is 33k and the -wal file size is 1mb.

There is also the LibrariesCache folder in that AppSupport folder, it contains 371 items totaling 117mb. If I remove that folder and launch k7, I can watch it get rebuilt, but k7 still crashes, and after restart it is no longer present.

Don't know if that sheds any light or what...
 
Last edited:
I know you said that installing new libraries won't break k7, but if it's a rebuilding-database issue that's causing my kernel panics, might that not be possible? The only thing that changed in between "k7.8.1 works fine" and "k7.8.1 kernel panics, better update to k7.10.5" was that I did install a half-dozen small-dev libraries using Native Access (and I have updated to yesterday's v3.12.1).

And for one of those new libraries (Impact Soundworks' "Special Reserve: Hyper Metals), after the problems started and I tried to uninstall it, Native Access v3.10.x showed that library's release version as being "0.0.0" which made me suspicious that the library dev did something bad, or that the DB was getting borked.... and that was the library that NA failed to uninstall (until yesterday's v3.12.1), and when it failed, NA threw up this notification banner which I had never seen before:

path not safe.png
 
Last edited:
Yeah I've never seen that error either. That sort of error might imply that a different process was still holding a handle to that path, so uninstall wasn't able to complete successfully (which would also explain the 0.0.0 version being displayed, too). And there are many thousands of users of Special Reserves libraries out there that had no issues whatsoever when installing them, so it's hard to blame it on that library specifically....

Another thing you might wanna try (just for kicks as I'm all out of ideas really) is copying the db3 file from your other working machine to this one. It's a hail mary...


BTW LibrariesCache folder contains images for Libraries tab for all installed products in one place, so that .nicnt files don't need to be scanned across many different places on startup. This is unrelated to the issue you're having. The crashlog points to the new browser specifically.
 
I know you said that installing new libraries won't break k7, but if it's a rebuilding-database issue that's causing my kernel panics, might that not be possible? The only thing that changed in between "k7.8.1 works fine" and "k7.8.1 kernel panics, better update to k7.10.5" was that I did install a half-dozen small-dev libraries using Native Access (and I have updated to yesterday's v3.12.1).

And for one of those new libraries (Impact Soundworks' "Special Reserve: Hyper Metals), after the problems started and I tried to uninstall it, Native Access v3.10.x showed that library's release version as being "0.0.0" which made me suspicious that the library dev did something bad, or that the DB was getting borked.... and that was the library that NA failed to uninstall (until yesterday's v3.12.1), and when it failed, NA threw up this notification banner which I had never seen before:

path not safe.png
Hey Charlie,

trying to follow your problem with crashes of K7. This path, that is shown in this error message by Native Access, does it still exist on your disk like this? Also wondering if the "dot" at the end was part of the path or just part of the message in NA?
Did you try to manually remove this path via finder?

As the crashes might relate to something in the paths written for that library, you would want to get rid of all its traces, which contain the path or the product name.

To clean your system from all traces of this library make sure to delete this content path, which was noted in the NA error message and also the JSON, XML and the PLIST files related to that particular library.

Keep Native Access closed during this process and when restarting K7. Because Native Access might/will rewrite the deleted XMLs and JSON files, maybe even the plist files.

/Library/Application Support/Native Instruments/Service Center/The_faulty_Library.xml
/Users/Shared/Native Instruments/installed_products/The_faulty_Library.json
/Library/Preferences/com.native-instruments.The_faulty_Library.plist


Does not hurt to also delete this folder before restarting K7, which is also used by the db3 (holds pics and meta data for the installed libs):
/Users/Shared/NI Resources

Hope this helps it, as I tend to believe also that it might be the borked install of one of the libraries you mentioned, which causes the db3 datatbase scan to crash.

Regarding the Kernel Panic thing caused by certain display setups, you tried 2 displays so far, right and the smallest one was still a 4k display?
If you have display at hand that is really low profile, I would give this another shot, as for some users this was the only way out if just cable or resolution change did not help. Try a TV maybe? Just to rule out any of this kernel panic related stuff.

cheers, Daniel!
 
Kontakt always did this - depends which NKIs you load into an instance, they get stored in the project file ultimately. This way you can always recall the project exactly as you left it - it doesn't depend on the state of the NKI on the hard drive.

Kontakt 7 is not any worse in this regard, it works as it always did. In fact, recently there was an edge case fix that prevented bloating the project filesize if you attempted to load a project that contained references to missing samples. So, it's actually more efficient in that regard than it ever was.
Dumb question: would it be terribly slower with modern hardware if Kontakt stored all that data to many small linked external files so that DAWs or hosts like VEP don't have to save all of that data themselves?
 
The end result would be pretty much the same I think. Except this data being external actually makes it way more volatile (since users can tamper with them). It's not going to happen.
 
I tried disconnecting my fancy new 5k2k monitor, and only using one old 4k connected via HDMI and k7.10.5 still instantly hard-crashes. I did not delete all the prefs and app support folders though, would this be a critical step if the issue is in fact display-related?
There were people having the issues with Kontakt 7 that were not using two monitors, especially in Logic. I could trace my identical issues with Kontakt to two monitors and an early version of Sonoma, it was all very DAW specific, DP and Logic but not Live, Reaper, and Bitwig etc. some people on Ventura did experience the kernal panics with Kontakt though. An update to Sonoma 14.5 solved it here.

IMO this is an issue that would be solved by updating Logic to 11 and Mac OS to Sonoma. You're in that zone of incompatibility IMO, and it's unfortunately because you're thinking you're playing it safe with a rare combination of Kontakt, OS, and Logic version.
 
Hey Charlie,

trying to follow your problem with crashes of K7. This path, that is shown in this error message by Native Access, does it still exist on your disk like this? Also wondering if the "dot" at the end was part of the path or just part of the message in NA?
Did you try to manually remove this path via finder?

As the crashes might relate to something in the paths written for that library, you would want to get rid of all its traces, which contain the path or the product name.

To clean your system from all traces of this library make sure to delete this content path, which was noted in the NA error message and also the JSON, XML and the PLIST files related to that particular library.

Keep Native Access closed during this process and when restarting K7. Because Native Access might/will rewrite the deleted XMLs and JSON files, maybe even the plist files.

/Library/Application Support/Native Instruments/Service Center/The_faulty_Library.xml
/Users/Shared/Native Instruments/installed_products/The_faulty_Library.json
/Library/Preferences/com.native-instruments.The_faulty_Library.plist


Does not hurt to also delete this folder before restarting K7, which is also used by the db3 (holds pics and meta data for the installed libs):
/Users/Shared/NI Resources

Hope this helps it, as I tend to believe also that it might be the borked install of one of the libraries you mentioned, which causes the db3 datatbase scan to crash.

Regarding the Kernel Panic thing caused by certain display setups, you tried 2 displays so far, right and the smallest one was still a 4k display?
If you have display at hand that is really low profile, I would give this another shot, as for some users this was the only way out if just cable or resolution change did not help. Try a TV maybe? Just to rule out any of this kernel panic related stuff.

cheers, Daniel!
Wow, thank you @Draman for such detailed info and instructions!

Unfortunately, none of these did the trick. I also tried again to remove every molecule of k7.10.5 from my system, and then move the identical molecules over from my still-functioning k7.8.1 laptop, and this did not work either. I went back through this thread as well as the ones I could find on the NI forums, carefully removing and replacing every bit that was mentioned anywhere, and even with a "transplanted" k7.8.1 install on my big machine, it still kernel panics in exactly the same way.

Perhaps the problem is actually buried somewhere deep within the NI Access / Player libraries databases, in some files that I didn't transplant or delete?

I also tried a few different monitors, including an ancient 1280 x 720 monitor that I managed to get recognized with a chain of adaptor dongles, and this didn't change anything.

So at this point I've already spent too much time and energy on trying to repair a broken sampler that I don't even use for serious work, so I'm throwing in the towel.

Maybe some future version of k7 or k8 will come with an announcement that the issue has been found and fixed, and I will read those release notes with interest.

Thanks to everyone who has contributed to my search for a solution, sorry I couldn't report success!
 
Back
Top Bottom