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

[EvilDragon]

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]

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]

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]

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]

That I've no idea. Sounds quite bizarre.

 

[Jay EM]

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]

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]

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

 

[Robym]

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]

so the takeaways are:

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

Thanks all you guys, hope this will help others