I ran a very quick test and I am not sure if my statement about Kontakt inside Cubase or VE PRO stands true.  I just tried Kontakt inside VE PRO and inside Cubase 7.5.20.   I palyed a pad sound and had a tempo ramp constantly changing tempo.  Kontakt inside Cubase was fine until I turned Kontakt's delays on and then the delays sound like they are frying as they keep up with the tempo constant changes.   This is probably what I was hearing when I made the previous post.  Kontkat inside VE PRO is a little glitchy at my 128 buffer with 2 VE PRO buffers during the tempo change ramp.  Bumping it up to 4 buffers stablizes it and throwing on the Kontakt delays  creates the frying sound.  So barring the tempo delay FX issue during tempo changes I think Kontakt is probably ok inside Cubase.

However......    most of my giant template is inside VE PRO.  I hear glitching at tempo changes on more than just Kontakt in my template.  I hear it happen on my piano from Addictave Keys and other plugins as well all hosted in VE PRO.  Now there is a fair amount of CPU load across these machines and it does appear that these tempo changes in Cubase cause CPU spikes on the VE PRO machines leading to the glitches.

So......Kontakt definitely behaves better inside Cubase (my previous observation might have been related to the delays in Kontakt....I would have to go back and read my post).  I think this is more than JUST a Kontakt issue as I can see this problem happening on a machine that does not have any Kontakt's involved.   The common denominator looks more like this is a VE PRO issue in my opinion.

@dlp - no the repro I was referring to was my own.  3rd post down on the 4th page of this thread.  Entirely independent of VEP.  If you have Komplete it's easy to test.  I'd be interested in your results.

tempo changes during host synced delays are always going to be an issue no matter the host / sampler and this is not the problem we are discussing.  Check my post and see how you get on

Cheers

Cubase 5.5.3

VE Pro 5.3.13240 [VST 3, x64]

Kontakt 5.3.1.37

OSX.6.8

Tempo Sync'd Soundiron 'Angklung' in Kontakt, tempo ramp in Cubase; can't reproduce any CPU spike particularly and performance didn't suffer.

I chose 'Angklung' as having a kind of involved sequencer. Here, three of its parameters are CC-controlled.
I think I would look at things more specifically such as the particular Kontakt library ['LASS']  and versions of all of the above rather than go with simple correlations. I also see 'delays' as behaving specially...

What buffer are you at?    Try it with at least a minumum 128 sample buffer.

I see you are on an older version of Cubase.....don't know if there is anything different with that vs 7.5.x

-D

Guys, it doesn't happen with all instruments but only seems to with particularly complex ones.  Maybe it's to do with the degree of scripting but I'm unsure.  I chose 'Scarbee Clavinet - Full' for my repro because people are more likely to have NI Komplete rather than, say, Spitfire's Sable library for example.  I wanted the simplest repro possible and with only a single instrument than many are likely to have in their libraries.

The point is, that those of us in film & tv that run huge templates are bound to have issues if Kontakt's 'ext' sync to host tempo is engaged.  Most do not because they don't have massive templates, or don't use tempo changes, or don't require Kontakt syncing to host tempo.  It's simple not an issue for most people which is why NI haven't address this bug after many years.  

If I may add, The likelihood of a few different forces at play here is high. As Brett is saying, scripting of a particular Kontakt instrument and buffer size are definite culprits here. Im using a drum loop program with extensive scripting that is undoubtedly creating my issue when playing across tempo jumps with Ext Sync on. And that's without delay or effects even on. Delays chasing tempo changes, abrupt ones, is always going to be problematic, but a sequencer changing a tempo shouldn't have to produce a click or spike in the audio IMO.

And getting NI to offer a solution is the big issue for all of us, especially film/TV composers who use tempo changes all the time!

Mr Anxiety

Man, excuse my bad spelling........ wow!

@brett said:

Guys, it doesn't happen with all instruments but only seems to with particularly complex ones.  Maybe it's to do with the degree of scripting but I'm unsure.  I chose 'Scarbee Clavinet - Full' for my repro because people are more likely to have NI Komplete rather than, say, Spitfire's Sable library for example.  I wanted the simplest repro possible and with only a single instrument than many are likely to have in their libraries.

The point is, that those of us in film & tv that run huge templates are bound to have issues if Kontakt's 'ext' sync to host tempo is engaged.  Most do not because they don't have massive templates, or don't use tempo changes, or don't require Kontakt syncing to host tempo.  It's simple not an issue for most people which is why NI haven't address this bug after many years.  

Feel free to submit a support ticket with Native Instruments. The more noise we make, the more we might get a result from them!

Thanks for checking this out Civ 3!

Mr A

This did not need ramp changes to repro it, and the project uses high latency. I don't need to use synced delay in that instrument, fortunately. I've never seen the likes of what happened, I had to quit Cubase.

I don't think that is particularly heavily scripted compared to many things I use that do not have any problem... synced delays is so not me which may be why I don't encounter this.

I used to think I was alone on this issue until some recent digging unearthed a multitude of composers with the same issues.  I have since submitted

two tickest to NI for which I have received only the auto-reply to which you all are no doubt familiar.  It's truly a shame that NI hasn't addressed this

major issue.  Tempo changes are at the root of what a sequencer can excel at as well as being crucial in a film composers tool chest.  Here's what

I have discovered in trying to find a workaround or anything that might get this thing to work.  First off, this is definitely corolated with CPU usage

and buffer size in addition to project complexity.  They all really tie together ultimately in that the CPU can either handle it or not.  I concur that this

issue can happen outside of VE Pro as I can get it to happen when K5 is hosted in Nuendo.  As stated earlier, on very small projects this does not

present itself as there is evidently enough CPU overhead to compensate for what I believe to be bloated code in K5.  Again, ramps are way more

troublesome and can bring my 12core Mac, with almost all SSDs, to it's knees.  IMHO it's not the amount of playing tracks that matter, rather how 

many tracks are in the given project - regardless if they are playing or not.  Also, I don't believe this occurs in K4. I was testing yet again and was not

able to get K4 to fail which I think is good news and I have made NI aware of this. I'm afraid this won't help any of us but perhaps as some have

stated if we film and T.V. composers keep pressing maybe NI will fix this.  In the meantime any useful workarounds are all we can hope for.

FWIW, I almost never post but this problem is so glaring and doesn't occur with other plugins e.g. Omnisphere, RMX, U-he, Waves, UAD, etc.,

that I felt compelled to jump in the fray.

Mac 12core (2 x 2.93 GHz 6-core Intel Xenon) OSX 10.8.5, 64GB ram, Nuendo 6.x, 2 x 480 3GB/s SSD, 2 x 480 6GB/s SSD, 1 2TB 7200rpm

I can confirm nasty breakups with a single ramp tempo change in Cubase for SonicCouture Broken Wurli, vs a jump tempo change which is fine.
This project I'm going to exploit this particular instrument with sync delays, actually. But it is the ramp in this case. This is with very little else going on and what is is pretty negligible. Very high latency and I expect to have some wiggle room with a lot loaded, but this ramp can't happen, period.
I can work around using ramp changes but just reporting, I doubt it's a single instrument but Kontakt 5 talking to Cubase.

Gentlemen,

We have to keep on Native Instruments to get this problem solved. The more support tickets they see on this, the more likely they will address it..... plain and simple. 

Happy Holidays everyone!

Mr A

Glad I found this.  This bug is inexcusable, IMO.  My workflow is significantly hampered by this.  I submitted a Support Request to Native Instruments but am not holding my breath.  Here's to hoping...

-Jamie 

Wow. NI customer care seems to be in the dumps.

I have DP 8 running Kontakt 5 and Signal (obviously demanding external sync) and I'm getting HUGE cpu spikes when changing tempos. When I turn the ext sync off, the cpu spikes go away completely. I'm shocked to hear that NI is not responding to this bug at all.

Same issue here using multiple instances of Kontakt 5.4.5.307 in VE Pro 5.4.13715 with Logic Pro X 10.1.1 on a Mac Intel 2.66 GHz 8-Core Mac Pro (2009) with a couple i7 custom built slave PCs. I tun off External sync in Kontakt and problem goes away, but then I can use any tempo-synced looping softwares correctly when there's multiple tempo changes in the session.

WTF!?

2.66 GHz 8-Core Mac Pro Intel (2009)

OSX 10.9.05

64GB DDR3

Logic Pro X 10.1.1

VE Pro 5.4.13715

Kontakt 5.4.5.307

RME Fireface 800 I/O

this is from NIs official Updates page http://www.native-instruments.com/forum/threads/official-update-status-kontakt-5-upcoming-5-5.94387/

• No more CPU spikes during KONTAKT instrument playback when manipulating the host tempo

This thread provides information about upcoming patches for Kontakt. It will be updated whenever new information becomes available.

---------
The currently available software version is 5.4.3. Please make sure that your installation is up to date.
--------


Upcoming version: 5.5

---------

The patch is currently in this phase:

• specification
• development
• beta testing
• final testing

For an explanation of the different phases, please see the section below.

---------

The update will include the following improvements:

FEATURES:

Extended KSP format plus additional parameters for the KONTAKT engine, for optimised engine use with new instruments.

• Control Time Machine Pro voice settings from KSP
• Change the contents of FX Slots from KSP
• Control time-related effect parameters (Delay, Chorus, Flanger, Phaser) via KSP

Time-related parameter handling

• User interaction options for time-related effect parameters are improved, and behaviour is more consistent

Improved performance

• No more CPU spikes during KONTAKT instrument playback when manipulating the host tempo
• Improved performance for processing MIDI CC events

FIXES:

• Fixed parse errors in Sonar Platinum
• Automatable parameters are now updating correctly on Komplete Kontrol and Maschine hardware
• Fixed CPU spike when changing tempo
• Fixed crash with corrupted database
• Fixed automatable parameters not being saved with a project
• Fixed CPU spike when changing EQ Gains
• Various other minor fixes

This list is subject to change, and does not necessarily list all features and fixes that will be in the final update.

So was this fixed for anyone? It seems to still be an issue for me in Cubase when I use Ramp tempo changes at low buffer sizes. If I raise my buffer size up to max they play back fine, or if I turn off tempo sync, but I need tempo sync on for the instruments that do use it in my piece. 

So is this problem 100% fixed with other users? Is it possible to instead of using ext tempo sync, to autmate the tempo in Kontakt manually in Cubase? 

Edit: turns out this was a very specific patch causing my problem. Perhaps it has been fixed then? 

Still awful here unfortunately....not fixed.

Hi JT3

No, not fixed at all here.  NI reports improvements in other hosts but 'off the record' I've been told that cubase handles tempo changes worse than other hosts and that NI simply doesn't see fixing this properly as a priority given many users have reported some improvements.  Certainly doesn't help those of us with large templates.

So far as workarounds go, spreading the load across greater instances of Kontakt can help (for example, I was an avid user of Kontakt banks meaning I could load huge numbers of patches in a songle Kontakt instance - bad idea in this case) and you might find having more vi-frames holding fewer kontakt instances may also help but ymmv on this one.

Brett