KSP+release triggers in need of a redesign/update

Hi,
handling release triggers in scripts is, pardon the expression, a royal mess at the time.
Any script that changes the volume, panning or tuning of a note (simple and common operations!), or wants to control when release samples are used and when they are not, or wants to control exactly which samples are used and possibly use multiple ones has to deal with release triggers explicitly. Only in the last (and most uncommon) case should this be necessary.
I hope that also users without scripting experience themselves but who have seen how hard it is to get release triggers to work with scripts put some pressure on NI to make this better.

The problems:
Any script that handles release triggers cannot be cascaded with another script (placed before it in the chain) since the second script can't tell apart ordinary notes and release notes sent from the first script. Hence in many situations all scripts but the last one in the chain must be configured not to trigger release samples. Furthermore, a script which deals with release triggers has no way of determining which groups are release triggers and which are not, so this is something the user has to configure. Due to the limited UI space a script can usually only afford to let the user specify one group, so instruments with multiple release trigger groups normally don't work together with scripts or have to be customized to fit the instrument. In short this violates the design principle of loosely coupled components and make scripts much less userfriendly.

Many instruments modulate the volume of the release sample with the time the note was pressed (long note - soft release). By forcing scripts to handle release triggers explicitly one looses this modulation. Or one has to use a custom-made script which, since it's tied to the particular instrument, is not possible to reuse with other instruments.

A script that generates notes also has to deal with the fact that releasing the sustain pedal triggers release callbacks differently for script-generated notes and externally received notes.

I would like a release trigger solution that looked like this:

• Automatically mirror any changes to volume, panning and tuning of a note to the release sample. For example, raising the volume of a note should automatically make the release sample louder.
  
• Add two variables to make it possible to use the allow_group/disallow_group and pass $ALL_RELEASE_GROUPS or $ALL_NONRELEASE_GROUPS as argument.
  
• Make it possible to use allow_group/disallow_group in the note and release callbacks to control if release trigger groups are allowed or not (currently disallow_group($ALL_GROUPS) has no effect on release triggers unless the NO_SYS_SCRIPT_RLS_TRIGGER condition is set, which makes scripting incredibly more complex and scripts less cascadable). The allowed/ignored state should be passed on to the next script in the chain which could then change the state or leave it as is.
  
• Make release behaviour of externally received notes and script generated notes consistent. Both the note that triggered "on note" and the notes that are generated with play_note should call the release callback in the same way, eg. when the sustain pedal is released.

At least the first three changes I believe wouldn't break any existing scripts. The fourth could be worth implementing since it seems like a bug from the start anyway.
The basic idea is: most people don't want to care about release samples, and occasionally one want to decide whether to use them or not and/or which group to use. KSP shouldn't make this more complicated than it need to be.

What do you think?
Anything you would like to change/add to my wish list?

Best,
Nils

 

Hi Nils,

Just thought I'd chime in with a few amens! One of my biggest gripes about having a script take over the triggering of release samples is that it's an 'all or nothing' kind of thing. One reason being that there is no way to runtime-disable K2 from triggering release samples from note-off. The only way to stop K2 from doing it is to use the pre-processor directive

Code:

SET_CONDITION(NO_SYS_SCRIPT_RLS_TRIG)

and once you've loaded such a script, you are stuck with it until you reload a different script. I've also noticed that when this directive is used, you dare not go into K2 and fiddle with anything (like turning on and off the 'Note Mono' button) or some very weird things begin to happen.

I've done a few scripts that have tried to cope with the release sample machinery and I shudder everytime someone posts a complaint that the script isn't handling release samples properly with some situation they have. The reason I shudder is because I know I'm in for a long, tooth-pulling experience with little reward at the end. So, like you, I vote for simplifying this whole thing.

Bob

 

Although I'm pretty happy about the changes made to KSP in the 2.1 update I'm sorry to see that the above issues have not been adressed. It seems that the minor sustain pedal inconsistency may have been fixed, but nothing has been done about the other things.

It also seems like the change_vol() problem causing crackles has not been fixed either.

Regards,
Nils

 

With the change_vol now being fixed in K2.1.1 maybe the time is right for making something about the release triggers. NI, please consider the suggestions above.

 

Just wanted to add my support for this.

Kotori has a good point and his suggestions seem good as well. I realize that you guys at NI just fixed the change_vol() problem for which we are extremely grateful (thank's again), but if I may I'd say this is probably one of the more important features for you to think about implementing in some future update if possible.

Considering how much release triggers are used and the number of instrument types that benefit from them, some way of making them easier to use (especially in combination with other scripts) would be a great thing and do heaps for Kontakt in terms of KSP versatility.

Besides, if even two of the top scripters in the community such as Kotori and Big Bob both feel release samples are difficult to implement, then it's well worth looking into.

N

 

I totally agree Kotori. NI's progrsmmers themselves must be frustrated to no end with the release trigger's design. I think NI is beginning to see the bigger picture with how scripts are catching on like wild fire. They did solve the change_vol() bug.

If NI takes these suggestions to heart, the benefits will be compounded by all the great scripts that would otherwise not be able to be written.

Thanks for listening NI.

Cheers,

T

 

I hope this fix is included in the forthcoming update.