Kontakt 4 cuts off notes during mixdown

I have a piece of music that is less than two minutes long that contains only the following factory instruments:

Abbey Road - Early 60s Kit Essential
Scarbee A-200
Trombone
Trumpet Section
Scarbee MM-Bass

I tried this in both Kontakt 4.1 and 4.2.3 with the same results. If I play it, everything works fine. If I mix down I get cutoff notes on either Abbey Drums, Scarbee Bass or Scarbee A-200. This happens about 99% of the time and it happens in different places. There is sustain pedal in both the Bass track (for slides) and in the A-200.

This problem seems like it is very similar to the problem in this post.

I am on a PC and am using Metro as my DAW. This has not happened with any of 100's of other plug-ins I have used including several made by Native Iinstruments. I am able to mixdown the piece in real-time using Metro's 'record direct from master output' feature.

Is there a limitation in the Kontakt Scripts?

If anyone would like to try this on their machine on a different DAW, I would be more than happy to supply a MIDI file and a .nkm multi for Kontakt 4. Just ask.

 

I think if you use fast offline mixdown Kontakt cannot read all sample portions so quickly from disk. I noticed when disk is very defragmented these cut-offs appear more often. I usually do render separate tracks to wav.
If you like, I can play with your midi in Reaper. Just send me pm.

 

Hello ruslan.st,

Thank you for your reply. Kontakt can read samples fast enough. I have no problem with using kontakt for fast mix down with most samples and I have sample loading in background off. It is only these scriptable instruments that seem to be a problem.

The whole point of a fast mix is that the plug-in can take as much time as it needs to render what it is supposed to. i.e. Don't return to the host until the job is done. This is a bug.

I have attached a zip file that contains a .MIDI file and a .nkm file. Load the nkm into kontakt and then import the MIDI file and assign all of the MIDI tracks to Kontakt.

I just tried it and did a mix down and it almost worked. If you are not paying attention it may appear to be okay but be sure to compare the mixdown to live playback. The SA200 has a vibrato sound on all sustained notes. If you retry the mix is seems to get worse.

 

I have tested attached midi, but I do not have some libraries, so I replaced sounds from factory library. There were no cut-off samples during rendering.

 

Thanks for testing but I believe it is these specific libraries that are causing the problem.

 

I finally discovered a workaround for anyone that experiences this problem with Kontakt 4.

Go to Kontakt 4 options dialog and be sure that 'override instrument's preload size' is checked. I just left it at 60k and now I can render/mix no problem!

This could also solve the problem (as seen in other threads) whereby users experience a major slow down of Kontakt 4. This slow down occurs when the host calls the VST method GetChunk. I believe this because I too was experiencing a major slow down and have conclusively narrowed it down to the GetChunk call. However after I changed the above setting Kontakt 4 responded lightning fast!

I am hoping it stays that way.

 

The reason you got notes dropping out was probably a small DFD buffer, which makes your hard drive seek a lot more, depending on the setting. By overriding the individual instrument DFD settings (available in Instrument Options), you gave your hard drive some more leeway to do all that it needs to do besides streaming (audio track readouts, etc.) when laying a render. Of course, this also depends on your hard drive speed, its fragmentation level...

Glad you made it work!

 

That is not true. During Mixdpwn or render, there are absolutely no time constraints placed on the hard drive! The host asks the plug-in for data and the plug-in can take as much time as it needs, even more than real time. So why would the notes be cut off only during mixdown? That is backwards.

 

only within the context of the current kontakt settings. oF course it will put pressures on your hard drive if you select different settings

 

Of course there are! When you're rendering a project, the MIDI data actually gets played, but you don't hear it. So, if you're doing a non-realtime render, all the MIDI data is read faster, so hard disk can come to the point where it can't cope with DFD anymore.

 

Unfortunately you don't know what you are talking about. MIDI data passed to a VST plug-in is done in memory. There is no disk reading involved. At least in my host. Believe me I know as I am a host developer.

What is DFD? Direct from disk? If yes, then why would there be any time constraints? When you are playing in real time you have a race against real time. You have to deliver 44k samples within 1 second (assuming a 44k sample rate). When you are doing an offline render there is no real time constraint. If, for example, the hard disk had an error and had to retry 50 times to read a portion of the disk before it succeeded, the resultant audio will still be good.

As for MIDI, the host sends the plug-in, in memory, a list of events to render to audio. Where is the constraint here? There is none. In a non-realtime situation if a correctly written plug-in takes 5 seconds to process one MIDI note it will still produce good audio. If the host is reading MIDI data off the hard drive (which is a bad design to begin with) then it still will not affect the audio produced by a correctly written plug-in because there are no time constraints in a non-realtime situation.

 

Sagantech,

We do know what we are talking about, but, hey, you know best

 

MIDI data IS passed to the plugins in the memory, but the samples STILL need to be fetched from the drive. And if the readout is asked for too many times in too small timeframe, dropouts occur.

I know what I'm talking about.

 

Uh huh, the readout? asked too many times?

Are those technical terms?

 

They are good enough to convey what is going on and why the dropouts occur.

 

OIC, now software bugs can be blamed on the uncertainty principle. :lol:

 

no bugs at all, just normal behaviour that can be configured easily enough to your requirements.