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
