# Release samples and note silence



## daringone (Jun 26, 2012)

I have some release samples which I have scripted in the On Release call back.

When you hit a note and release it the release sample plays, which is good. But, if you hold the note till it is silent and then release the key you still hear the release trigger. Is there a way I can check if the note is silent or not before playing the release sample?

Thanks!


----------



## Big Bob (Jun 26, 2012)

You might try event_status(id). I haven't tried this though so I'm not sure exactly when it changes state.

Rejoice,

Bob

EDIT: Sorry but this function only changes state after the release callback exits so it will not be useful for this situation. However, see my next post in this thread for a technique that does work.


----------



## polypx (Jun 26, 2012)

Look up the Rls. Trig. Counter... or "release trigger counter" in the Kontakt manual. It's a modulator desiged for exactly that purpose.


----------



## Blackster (Jun 27, 2012)

OR: if you have sustained samples which decrease in volume over time, e.g. like guitar samples or piano samples, then just write a function which decrease the volume of the release samples group(s) in a parallel way. 

The release will be played though but if the volume is down to zero, you won't hear it


----------



## daringone (Jun 27, 2012)

Hi, thanks for the info.

Bob, I tried the event status thing but it didn't have the desired results :(

Polypx, The only thing the manual says about the rt counter is - resets the release trigger counter used by the release trigger system script - I'm not sure how this will help me, nor exactly how it works, could you elaborate?

Blackster, I'm not manually decreasing the volume of the samples I just let them play for their full duration, so I don't think I could apply your technique in my case.

Thanks


----------



## germancomponist (Jun 27, 2012)

The parameter is called " t(ms) " and is on the right near that "Release Trigger" button.

Experiment with different settings.... .


----------



## daringone (Jun 27, 2012)

I'm coding my own release triggers I'm just using normal groups, can I manually code groups if they are set to release trigger?


----------



## daringone (Jun 27, 2012)

I just tried turning on Release Trigger for the groups I'm using for release samples but this causes all the release groups to come on everytime a note is released regardless of the settings in my scripts On Release.


----------



## Big Bob (Jun 27, 2012)

Hi Dave,

Maybe something like this will accomplish the job?

*on init*
``message('')
*end* on

*on release*
``*if* get_event_par(EVENT_ID,EVENT_PAR_PLAY_POS) = 0
````message('note ended')
``*else*
````message('note still sounding')
``*end* *if*
*end* on



At first I thought I might have to watch it in a short-time loop to see when it stops increasing but, it seems as though the position value conveniently goes to zero when the sample runs out. 

Rejoice,

Bob


----------



## daringone (Jun 27, 2012)

Ah that's great Bob, I shall give it a go. I tried the same thing but used -1 rather than zero, and it didn't work. I never thought to try zero


----------



## daringone (Jun 27, 2012)

Bob I just tried it and it works!

Thanks again


----------



## polypx (Jun 28, 2012)

The Release Trigger Counter is a modulator that keeps track of how long a note has been held. If you route this to the volume of your release triggers, you reduce the volume the longer the note has been held.


----------



## Big Bob (Jun 28, 2012)

Hi Dan,

There is another rather obscure issue connected with this. 

If you write a script that disables system-scripted release triggering with:

```
SET_CONDITION(NO_SYS_SCRIPT_RLS_TRIG)
```
 you should also include the following command in your NCB.

```
reset_rls_trig_counter(EVENT_NOTE)
```

Otherwise, anyone using the rls-trig counter as a modulator will have problems because the counter is no longer reset automatically by the system script.

Rejoice,

Bob


----------



## polypx (Jun 28, 2012)

Hi Bob,

Yes, if you disable the RLS.TRIG and do it yourself in a script you need to put the reset_rls_trig_counter in each note CB. But the great thing is it DOES still work, so you can use it even when managing your own release group system.

I've found the Rls.Trig.Counter very useful, but I wonder if a lot of people don't understand what it does.

cheers!
Dan


----------



## Big Bob (Jun 29, 2012)

Hi Dan,



> I've found the Rls.Trig.Counter very useful, but I wonder if a lot of people don't understand what it does.



I think you are quite right about this. I remember way back in the K2 days when a number of people were claiming it didn't work (or they couldn't seem to make it work). So I posted an example of how to use it properly but I doubt if that old post is still retrievable after all the forum glitches since then :lol: 



> But the great thing is it DOES still work, so you can use it even when managing your own release group system.



This is another point of confusion that I'm glad you pointed out. Most users probably think once the system-script release triggering has been disabled that the state of the Release Trigger button no longer matters. While it no longer causes release samples to be triggered, it does enable the release-trigger counter so it can still be used as a volume modulator.

I am curious about one thing that you said though,



> you need to put the reset_rls_trig_counter in each note CB.



the word 'each' is a little puzzling. A script only has one NCB so the only meaning I can associate with your statement is possibly you are thinking of multiple scripts. If so, are you saying that the reset must be performed in each cascaded script?

Apparently Kontakt maintains a counter for each of the possible 128 notes only since the reset command parameter is the note *number* (not the note* id*). So I would think it would be sufficient if only one script (of the possible 5) has the reset command at the head of its NCB. What's your take on this?

Rejoice,

Bob


----------



## polypx (Jun 29, 2012)

Sorry Bob ... "each" was just lazy typing. I haven't tried this in cascading scripts.

But if I'm managing my own release samples (for whatever reason, usually group management) I include this in my INIT callback:

SET_CONDITION(NO_SYS_SCRIPT_RLS_TRIG)

Then this within my NOTE callback:

reset_rls_trig_counter($EVENT_NOTE)

And I use the release groups in Release Trigger mode, so that I have access to the Rls.Trig.Counter function, which I usually route to volume. Typically for something like a harpsichord or keyboard that has some kind of release noise, I'd set the Rls.Trig.Counter to about 4 or 5 seconds... so that if the note is that long, the release noise is gone by that time.

cheers,
Dan


----------



## Big Bob (Jun 29, 2012)

Hi Dan,



> Sorry Bob ... "each" was just lazy typing. I haven't tried this in cascading scripts.



It may have been lazy typing but it did cause me to think about this a little more :lol: 

I think that a reset should at least be included in the NCB of each 'independent' script or suite of scripts. Let's say that the script in slot 1 has the reset in its NCB but what if that script also modifies incoming notes and/or creates totally new ones. If the next script doesn't include the reset in its NCB, the created notes from script one will not have their rls counters reset. Come to think of it, in this scenario if there are no other scripts down the line to reset the counter that could be a problem. So, I guess if a script generates new notes it should also reset the counter for each such note generated?

Since it probably does no harm if the same note's counter is reset multiple times (but closely spaced), it might be safest if every NCB includes the reset. In addition, for scripts that generate new notes, some additional resets may be required at the point of generation.

One potential problem that I see here is if a script doesn't disable system handling, then it probably shouldn't reset the counter? But, what if such a script is cascaded with one that *does* disable system release handling? I guess if the script without resets embedded is positioned ahead of the script that does, it should be OK but not vice versa?

Come to think about it, maybe it's also harmless if a script resets the rls counter even if the system is still handling release triggering. If so, then maybe every script should include this reset both in its NCB and at the point of new note generation. Have you ever run any tests to see if always resetting the counter when a new note starts affects the behaviour of Kontakt when it is handling release triggering?

I guess when I get some time for such things, I'll run some tests :roll: 

Rejoice,

Bob

EDIT: I ran a few quick tests and the results seem to indicate that it is harmless for a script to issue reset counter commands in the NCB and at the point of new note generation, even if that script doesn't disable system release handling. I couldn't detect any difference in behavior with and without the reset commands. Of course when the system script *is* disabled, then it is essential to use the reset commands (that is if the instrument needs to use the rls counter to control something).


----------



## mk282 (Jul 1, 2012)

The only detriment to the factory release trigger counter is that, for example, if you have an instrument like a piano, the notes decay longer or shorter depending on their pitch (higher notes decay sooner), which would require different max release trigger time for every note, so that the release triggered samples end up played at the correct amplitude.

For that kind of thing, fully scripted solutions are still better.


----------



## daringone (Jul 2, 2012)

Hi again,

Sorry I haven't checked in in a while, been very busy. I haven't actually put in the code to disable Kontakt's release trigger system, I'm just not making use of that system. Will this be a problem? Should I put in the code to disable it?


----------



## Big Bob (Jul 2, 2012)

Hi Dave,

I would say that it depends on the specifics. If you have both the script and the instrument under your control, then its optional. If you are writing a general-use script, will your script not do the right thing if the user's instrument is setup to use K4's release triggering? In other words, does the possiblilty exist that system triggering will interfere with your triggering of release samples?

If so, and you want to prevent that from happening, then your script should disable system handling with:


```
SET_CONDITION(NO_SYS_SCRIPT_RLS_TRIG)
```

And, if you do include this directive, then you should also issue include:


```
reset_rls_trig_counter(note_number)
```

at the head of your NCB and at the point of origin of any 'generated' notes produced by your script. Including this will only matter to users that have instruments that are configured to use the counter as a modulator and wish to continue to do so even if your script is handling the actual triggering of release samples.

However, if your script also provides the equivalent function, of reducing the volume of the release group depending on the length of time the sustained note is held preceding the release, then you probably need to instruct the user to reconfigure his instrument so that the counter is no longer being used for this purpose. In such a case, the reset command may be more or less optional but it probably won't hurt to 
include it.

Rejoice,

Bob


----------



## daringone (Jul 3, 2012)

ok, thanks Bob!


----------



## daringone (Jul 7, 2012)

Hi guys, just been looking at my script again after a short break. 

polypx - I have access to the Rls.Trig.Counter function, which I usually route to volume

How do you route it to the volume? 

Thanks


----------



## Big Bob (Jul 7, 2012)

You probably directed this at Dan but as long as I'm here:

1. select the group
2. under the amplifier, click add modulator
3. under external sources, select rls. trig. counter.

Rejoice,

Bob


----------



## daringone (Jul 7, 2012)

Ah, as simple as that. Thanks once more Bob!


----------

