# Strange CPU peak problem... [SOLVED - Thanks] - Could be instructive for others



## Robym (Oct 17, 2019)

Hello,

We are doing 2 sequels of a library we already released some time ago.

I will call the already released library Lib A, and the ones we are working on Lib B and Lib C.

All libraries have identical script (apart from presets names etc...) with identical lines count.
All libraries have identical groups structure (identical Busses, fx, LFos etc...),and groups count.

Lib A contains 1GB more of NCW samples than Lib B and Lib C.
Lib B and Lib C contain more IRs (which are 30/50kb each) than Lib A and the picture files are the same in size and amount.
Lib B .nkr is 41MB, Lib C .nkr is 43MB and Lib A .nkr is 34MB.
Somehow Lib A .nki is 2.8 MB, Lib B is 1.8MB and Lib C is 1.9MB (it's possibly due to the fact that Lib A has way more zones than Lib B and Lib C - More than double).


Now, Lib B after starting up makes Logic Pro CPU peak at almost 90% (of one core)
Lib A and Lib C stay at about 15%. All Libs are loaded on same instrument channel, one after the other.
No other instrument or plugin is loaded in LogicPro. The CPU readings are done with GUI visible and transport not running, with instrument idle (not playing).

In K Standalone Lib A and Lib C CPU meter range from 0% to 2%
In K Standalone Lib B CPU meter ranges from 3% to 20% (never stops changing).


No matter if i load different samples in each, or different convolutions, or whether I turn off all FX or unload all IRs, the difference is still the same.
What makes Lib B peak so much?
Where do I need to look to fix this?

Any help is highly appreciated.

Roby


----------



## P.N. (Oct 17, 2019)

Hello.

If you got CPU fluctuations while the instrument is idle, the usual suspect is the LCB.
Another thing that influences CPU is not the number or size of IR files, but the IR frequency and lenght. (long IRs can cause instability).

Other than that, it's difficult to know for sure what's going on.

Cheers.


----------



## Robym (Oct 17, 2019)

Thank you PN

The only IRs which are not in common are very short cabinet and eq impulses (we are talking of a few samples in length, not seconds).

What do you mean with LCB? The listener callback?
they are identical.


----------



## P.N. (Oct 17, 2019)

Robym said:


> What do you mean with LCB? The listener callback?


 Yes. CPU fluctuations on an idle instrument normally means an open loop somewhere.
It could be anything from an animation to a complex function, so it's worth checking out.

Even if similar code produces different results, i'd go back to the LCB and make sure it's as optimized as it can be.

Cheers


----------



## Robym (Oct 17, 2019)

Thank you again for your help and time.

Sorry, maybe i was not clear.
The code is identical, copied and pasted, same number of lines, identical.
Checked back again line after line. 
Created for instrument 1, copied onto instrument 2 and then copied from instrument 2 to instrument 3.
100% identical.
But only instrument 2 gives problems...


----------



## P.N. (Oct 17, 2019)

I'm afraid i won't able to help beyond my initial suggestions.

The only other thing i can think of is getting rid of any message("") you might have anywhere on the script, so that you can further analyze the internal warnings that Kontakt may be outputing.

Also, making sure the NKRs are correctly created and assigned can sometimes fix issues like this.


----------



## Robym (Oct 17, 2019)

Thanks PN

NKR are all as they should be 

but at this point it looks that the only reason could be the samples.
I literally copied and pasted the script from instrument 1 to instrument 2, and still instrument 2 has problems.
I copied and pasted the script from instrument 2 to instrument 1 and instrument 1 is working fine with no cpu problems.

I copied all samples from instrument 2 to instrument 1 and the CPU usage has decreased considerably for instrument 2

There might be a dodgy sample somewhere.
Still looking...


----------



## Robym (Oct 17, 2019)

Yes it is definitely because of some dodgy samples...
4 out of the 200 groups contain zones that make the huge peak!
Deleting those zones, the CPU goes to 5% in logic and 0-1% in K standalone.

Worth noting that in Logic, by closing the GUI the CPU goes to 1%, while before it was staying around 50%.

So gotta understand what's wrong with those wav files, as they were created exactly like all other samples used in same instrument.....


----------



## EvilDragon (Oct 17, 2019)

Is HQI mode set to "high" or "perfect" for those groups, and are zones in those groups stretched a lot, or are in higher sample rate than your DAW project sample rate (or standalone soundcard sample rate)? That would be the reason.


----------



## Robym (Oct 17, 2019)

Update
things get even stranger:

I re-exported the wav files, they are all brand new, hopefully not corrupted.

By just replacing them in the sample folder, nothing changes, still huge peaks.
I had to re-do the mapping manually zone by zone in those groups, and now the peaks are less, but not as low as when i removed those zones completely (see above)

Then i noticed another group contained perhaps dodgy samples. After i removed, as a test, the zones from that group only, Kontakt CPU meter in standalone kept on spiking from 15% to 70% until when i put back the zones in and it got down to 0-10%

So i did another test, and removed all the zones again from those 5 groups (earlier i only deleted the zones from 4 groups - see above)...

Now kontakt keeps on changing from 10% to 35%, non stop....
So i closed it without saving and re-opened it:
now it goes from 3% to 12%....

it's definitely not a script problem... but what can it be?


----------



## EvilDragon (Oct 17, 2019)

Even if you completely bypass the script you still have peaks?


----------



## Robym (Oct 17, 2019)

EvilDragon said:


> Is HQI mode set to "high" or "perfect" for those groups, and are zones in those groups stretched a lot, or are in higher sample rate than your DAW project sample rate (or standalone soundcard sample rate)? That would be the reason.



Hi Evildragon, thanks for replying.

I'm not using sampler mode.
For ALL the groups in all 3 instruments i'm using TM Pro in normal mode (not HQ).
The zones are all mapped chromatically, not stretching.
Samples are all 44100 24bit, and my DAW and soundcard are both at 44100.


----------



## Robym (Oct 17, 2019)

EvilDragon said:


> Even if you completely bypass the script you still have peaks?



No, by bypassing the script slot, it goes to 0%
but the same exact script is in other 2 instruments which don't have CPU problems. And, as i mentioned, by swapping scripts the problem remains on this instrument alone....

the 3 instruments, apart from the samples content, are identical.


----------



## Robym (Oct 17, 2019)

Another update...

In LogicPro: if i bypass the script, Logic CPU meter goes to 0%.
Then when switch the script on again it goes back to 100%* BUT...*
when i close the GUI (Kontakt still active, just hidden), it goes back to 0%,* 
then when i re-open the GUI, the CPU stays at 1%.....*

so by bypassing the script once and then back ON again, hide and reveal the GUI, it works....
why????


----------



## EvilDragon (Oct 17, 2019)

If CPU spiking stops when you bypass the script, that means you have a script issue, for some reason. Definitely sounds like something related to listener callback. What happens if you comment out the whole listener callback in the script, THEN load your instrument?


----------



## Robym (Oct 17, 2019)

EvilDragon said:


> If CPU spiking stops when you bypass the script, that means you have a script issue, for some reason. Definitely sounds like something related to listener callback. What happens if you comment out the whole listener callback in the script, THEN load your instrument?


That would be the first thing as also PN has mentioned....
but the same script has no issues on other 2 instruments at all.

When i delete the on listen callback the spike goes down to 0% as expected (obviously the instrument does not work, but as a test..).


----------



## EvilDragon (Oct 17, 2019)

Doesn't matter if other instruments don't have the issue. Just means you need to thoroughly check what exactly in the listener callback grinds the CPU. It can also mean that the other instruments could develop the issue eventually, since it seems something in LCB is not exactly bulletproof. Can you post the code (with any associated functions called from LCB, if any)?


----------



## polypx (Oct 17, 2019)

Robym said:


> when i close the GUI (Kontakt still active, just hidden), it goes back to 0%,*
> then when i re-open the GUI, the CPU stays at 1%.....*



Do you have an animation in the GUI?


----------



## Robym (Oct 17, 2019)

EvilDragon said:


> Doesn't matter if other instruments don't have the issue. Just means you need to thoroughly check what exactly in the listener callback grinds the CPU. It can also mean that the other instruments could develop the issue eventually, since it seems something in LCB is not exactly bulletproof. Can you post the code (with any associated functions called from LCB, if any)?




Here's the LCB




```
on listener
  if ($NI_SIGNAL_TYPE = $NI_SIGNAL_TIMER_BEAT)
     $tempo:=ms_to_ticks(60000000)/960

    select ($sync)
      case 0        {original tempo}
        $time_division:=$DURATION_SIXTEENTH
      case 1      {halves the speed}
         $time_division:=$DURATION_EIGHTH
      case 2  and 3  {doubles the speed -  doubles the speed without stretch}
       $time_division:=$DURATION_SIXTEENTH/2
     case 4   {automatic}
        if ($tempo<%loop_orig_tempo[$preset_name])      {doubles the speed}
            $time_division:=$DURATION_SIXTEENTH/2
        end if
        if ($tempo>=%loop_orig_tempo[$preset_name] and $tempo<%loop_orig_tempo[$preset_name]*2)     {original tempo}
          $time_division:=$DURATION_SIXTEENTH
       end if
      if ($tempo<240 and $tempo>=%loop_orig_tempo[$preset_name]*2)      {halves the speed}
         $time_division:=$DURATION_EIGHTH
      end if
    end select
  end if



message("")
end on
```


----------



## Robym (Oct 17, 2019)

polypx said:


> Do you have an animation in the GUI?


Hi Polypx, thanks for replying

No animations...


----------



## EvilDragon (Oct 17, 2019)

OK so you're doing that on each and every listener tick, which is not necessary. It should only update those values if the tempo actually changed, and the way to do this is to use $DURATION_QUARTER, store its value to a variable, then test against it.


```
on listener
    if DURATION_QUARTER # prev_quarter
        <your whole LCB>

        prev_quarter := DURATION_QUARTER
    end if
end on
```


And don't do message("") in LCB. That's just uncool.


----------



## Robym (Oct 17, 2019)

EvilDragon said:


> And don't do message("") in LCB. That's just uncool.


Thats' just remnant as weeks ago it was messaging me stuff, i always delete them when i'm finished.

Thanks for the $prev_quarter thing. It's putting the CPU usage down.


----------



## EvilDragon (Oct 17, 2019)

Good!

You should always be wary of things like these. Do your calculations only when they are really necessary. There was no real need to constantly calculate what you calculated on every LCB tick.


----------



## Robym (Oct 18, 2019)

Thanks, lesson learned.

Still need to understand the issue with the samples/zones though....
Why deleting zones from a group makes K cpu meter go crazy... until i put them back


----------



## EvilDragon (Oct 18, 2019)

That I've no idea. Sounds quite bizarre.


----------



## ScoringFilm (Oct 18, 2019)

I have had issues in the past, when making significant changes to a script, Kontakt seems to remember the old settings/variables (i.e. searches for something that is not there any more). To resolve it I saved the instrument with a blank script then re-applied the new script once re-opened which seemed to fix it.

Not sure if that's the issue but give it a try.


----------



## EvilDragon (Oct 18, 2019)

Just applying a blank script then reloading yours should work the same way, no need to save then reopen NKI. Blank script resets all persistence.


----------



## Robym (Oct 18, 2019)

for some reason, after manually re-doing the mapping of zones for that group with same samples, now the peak is gone...


----------



## Robym (Oct 18, 2019)

EvilDragon said:


> Just applying a blank script then reloading yours should work the same way, no need to save then reopen NKI. Blank script resets all persistence.


i did not do that earlier (the blank script trick)

but i transferred this problematic script to another instrument of the same series (just different samples content), and that script did not cause any CPU issues on that instrument ...
that's why i was hesitant in thinking that the issue was the actual script, also because of the samples problem...


----------



## Robym (Oct 18, 2019)

so the takeaways are:


LCB - make it calculate only when there is a change (like on all other CB)
Sometimes manually re-doing the mapping fixes strange groups behaviours
Applying a blank script can sort out erratic behaviour
Sometimes Kontakt is just acting crazy
Same exact script might work in one instrument and won't work on another identical instrument
message("") on LCB is not cool!!! 
Always ask VI-control and some amazing people will be happy to help
Thanks all you guys, hope this will help others


----------

