Bug: first script slot does not work correctly

Nickie Fønshauge found when using a test script of mine that scripts loaded in the first script slot handle note releases in an incorrect way (the other script slots are working correctly). Specifically if a script ignores the first note-off message the script's release callback will never again be run by Kontakt if the script is loaded in the first slot (it will for all other slots). The fact that this piece of code is not properly run can cause problems when the script depends on some cleanup being performed when a note ends.

This causes problems with the SIPS Legato script. Only load SIPS into script slots 2-5.
If the SIPS Legato Script is loaded in the first script slot on instruments with looped samples it can result in stuck notes. If it is loaded in the first slot on non-looped instruments the notes will not get stuck but I think the voice count will be higher than normal and it's not certain that legato transitions will sound exactly the same. Details and a script that can be used to reproduce this problem and discrepancy between slots can be found in this thread.

NI, please fix this!

 

Thanks for the tip on this, Kotori.

NI - I would also really like to see this fixed.

 

Yes, please fix.

 

This is a serious problem, that could potentially prevent many scripts from running in slot 1. Not a lucky situation, since there are only 5 slots and you are not likely to be able to change the script order.

BUG FIX, PLEASE!

 

Great detective work guys.

This needs to be addressed.

Thanks,

T

 

Hey NI, this is a serious problem! Until it's fixed, it needs to be publicized more widely than Nickie & Nils dropping a few posts wherever they can. I'm sure we would all feel better about this if someone from NI would acknowledge that they have now heard about this problem and help is on the way.

Bob

 

BUMP!

Still no NI acknowledgement?

 

I've reported it to the Kontakt bug database exactly as you guys stated it. I don't know when a fix might be coming.

 

Thanks for reporting this through official channels ddas.

Cheers,
T

 

Hi,

this is obviously a bug in the ksp engine and it should be fixed.
Thank you very much for reporting this bug on the forum, because now NI can fix it and we scripters can "live" with that bug, because it's not a bug which makes a correct working script impossible.
I had a look at the SIPS Legato script and found out, that the last parameter of fade_out is 0. Why not 1, which will stop the voice after fading out?
I tried it with 1 and the behaviour of the first and the other slots was the same and there was no higher voice count.
Another way to solve the problem would be to set the condition before note_off and not in the release callback if you want to ignore the note off the program called a millisecond before?

Best Regards,
Josef

 

Hi Josef,
Thank you very much for this comment and your kind suggestions. Yes, that change of the last parameter to fade_out has been made in the latest (soon to be released) version as a safety precaution. It's seems it is possible to workaround this bug in the SIPS case, so the biggest problem is probably the uneasiness this problem creates about not being able to rely on KSP's behaviour.

I'm not sure what you mean by "set the condition before note_off". If you mean performing whatever would've happened in the release callback at the point where note_off is invoked, then yes this might be possible in the SIPS case (the above workaround is better though). However, this cannot be done when polyphonic variables are used since KSP do not provide a way to access the polyvars of other note events than the current one (one of the bigger KSP limitations as I see it), so it's not a generally applicable approach. Thanks again.

Best regards,
Nils

 

Hi Joseph.... and welcome to the NI forum LOL ( I saw that was your first post) ;-)

Thanks for demonstrating the importance of this KSP fix.

Hope to see you around some more... and please... drop in to this KSP scripting forum and say "hello" some time... we'd love to see you there.

Cheers,

T

 

Hi Josef, and thanks for your suggestions which are very appropriate for the current version of K2. However, let me point out that some of the details in the behavior of the KSP has changed (mostly for the better) from the way things were when I first wrote SIPS.

In V105 I did use a 3rd fade_out() argument of 1. However, when I wrote the V110 update, I was concerned about another problem that used to exist. In fact, some of it is still with us. Consider the following:

When using fade_out(id,t,p), with p = 1, the voice dies after ‘t’ and the sample stops playing. Apparently the event is also retired but no RCB occurs. When the key is later released, nothing at all seems to happen and thus the K2 keyboard display shows the key still down. Any derivative note will also be left hanging. For example:

fade_out($EVENT_ID,2000000,1)
play_note($EVENT_NOTE + 7,127,0,-1)

will leave the derivative note hanging if the key is held down for longer than 2 seconds.

Because of this observation, I was somewhat worried about a sample 'running out' before the script could issue the needed note_off (after the bending interval had expired). So, in V110 I changed the 3rd argument from 1 to 0 so that at least looped samples would continue and their events remain alive after the fade-out. Besides, when the KSP is working correctly an argument of '1' is unnecessary.

However, it turns out that the latest version of K2 continues to properly respond to note_off commands (hanging note events are still 'alive') so it doesn't really matter whether the 3rd parameter is zero or one. And, since we have now discovered the 'slot 1' problem, using a 3rd argument of 1 has the added advantage of acting as a sort of 'safety net' so I already suggested that we change it back to 1 in releases subsequent to V110.

But keep in mind everyone that this is only a band-aid type of safety net and if possible, you should still avoid slot 1. It may also have other side effects and if nothing else, it will tend to raise the polyphony higher and longer than necessary. And, V110 still has the argument set to zero unless you custom edit it. Nils currently has a later version and when he releases that, it will have the 'safety net'. However, I still advise that you avoid slot 1 until NI fixes this problem.

God Bless,

Bob

 

I'm not sure if Joseph is actually "with" NI so I'm just bumping this so it gets noticed by NI.

Thanks,

T

 

A little update on this matter: Big Bob has written an excellent study of this problem which answers many questions (and asks a couple of new ones).

I recommend reading the full 10-page report but take the liberty of sharing some of its most important findings here. Assuming that all incoming notes are in some sense 'generated' in an invisible internal script slot 0 it seems that scripts depending on the release callback being able to trigger multiple times must be loaded in a script slot two steps away from the place where notes are generated. This explains why script slot 1 is always problematic for these scripts, but it also shows the general problem. Eg. if a script in say slot 2 generates notes or regenerates incoming notes any other script sensitive to this problem must be loaded at least two steps away from it (slot 4 or 5).