What's new

ONCE AND FOR ALL: Kontakt modulation via KSP


KSP Wizard
I see people are still struggling with this, after all this time. So I thought I could explain this to everyone once and for all, since it's quite an important thing when doing a custom scripted instrument.

First, let's break things down. Kontakt has two types of modulators - internal and external. Internal are: LFO, envelope, glide, step modulator, envelope follower. External are: pitch bend, aftertouch, MIDI CC, constant, random unipolar/bipolar, etc.

Next, internal modulators have two parts: the modulator itself (represented by its module in the Modulation section of Kontakt's instrument edit view), and the modulator target strip (found at the destination - source pitch, filter cutoff, amplifier volume, etc.). External modulators only have the modulator target strip.

Now, how do we KSP this all? This is where KSP offers two commands: find_mod() and find_target(). First one targets either internal modulators or external modulator target strips. Second one targets only (and nothing else but) internal modulator target strips. These commands work by searching for a named reference, the name of a modulator/target strip. Kontakt assigns default names to these, but I find them completely useless, so I heartily recommend everyone to do their own naming.

Here's my suggestion for a clear-cut modulation naming scheme:

* use all caps
* name internal mods either by their purpose (PITCH LFO, FILTER ENV), or number them (LFO 1, LFO 2, ENV 1, ENV 2). I tend to go with the latter.
* name internal mod target strips in such a way that you include the modulator name and an arrow pointing to the target (LFO 1 -> PITCH, ENV 2 -> CUTOFF 1 (more on why I used 1 here later))
* name external mods like internal mod target strips (PB -> PITCH, AT -> VOLUME, RANDOM -> STARTPOINT...)

That should be clear enough for everyone, I think. If you have more than one internal modulator of the same type (say, multi LFO), Kontakt does NOT auto-number them incrementally unfortunately, and this can be a source of a lot of confusion. So make sure you rename them immediately upon instantiating them, and it should all be clearer.

But, how to rename modulators, or see their names in the first place? For this, you have to go to Script Editor, and press the Edit button there to open the text input area of the Script Editor. Now you can see the names of modulators and target strips when you right-click them. You don't have to have the Script Editor open at all times - but you have to have the text input area open. So after opening the text input area, close the Script Editor to give yourself a better overview of the instrument. I also recommend closing the Wave and Mapping Editors, as well as Group Editor, too (use Monitor->Groups tab in Kontakt's left-side browser instead of Group Editor, it's more spacious anyways).

IMPORTANT: In Kontakt 4, you could only rename modulators within one group - the renaming operation didn't pass through other editable groups (for example, when Edit All Groups is enabled), so you had to rename every modulator in every group manually (or do one group, then duplicate it - which is what I tend to do anyways, since batch-renaming things can sometimes lead to unexpected results if your modulators were added at different times and in different order, etc.). In Kontakt 5, when you have more than one group selected for editing, the renaming operation WILL be passed through all those selected groups. There are some situations that are very hard to explain in layman's termas when this doesn't happen, but it's mostly related to the abovementioned unexpected results. When you notice this situation, I recommend duplicating one of the existing groups with fully-named modulators, then pasting samples back into it.

Also, I read somewhere that people notice missing modulators after they've added them, etc. This happens when you select a modulator (it gets a yellow frame around it), then type in the Script Editor, and at some point you press the Delete key on your keyboard. Kontakt wrongly assigns keyboard focus to BOTH the Script Editor AND the instrument edit view - so you get both your character from the script deleted, AND the modulator! So be careful!!!

Let's notice one more thing regarding Kontakt 5 here. When you right-click the modulator or its target strip, you will see some numbers there (group, slot, idx). This is essentially what find_mod() and find_target() will return when used, these are the numbers that you put in set_engine_par() or get_engine_par(). So if you feel like you don't want to be bothering with this all, you can use the numbers, too. But I find that this really affects script readability in a bad way, so I always use the naming scheme. Then everything makes a lot more sense.

Before continuing onward, let me explain my naming scheme above for the case where I used "CUTOFF 1" in the modulator target name. In Kontakt, you can have up to 16 internal modulators per group. Each of those modulators can target up to 16 destinations. So let's say you have several filters loaded in Group FX, and you want one single LFO to modulate the filter cutoff in all of them. For find_mod() and find_target() to work we need to have UNIQUE names for EVERYTHING within a single group! This is why I added a number there. In the above situation, Group FX slot 1 filter cutoff would be called CUTOFF 1, slot 2 would be called CUTOFF 2, and so on. So we would have modulation target strips named like so:


This ensures unique naming and no find_mod() errors, provided you didn't do a typo of a modulator in the script, or something :) Note that we need this naming ONLY when there's a multiple of the SAME modulation links across multiple Group FX slots. So, if we have 4 filters or 4 EQs and we want to modulate the same parameter in all of them with just one modulator, this is the case when we use this incremental naming scheme. If we have an EQ in one slot, a filter in another, a Skreamer in yet another, and we have ONE modulator targetting a DIFFERENT parameter in all of them, we don't need to do this (since you would name the modulator targets differently, for example: LFO 1 -> CUTOFF, LFO 1 -> EQ GAIN2, LFO 1 -> SKR TONE...)
Last edited:


KSP Wizard
Thread starter
  • Thread Starter
  • Thread Starter
  • #2
Let's put all this to good use now. Some examples:


Let's say our LFO is named "LFO 1" and we want to change its frequency. Let's say it's found in group 2, and that our ui_knob/slider is called $LFOFreq. Here's what we do:

set_engine_par($ENGINE_PAR_INTMOD_FREQUENCY,$LFOFreq,1,find_mod(1,"LFO 1"),-1)

That's all there's to it! Same code is used for other LFO parameters, and all envelope parameters in much the same way. $ENGINE_PAR_INTMOD_FREQUENCY applies to LFOs and step modulators.


Let's say we have an envelope modulating pitch in group 4. Our envelope is called "ENV 2" and our mod target strip is called, naturally, "ENV 2 -> PITCH" (because you're following my naming guidelines, are you? :)). Our ui_knob/slider is called $PitchEnv. We can deal with this in several ways, one of which is needlessly more complicated than others. Let's see...


set_engine_par($ENGINE_PAR_MOD_TARGET_INTENSITY,$PitchEnv,3,find_mod(3,"ENV 2"),find_target(3,find_mod(3,"ENV 2"),"ENV 2 -> PITCH"))

This will target ONLY the modulation amount slider, which goes from 0 to 100%. Which means unipolar (positive) modulation happens. Notice how the code is structured: first we're telling which engine parameter we want to change, then we tell by what amount, then we point to the group we want to modify, then we tell which modulator we're pointing, and finally which modulator target strip we want to change (we repeat find_mod() here because it's important for KSP to know the modulator to which the target strip is attached to). The range of our ui_knob/slider is 0 to 1000000.


This is the needlessly more complicated way: using the unipolar mod amount code and then targetting the Invert button with a separate engine parameter call. The range of our ui_knob/slider in this case is -1000000 to 1000000.

set_engine_par($ENGINE_PAR_MOD_TARGET_INTENSITY,abs($PitchEnv),3,find_mod(34,"ENV 2"),find_target(3,find_mod(3,"ENV 2"),"ENV 2 -> PITCH"))
if ($PitchEnv < 0)
    set_engine_par($MOD_TARGET_INVERT_SOURCE,1,3,find_mod(3,"ENV 2"),find_target(3,find_mod(3,"ENV 2"),"ENV 2 -> PITCH"))
    set_engine_par($MOD_TARGET_INVERT_SOURCE,0,3,find_mod(3,"ENV 2"),find_target(3,find_mod(3,"ENV 2"),"ENV 2 -> PITCH"))
end if

See? This is needlessly complicated. Thankfully there's another engine parameter that handles this all for itself. For whatever reason it's not documented, but I think everyone should know about it, since it offers one cool feature many people don't know about. This engine parameter is called $ENGINE_PAR_INTMOD_INTENSITY. Its range is 0-1000000, and this covers the ENTIRE bipolar range of the modulation amount slider, which means 0% is at 500000, 100% is at 1000000 and -100% is at 0. So, our code for bipolar modulation amount slider becomes this:

set_engine_par($ENGINE_PAR_INTMOD_INTENSITY,$PitchEnv,3,find_mod(3,"ENV 2"),find_target(3,find_mod(3,"ENV 2"),"ENV 2 -> PITCH"))

Our $PitchEnv range for this example is then, of course, 0 to 1000000.

But... that's not all! It seems that NI didn't build in any range checking for this engine parameter. Which means, we can go beyond the range of -100%~100%! This is especially important for pitch modulation, because sometimes we want to have a stronger modulation that goes beyond 12 semitones range that Kontakt allows at 100% modulation amount. So, just continue with the values, expanding the range. It follows a sort of exponential curve, so engine parameter of 2000000 is not 24 semitones, it's actually 324 semitones! So you don't want to go that high. Here's a table with some useful values:

-12 to 12 semitones -> 0 to 1000000
-24 to 24 semitones -> -130000 to 1130000
-36 to 36 semitones -> -221000 to 1221000
-48 to 48 semitones -> -293500 to 1293500

I doubt you'll need more than this. Also note that extreme pitch modulation can sometimes crash Kontakt, since this is not only an undocumented feature, but probably actually an unintentional bug on NI side. So it MIGHT be fixed at some point... but somehow I think this "exploit" is here for a reason. So there you go - this is how to extend modulation range for pitch modulations! This might or might not work for other engine parameters. Explore!


This is as simple as it gets. We can use either unipolar or bipolar modulation amount examples from above, except we do not need to use find_target() at all! Just write -1 instead. Let's say we have aftertouch mapped to modulate LFO 1 frequency in group 10.

set_engine_par($ENGINE_PAR_INTMOD_INTENSITY,$ATVolume,9,find_mod(9,"AT -> LFO 1 FREQ"),-1)

That's all there's to it!

I think there's one more thing I'd like to say here, and one thing all KSPers should know. When find_mod() doesn't find a modulator with designated name, it actually returns a value of 0 instead of -1! This is actually a bug on NI side, that I don't know why isn't fixed yet. How does this manifest? Well, it manifests in such a way that it will CHANGE the value of the modulator whose slot ID is 0 REGARDLESS! This is usually amplifier envelope which is assigned by default by Kontakt. Usually it sets the modulation amount of it to 0%, which makes the instrument behave in a very weird way (envelopes don't work and notes are cut short). So, if your instrument starts behaving weirdly after a wrongly targetted find_mod(), you know what to look for!


I hope this has been helpful. I've probably missed some things I wanted to mention, but that's why this is a forum and this is a thread where you can leave your questions and I'll answer from time to time.


Mike Greene

Senior Member
This is great, Mario! I agree with Greg that it should be a sticky. I can do that. (Or maybe Mario can, too?) However, maybe it's just me, but I tend to ignore stickies because they're not usually "active" topics. My eye just automatically skips them. So I'm thinking we should wait a few days, since it will be at the top anyway, then stickyize it after it starts to drop.


Senior Member
Another quirk I found out is you can't use $ALL_GROUPS as a group index in set_engine_par(). You need to parse all the groups one by one.


KSP Wizard
Thread starter
  • Thread Starter
  • Thread Starter
  • #11
$ALL_GROUPS is really just meant to be used with (dis)allow_group (and event-based variant).
Top Bottom