# Official list of KSP bug fixes in 2.1



## kotori (May 1, 2006)

This bug fix list can be found at the end of the readme file in the Kontakt folder. There all kinds of bug fixes there (not just scripting) so please check it out and see whether the bugs that have been troubling you are supposed to be fixed. 

Here are the script related bug-fixes:
SCRIPT: Abfrage des Effekttypes funktioniert nicht bei send effekten
SCRIPT: Build in variable $START_CRITERIA_ON_KEY wrong
SCRIPT: Bypass status graphic does not update correctly
SCRIPT: CC 120/123 (all sound/notes off) madness
SCRIPT: clicking on Release Trigger resets values in any script
SCRIPT: Edit script -> windows for password out of screen
SCRIPT: Engine parameter for Gainer missing
SCRIPT: IR Sample Path broken on MAC
SCRIPT: noice with fade_out
SCRIPT: Knobs folgen Controller aus dem Script nicht
SCRIPT: KSP produces stuck notes
SCRIPT: Microtuning script issue
SCRIPT: Problem with keeping persistent variables 
SCRIPT: Saving script (protected) and loading in other slot unprotects script
SCRIPT: Script GUI's not correctly updating K2 parameters
SCRIPT: _get_folder($GET_FOLDER_LIBRARY_DIR) not working in multi
SCRIPT: script ui can cause a K2 crash & problems with ASIO4ALL
SCRIPT: Script-generated text should clear when script clears
It seems they haven't even tried to fix the change_vol noise problem. Now I'm dissapointed. :evil: 
Nothing much has been done about release triggers either. Btw, does that script protection bug mean that the code of any protected script can be read by just saving it as a preset and then loading it in a new slot in earlier versions of K2!? If that's the case the bug fix won't work unless they made the new preset format unreadable to earlier versions of K2.

The new engine parameter control functions and UI flexibility is very nice, but I don't know how useful these features really are without the core functionality working without problems. I really wish NI would do a better job fixing bugs before introducing new features!

Nils


----------



## Thonex (May 1, 2006)

Thanks Kotori for posting this.

I too am disappointed about the lack of effort to fix the change_vol() bug.

But, I'm guessing that if we can control Flex envelopes well enough through a script, that Flex envelopes may be a more elegant solution for legato scripting down the road anyway.... no?

With a flex envelope, you can have up to 64 (I believe) nodes... and I think you can contol each node via the script... no?

Cheers,

T


----------



## kotori (May 1, 2006)

Hi Thonex,
I haven't looked into scripts controlling Flex envelopes yet. That's an interesting thought.
However the problem is that they can only be controlled at the group level whereas the change_vol function can control the envelope of individual notes. But if there are only two notes involved one could make a copy of all groups and assign different envelopes to these two collections of groups as a workaround.
I wish NI were to implement a function like this: note_envelope($EVENT_ID, $time_span, %my_control_points, $type_of_envelope)
That would be better than doing a busy loop in KSP calling change_vol.

Btw. for anyone interested I posted the complete list of bug fixes in a thread at the NI forum.

Cheers,
Nils


----------



## Big Bob (May 1, 2006)

Thonex @ Sun Apr 30 said:


> Thanks Kotori for posting this.
> 
> I too am disappointed about the lack of effort to fix the change_vol() bug.
> 
> ...


Hi Andrew,
I agree with Nils on this, we must have some means of *individual note *volume shaping available and right now all we have are fade_in, fade_out, and change_vol. While fade_in/fade_out are working properly, they are very limited in the accuracy of control versus time. That leaves us only the change_vol function to provide static control or precise volume versus time control (at the individual note level). Without this function working properly and/or without a suitable replacement (such as the one Nils just suggested), we are very limited as to the magic we can perform.

I also agree with Nils that some of the new features are nice but, I would gladly give them up to get all the old features working right. After reporting KSP problems starting back in May of 2005 with no kind of meaningful response from NI, I posted a list of 6 highly-reproduceable KSP bugs on January 22, 2006 at Markus' request. It was a very detailed report and included small scripts that easily and clearly demonstrated the problems. I won't repeat the entire text here, but here is a summary.

1. The play_note() function intermittently produces 'hung' or 'stuck on' notes. This problem generally occurs when the MIDI data stream contains very short notes.

2. The change_vol() function doesn't work properly when the 3rd argument is set to zero and it's used in conjunction with the wait() function.

3. The change_vol() function produces noise artifacts when called rapidly in a loop.

4. The ui_value_edit control is not handled properly when embedded in a Conditional Compilation (or pre-processor) block.

5. ui_value_edit boxes chop off the display of large numbers in a very hoaky fashion both on the left and the right.

6. The fade_out() function has a 'hanging note' problem when using '1' for the 3rd argument.

I have just retested these 6 issues with V2.1 and the results are not too impressive (since we have been waiting nearly a year for this update). First the good news: NI may actually have fixed #1 (at least it now gets through the simple test I had posted so they definately tried to do something about this problem). They also seem to have done something about #5, but that's it. Problems #2, #3, #4, and #6 are still with us and according to the readme list, haven't been touched. Moreover, at Markus' own admission, #1 had to be fixed for Bandstand, and not because we complained about it.

I might also mention that they did do something favorable about the CC123 problem that has been giving a lot of us trouble. It remains to be seen if the SIPS issues with freezing up when running with some hosts has been cleared up or not.

So, at least as far as the KSP is concerned, I find V2.1 very disappointing so far. I would also have posted about this on the NI forum but it seems to be down again and, of course, that's yet another problem. I think NI is desperately in need of some kind of attitude adjustment.

Bob


----------



## Thonex (May 1, 2006)

Big Bob @ Mon May 01 said:


> I agree with Nils on this, we must have some means of *individual note *volume shaping available and right now all we have are fade_in, fade_out, and change_vol. While fade_in/fade_out are working properly, they are very limited in the accuracy of control versus time. That leaves us only the change_vol function to provide static control or precise volume versus time control (at the individual note level). Without this function working properly and/or without a suitable replacement (such as the one Nils just suggested), we are very limited as to the magic we can perform.



The way I'm looking at it... and I may be wrong here... is that yes.. a Flex Env may be for an entire group, but all the nodes could be controlled by the script on a 'per note' basis... so in essence each note would have it's own 64 node dynamic ADSR. 

Also, I'm not saying that we shouldn't use the built in fade_in/fade_out.... I'm just trying to come up with a variable attack volume scenario that we haven't explored yet. Also, to take this one step further... (again I'm not even sure if this is possible in K2) but assigning the Flex Envs to pitch could also provide some creative solutions... ie. overshooting a note's target pitch... different log/exponential type curves etc.

Just thinking out loud here.

T


----------



## Thonex (May 1, 2006)

kotori @ Mon May 01 said:


> Thonex @ Mon May 01 said:
> 
> 
> > The way I'm looking at it... and I may be wrong here... is that yes.. a Flex Env may be for an entire group, but all the nodes could be controlled by the script on a 'per note' basis... so in essence each note would have it's own 64 node dynamic ADSR.
> ...



You probably did understand me.... but I'm hoping that, much in the same way (for example) velocity can control a note's ADRS that Flex envs might be able to do the same thing?

T


----------



## Big Bob (May 1, 2006)

Thonex @ Mon May 01 said:


> Big Bob @ Mon May 01 said:
> 
> 
> > I agree with Nils on this, we must have some means of *individual note *volume shaping available and right now all we have are fade_in, fade_out, and change_vol. While fade_in/fade_out are working properly, they are very limited in the accuracy of control versus time. That leaves us only the change_vol function to provide static control or precise volume versus time control (at the individual note level). Without this function working properly and/or without a suitable replacement (such as the one Nils just suggested), we are very limited as to the magic we can perform.
> ...


Yes, this would all be wonderful if you could apply it on an event by event basis but I don't think you can. So, just as a suggestion, why don't you try some simple experiments with these ideas and see if you can get individual note control?

God Bless,

Bob


----------



## Thonex (May 1, 2006)

Big Bob @ Mon May 01 said:


> Yes, this would all be wonderful if you could apply it on an event by event basis but I don't think you can. So, just as a suggestion, why don't you try some simple experiments with these ideas and see if you can get individual note control?
> 
> God Bless,
> 
> Bob



I will when I'm done with these projects. I think Theo told me that Stradavri uses no ADSRs and only Flex Envs. I could be interesting if it really works... 

Cheers,

T


----------



## Big Bob (May 2, 2006)

Thonex @ Mon May 01 said:


> Big Bob @ Mon May 01 said:
> 
> 
> > Yes, this would all be wonderful if you could apply it on an event by event basis but I don't think you can. So, just as a suggestion, why don't you try some simple experiments with these ideas and see if you can get individual note control?
> ...


Hi Andrew,

I've been thinking about this a little bit and it occurs to me that if we can get users to warm up to the idea of modifying their instruments in order to get the most from certain scripts, we can probably squeeze more overall performance out of K2. This combination of script and customized instruments working hand and glove has a lot of promise. (I think this is essentially what Thomas J, et al are doing for example). In fact, until NI fixes some of the crippled features and adds more control for the KSP, this combination of script and custom instrument may be our only way to work around certain problems.

On the other hand, there will probably always be a group of users that just want to load a script and go (without having to get involved in special edits and or sample libraries). So, I guess maybe both ideas will persist. In any case, isn't it wonderful that the choices are now moving toward Excellent results by just using a script and possibly 'Outstanding' results with the combos (as opposed to the old days where everything turned out Good to OK no matter what we did :cry: )? Things are truly getting more interesting no?

Keep us posted on how you fare with your flex envelope experiments, we'll look forward to more excitment ahead.

God Bless,

Bob


----------

