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

I've found another form of a work around.  (dare I call it a fix)

I have an insanely large template 1000+ instruments spread accros 6 VEP instances.  I found that not all of the 6 instances were getting CPU spikes during tempo ramps.

I then narrowed it down further by disabling external sync in Kontakt to find specific kontakt instruments that would cause spikes.  I found that in my case Action Strings were causing the spike.  If I removed them - I no longer have spikes during tempo changes.

So I'm going to go through my whole template and find patches that are tempo sync'd and causing this spike issue.  I'll then place them on a seperate VEP which I'll know to disable if I'm gonna have a tempo ramp.

I'll just have to learn to not write with those specific patches during a cue with a tempo ramp. But this way it frees up the rest of my 1000 instruments and "quarenteens" the few problem children.

I'd be curious to see if this helps anyone else.