Kontakt 5.5より前のバージョンでも、エフェクトスロットの内容に関する情報を取得するための仕組みは、$ENGINE_PAR_EFFECT_TYPEのようなエンジンパラメーター変数や$EFFECT_TYPE_FILTERのようなビルトイン定数を通じてすでに用意されていました（モジュールの種類とサブタイプを参照）。
Kontakt 5.5以降では、同じビルトイン定数のセットを使って、ロードされているエフェクトを変更することも可能になりました。
on init
set_engine_par($ENGINE_PAR_EFFECT_TYPE, $EFFECT_TYPE_FILTER, 0, 0, -1)
set_engine_par($ENGINE_PAR_EFFECT_SUBTYPE, $FILTER_TYPE_LDR_LP4, 0, 0, -1)
end on
Instrument内の最初のグループの、最初のGroup FXスロットに4ポールのローパスラダーフィルターを挿入します。
エフェクトスロットの内容の変更は非同期の処理です。つまり、インスタンス化した直後に、新しくインスタンス化されたエフェクトへ確実にアクセスすることはできません。これを解決するため、このコマンドは$NI_ASYNC_IDを返し、on async_completeコールバックをトリガーします。さらに、この処理を簡潔に書くためにwait_async()コマンドを使うこともできます（こちらが推奨されます）。
警告：on initコールバックからエフェクトスロットの内容を変更した場合、その処理は同期的に実行されるため、Instrumentの初期ロード時間に影響します。多数のエフェクトスロットに対してこれを行う場合はとくに顕著です。そのような処理はon persistence_changedコールバックへ移すことをおすすめします。
フィルターはサブタイプを持つエフェクトタイプであるという点で、やや特殊です。KSPからサブタイプを明示的に選択せずに新しいフィルターをインスタンス化できるようになったため、あらかじめ定義されたデフォルトのフィルターサブタイプが必要になります。それがSV LP4です。
KSPを通じてエフェクトスロットの内容を変更するとき、割り当て済みのオートメーションとモジュレーションの扱いは、KontaktのGUIで同じ操作を行った場合と同一になることが期待されます。
上で説明したのと同じコマンドを使って、内部モジュレーターのサブタイプを変更することもできます。具体的には、エンベロープのタイプ（AHDSR、Flex、DBD）や、LFOのタイプ（Rectangle、Triangle、Sawtooth、Random、Multi、Multi Digital）を切り替えられます。モジュレーターそのものを挿入したり削除したりはできません。また、そのタイプ（LFO、Envelope、Step Modulator、Envelope Follower、Glide）を変更することもできません。
KSPから設定できないエフェクトタイプが2つあります。Surround PannerとAET Filterです。
|
|---|
条件として使用するシンボルを定義します。 |
|
|---|
条件の定義を削除します。 |
|
|---|
|
|
|---|
|
|
|---|
条件。 |
|
|---|
条件。 |
|
|---|
条件。 |
|
|---|
リリーストリガーのカウンターをリセットします（リリーストリガーのシステムスクリプトが使用します）。 |
|
|---|
このイベントが決して終了しないことをスクリプトエンジンに伝えます（リリーストリガーのシステムスクリプトが使用します）。 |
プリプロセッサーは、解釈の対象からコード要素を除外するために使用します。<condition-symbol>は、英数字からなり先頭が文字であるシンボル名を指します。たとえば、次のように書くことができます：
on note
{ do something general }
$var := 5
{do some conditional code}
USE_CODE_IF_NOT(dont_do_sequencer)
while ($NOTE_HELD = 1)
play_note($EVENT_NOTE, $EVENT_VELOCITY, 0, $DURATION_SIXTEENTH)
wait($DURATION_EIGHTH)
end while
END_USE_CODE
end on
ここでは何が起きているのでしょうか。
シンボルdont_do_sequencerが定義されていない場合にかぎり、USE_とEND_USEの間のコードが処理されます。このシンボルが見つかった場合、コードはパーサーに渡されず、そのコードは最初から書かれていなかったのと同じ扱いになります。したがって、CPUリソースを一切消費しません。
すべてのコマンドは、スクリプトが実行される前に解釈されます。つまり、USE_CODE_を使うと、コードはスクリプトエンジンに渡される前に止められることがあります。これは、SET_CONDITIONとRESET_CONDITIONが実際には本当のコマンドではないということを意味します。これらはif ... elseの制御構文の中では使用できず、また、これらのコマンドの前にwait()文を置いても意味がありません。SET_CONDITIONとRESET_CONDITIONは、それぞれ他の処理よりも前に実行されます。
定義されたシンボルはすべて後続のスクリプトスロットに引き継がれます。つまり、スクリプトスロット3に条件付きのコードが含まれている場合、それをスクリプト1や2でオンにしたりオフにしたりできるということです。
条件付きのコードを使ってシステムスクリプトをバイパスできます。これらのシンボルのいずれかをSET_CONDITION()で定義すると、システムスクリプトの該当する部分がバイパスされます。分かりやすさのため、この定義は必ずon initコールバックの中で行うようにしてください。
on init
{ we want to do our own release triggering }
SET_CONDITION(NO_SYS_SCRIPT_RLS_TRIG)
end on
on release
{ do something custom here }
end on
独自のリリーストリガーのロジックを実装したい場合、これがその第一歩となります。
Program Global Storage（PGS）コマンドを使うと、通常の左から右への処理順序を回避して、あるスクリプトから別のスクリプトへ値を送ったり受け取ったりできます。PGSは共有メモリで、どのスクリプトからも読み出しと書き込みができます。
PGSコマンド |
|---|
|
<key-id>は変数名に似ています。英数字のみを含むことができ、数字で始めることはできません。また、64文字を超えることもできません。固有の存在であることを強調するため、常に大文字で書くようにするとよいでしょう。
以下は例です。次のスクリプトを任意のスロットに挿入してください：
on init
declare ui_button $Just_Do_It
pgs_create_key(FIRST_KEY, 1) { defines a key with 1 element }
pgs_create_key(NEXT_KEY, 128) { defines a key with 128 elements }
end on
on ui_control($Just_Do_It)
{ writes 70 into the first and only memory location of FIRST_KEY }
pgs_set_key_val(FIRST_KEY, 0, 70)
{ writes 50 into the first and 60 into the last memory location of NEXT_KEY }
pgs_set_key_val(NEXT_KEY, 0, 50)
pgs_set_key_val(NEXT_KEY, 127, 60)
end on
次に、以下のスクリプトを他の任意のスロットに挿入します：
on init
declare ui_knob $First (0, 100, 1)
declare ui_table %Next[128] (5, 2, 100)
end on
on pgs_changed
{ checks if FIRST_KEY and NEXT_KEY have been declared }
if (pgs_key_exists(FIRST_KEY) and _pgs_key_exists(NEXT_KEY))
$First := pgs_get_key_val(FIRST_KEY, 0) { in this case 70 }
%Next[0] := pgs_get_key_val(NEXT_KEY, 0) { in this case 50 }
%Next[127] := pgs_get_key_val(NEXT_KEY, 127) { in this case 60 }
end if
end on
上の例で示したとおり、pgs_set_key_val()コマンドが実行されるたびに実行されるコールバックも用意されています。
PGSキーはいくつでも持つことができますが、各キーが持てる要素は最大で256個までです。
PGS文字列の基本的な扱いは通常のPGSキーと同じですが、1つだけ違いがあります。PGS文字列キーは、すでにご存じの標準的なPGSキーのような配列ではなく、通常の文字列変数のように機能します。
PGS文字列コマンド |
|---|
|
Advanced Engineタブは、Instrumentやスクリプトのパフォーマンスをデバッグしたり測定したりするのに役立つツールです。
Engineタブ（KontaktのSide PaneにあるMonitorタブのサブタブ）でもパフォーマンスの統計を分かりやすく表示できますが、Advanced版はCPU使用率などをより高い精度で表示し、Kontaktをプラグインとして使用している場合には複数インスタンスの情報も表示します。
先に述べたとおり、EngineタブはMonitorタブのサブセクションで、KontaktのSide Paneにあります。
DAWやホストでKontaktをプラグインとして複数インスタンス実行している場合、それぞれのインスタンスがこのセクションに1項目として表示されます。Kontaktをスタンドアローンで使用している場合は、現在のインスタンスのみが表示されます。
ここでは5種類のパフォーマンス統計を確認できます：
下部のセクションには、現在ロードされているすべてのKontaktインスタンスのパフォーマンス統計の合計が表示されます。以下のパラメーターがあります：
参照元情報：Advanced Concepts
https://docs.native-instruments.com/online-guides/ksp-manual/en/advanced-concepts