Kontakt VST3 cutting off long notes randomly when bouncing to audio???

Coming back to this thread as still having the same issue on the latest versions of Kontakt and wondered if anyone had had any breakthroughs... Am constantly wasting hours having to check over all my Kontakt stems and then inevitably realtime exporting them!

Edit: started a discussion over on the NI forums in case it gets in front of more NI people there:

TL;DR: Solution (for me this time) was slightly humanizing the notes before bounce. It's not the solution, but apparently sometimes that can work.

Might as well share my take. Experiencing this on Cinematic instruments as well, which is a little ironic, since I think they are my most expensive instruments (they do sound good but would expect them to work technically too).

It appears to happen mostly on render only, but occasionally you can reproduce the note dropouts on playback as well. For example, looping only the problem notes and the notes before them sometimes results in the same note dropouts in playback as in render.

Furthermore, if you have Kontakt open with its Keyboard toggled while bouncing, you can actually see that the dropped notes are not being "pressed" on Kontakt's keyboard at all during rendering. I don't know if that's useful info on troubleshooting to anyone, just caught my eye.

I take it 100% of the people here have tried this, but depending on the extent of the note dropouts in section, I find that sometimes the problem is solved simply by rebouncing. Of course that will easily get rather frustrating as well if it does NOT solve the problem, as rebouncing may render the initially dropped notes, but drop some new notes instead... Rebouncing a few times is usually my go-to solution.

None of the solutions suggested in this thread have worked for me (separately or together):
- DFD -> Sampler = no effect
- Maxing out preload override = no effect
- Changing offline interpolation to Perfect = no effect

I was just now fighting with this problem for a particularly long time (once again, and hence being here typing this message from google rn), and what actually finally fixed the problem was slightly humanizing the notes before bounce. I can't believe it. Normally I always use humanizing with instruments like this, only this time I had it quantized, and the problem was exceptionally persistent. I bounced it multiple times after humanizing and no note dropouts. So, might be wrong here but my quick speculative conclusion is now that humanizing reduces the chances of this problem occurring (doesn't solve it tho).

Well, f*** me, humanizing didn't work anymore next time; probably it was pure coincidence that it rendered all notes correctly for a while after humanizing (as appears to be the case with rebouncing - often seemingly entirely up to random chance).

Yeah… unfortunately I get this problem regardless of quantising/unquantizing, and rebouncing doesn’t fix the issue consistently for me. The only actual “fix” has been rendering online… which is okay if you’re doing it once, but it makes doing stems an absolute nightmare!

Talking about a nightmare, in the end I saw no other choice but exploding all simultaneous notes of different pitch (i.e. chords, mostly) to their own tracks and inserting a new Kontakt instance with the same instrument to each one (each instance playing only 1 note at any time). That was a ton of extra work and might continue to be a nightmare later, and I still had to do a couple of rebounces to get all rendered, but at least it is now rendered properly, lol! Could be a coincidence, but I think Stradivari Cello has so far been the worst. Problem doesn't seem just as bad with the violins...

We encounter this problem in NotePerformer 4/NPPE since we offline process all Kontakt instruments faster-than-realtime.

On my 10-core Mac M1 configuration, Kontakt 7 (VST3) drops many notes if processed with five or more parallel threads at 100% CPU. That's five cores, each running a different instance of Kontakt, bouncing without pause.

One, two, or three parallel threads don't seem to reproduce the problem.

More precisely, the preload and release samples work, but there's silence in-between.

It's the loop crossfades in DFD mode. Under certain circumstances they just give out. See this NKI. Try playing it, it will cut out after a couple of loop repeats. Set loop crossfade to 0, everything works fine.

Ok I figured out why Stradivari Cello is the worst: it's because apparently the instrument is not even meant to be able to play chords, which is what my notation was. It appears it is not meant to be able to perform anything that a single player playing a single cello isn't. Gotta check if this is the case with the other Cinematic/Cremona instruments as well, because that will definitely explain part of the problem for me.

Was perhaps second time using the cello, was already used to lesser note dropouts with the violins so I just assumed it was the same problem. Feeling pretty dumb for fighting for hours just to realize the instrument was working as intended all along. In my defense, I have yet to find any mention of this "simultaneous note" limitation anywhere, including the manual. I realized it by staring at the finger position view of the instrument while playing some chords. Suppose I just assumed it works like the other Kontakt cellos...

Anyway, just thought I'd clear this up in case it helps future note dropout sufferers; in addition to the actual bug, the instruments are not able to play arbitrary simultaneous notes by design. Don't confuse these two things like I did for a while there.

oinha said:

In my defense, I have yet to find any mention of this "simultaneous note" limitation anywhere, including the manual. Suppose I just assumed it works like the other Kontakt cellos...

Click to expand...

I mean, this is how solo cellos work, one note per cello player ordinarily. A player can play certain double stops, triple stops and even quadruple stops, but you have to know what you are doing when writing them. It's true that many cello VIs allow you to play multiple notes and thereby turn your single cello into a set of cello players, but that's what you are doing when you play the instrument that way, turning your solo cello into a set of players.

jbuhler said:

I mean, this is how solo cellos work, one note per cello player ordinarily. A player can play certain double stops, triple stops and even quadruple stops, but you have to know what you are doing when writing them. It's true that many cello VIs allow you to play multiple notes and thereby turn your single cello into a set of cello players, but that's what you are doing when you play the instrument that way, turning your solo cello into a set of players.

Click to expand...

Yeah it makes perfect sense. I just have a bunch of cello and violin instuments from NI previously and none of them have had this kind of functionality + having already experienced note dropouts with the same instument family + just replacing old cello chord notation with Stradivari (mostly expecting it just to sound better) = it just didn't occur to me until now. Would still assume it would be stated somehow in the manual though.

Update: I'm currently on with NI support about it. Have submitted a demo Reaper project to the devs - empty except one instance of CSS Violin 1 with audio examples that's dropping out on offline render. Literally just loaded the instrument in, played in a line and exported offline and this was the result.

You can hear it glitching out several times, especially noticeable dropouts after 00:11.

Please do get in touch with NI directly or chime in on the above NI forum thread if anybody has any extra info - it would really help get this in front of them!

EvilDragon said:

It's the loop crossfades in DFD mode. Under certain circumstances they just give out. See this NKI. Try playing it, it will cut out after a couple of loop repeats. Set loop crossfade to 0, everything works fine.

Click to expand...

Is there any chance NI will fix this at some point? There are some instruments you can't edit because the developer locked the library, while others (i.e. orchestral instruments) are simply far too complex to fix the issue across all samples in multiple patches... Not to mention that it really shouldn't be up to the user to have to fix an issue that has been known for years now....

jcrosby said:

Is there any chance NI will fix this at some point? There are some instruments you can't edit because the developer locked the library, while others (i.e. orchestral instruments) are simply far too complex to fix the issue across all samples in multiple patches... Not to mention that it really shouldn't be up to the user to have to fix an issue that has been known for years now....

Click to expand...

Yeah this bug is a major drag and making me glad many of the big devs are moving to their own proprietary players. NI needs to put some more energy behind this issue.

It's on Kontakt team's radar, but no timeline on the fix due to other more time-pressing priorities. You'll know what I mean...

studioj said:

Yeah this bug is a major drag and making me glad many of the big devs are moving to their own proprietary players.

Click to expand...

Other players have their share of issues too.

EvilDragon said:

It's on Kontakt team's radar, but no timeline on the fix due to other more time-pressing priorities. You'll know what I mean...

Click to expand...

Forgive me, but I don't know what you mean! (Not meaning to be difficult, just interested to know what is more time-pressing priorities-wise.)

Just from the responses in this thread and elsewhere, it's clearly something that's been affecting many users for years now which surely makes this a very high-priority bug to fix.

EvilDragon said:

Other players have their share of issues too.

Click to expand...

Sure - but I'd argue that not being able to render these libraries offline successfully is a major, game-breaking issue for professional users, and I've never had to spend hours re-exporting stems with any other sample player.

This problem isn't an occasional bug under very specific conditions -- offline rendering simply doesn't work properly with certain (expensive!) Kontakt libraries.

studioj said:

NI needs to put some more energy behind this issue.

Click to expand...

The best (and only) thing we can do as users is to get in touch with NI directly to bring it to their attention!

I have stopped purchasing Kontakt libs in 2019 until this issue is fixed. Didn't even upgrade to Kontakt 7.
It's just too much money for me as hobbyist to get instruments that are only partly usable. Sorry.

I deleted all software from my daw that has issues or unfixed bugs because i want a stable setup. The only reason I don't delete Kontakt is that I have many really great libs and there's no real alternative to them. And I know Kontakt as I've been using it for almost 18 years.

inthevoid said:

(Not meaning to be difficult, just interested to know what is more time-pressing priorities-wise.)

Click to expand...

I cannot say specifically. Everything will be clearer soon enough.

inthevoid said:

This problem isn't an occasional bug under very specific conditions -- offline rendering simply doesn't work properly with certain (expensive!) Kontakt libraries.

Click to expand...

It IS a bug that happens under very specific conditions, it's just that certain libraries use the feature that leads to these conditions in greater capacity, so it happens more often. Unfortunately, these conditions are non-trivial and the fix needs a thorough investigation as it's in a very critical part of the codebase (the whole direct from disk streaming code), so it is not something to be approached lightly. However there ARE things that have higher priority to be done first, coming from higher up the company. You will see.

EvilDragon said:

I cannot say specifically. Everything will be clearer soon enough.


It IS a bug that happens under very specific conditions, it's just that certain libraries use the feature that leads to these conditions in greater capacity, so it happens more often. Unfortunately, these conditions are non-trivial and the fix needs a thorough investigation as it's in a very critical part of the codebase (the whole direct from disk streaming code), so it is not something to be approached lightly. However there ARE things that have higher priority to be done first, coming from higher up the company. You will see.

Click to expand...

No problem - totally understand!

EvilDragon said:

It's the loop crossfades in DFD mode. Under certain circumstances they just give out. See this NKI. Try playing it, it will cut out after a couple of loop repeats. Set loop crossfade to 0, everything works fine.

Click to expand...

I just had a chance to test this. On my system the loop plays without cutting out regardless of loop crossfade value...

EvilDragon said:

I cannot say specifically. Everything will be clearer soon enough.


It IS a bug that happens under very specific conditions, it's just that certain libraries use the feature that leads to these conditions in greater capacity, so it happens more often. Unfortunately, these conditions are non-trivial and the fix needs a thorough investigation as it's in a very critical part of the codebase (the whole direct from disk streaming code), so it is not something to be approached lightly. However there ARE things that have higher priority to be done first, coming from higher up the company. You will see.

Click to expand...

Are you sure that's not a separate issue? We get dropouts also with pizzicato samples that aren't looped. Here's an example:

Looped drop-out:

Non-looped (pizzicato) dropout:

I can easily reproduce it with our internal tools by bouncing five or more threads running Kontakt asynchronously, on a system with more than four CPU cores.

It could be random, but we didn't notice the problem in the early development stages when we targeted the VST2 of Kontakt. From my perspective, it looks like the Kontakt VST3 intentionally drops disk-streamed audio when exceeding 400% CPU, despite setting the offline mode state for the Vst.ProcessData structure in VST3.

inthevoid said:

I just had a chance to test this. On my system the loop plays without cutting out regardless of loop crossfade value...

Click to expand...

Again it's not ALWAYS happening. It's in specific circumstances. If you play with setting up loop xfades long enough it will happen.

Wallander said:

It could be random, but we didn't notice the problem in the early development stages when we targeted the VST2 of Kontakt. From my perspective, it looks like the Kontakt VST3 intentionally drops disk-streamed audio when exceeding 400% CPU, despite setting the offline mode state for the Vst.ProcessData structure in VST3.

Click to expand...

I've looked, and I couldn't see any code that would do this specifically for VST3 only... The actual voice processing code is plugin type agnostic and supports up to 16 threads.