# Useful constants library for KScript editor



## EvilDragon (Jun 9, 2010)

We know that you can include other .txt files as a part of your script. Here's a very useful library of constants that you'll like to use a lot, no doubt! Admit that you hate writing that $VALUE_EDIT_MODE_NOTE_NAMES every time!

Thanks goes to gregjazz for this excellent idea.

Paste this into .txt file of your choice and off you go!


```
{ This include library contains constants which can be used with KSP functions which otherwise use numerical values.     }
{ For example, instead of remembering which value is used in get/set_engine_par for insert/send FX, just write INSERT_FX }
{ or SEND_FX, etc. }

on init
    { sort() function order }
    declare const ASC := 0
    declare const DESC := 1
    
    { purge_group() function mode }
    declare const UNLOAD := 0
    declare const LOAD := 1
    
    { set_event_par_arr() function mode }
    declare const ALLOW := 1
    declare const DISALLOW := 0
    
    { hide_part() constants - use .or. to combine the values, or just sum BG+TITLE+LIGHT, etc. }
    { ALL is used by itself, do NOT add or .or. anything else if you have ALL as a parameter!  }
    { Control parameter $CONTROL_PAR_HIDE also uses these values in the same way!              }
    declare const NONE := 0 { NONE is also used for other functions! }
    declare const BG := 1
    declare const TITLE := 2
    declare const VALUE := 4
    declare const LIGHT := 8
    declare const ALL := 16
    
    { set_key_color() function values }
  { declare const NONE := 0 -> already declared above! }
    declare const WHITE := 1
    declare const YELLOW := 2
    declare const GREEN := 3
    declare const RED := 4
    declare const BLUE := 5
    declare const CYAN := 6
    
    { set_knob_unit() function values }
  { declare const NONE := 0 -> already declared above! }
    declare const DB := 1
    declare const HZ := 2
    declare const PERCENT := 3
    declare const MS := 4
    declare const OCT := 5
    declare const ST := 6

    { ui_value_edit parameter for showing MIDI note names }
    declare const NOTE := 0

    { change_pan(), change_tune() and change_vol() relative-bit values }
    declare const ABS := 0
    declare const REL := 1

    { fade_out() function stop_voice values }
    declare const STOP := 1
    declare const RUN := 0

    { substitutions for $VCC_PITCH_BEND and $VCC_MONO_AT }
    declare const PBEND := 128
    declare const AT := 129

    { play_note() function duration values }
    declare const KILL := -1
    declare const WHOLE := 0
    
    { $CONTROL_PAR_TEXT_ALIGNMENT values }
    declare const LEFT := 0
    declare const CENTER := 1
    declare const RIGHT := 2

    { $CONTROL_PAR_SHOW_ARROWS values}
    declare const YES := 1
    declare const NO := 0
    
    { get/set_engine_par() function values, also used for load_ir_sample() }
    declare const INST := -1
    declare const INSERT_FX := 1
    declare const SEND_FX := 0
    
    { get_folder() function values }
    declare const INSTALL := 0  { folder in which Kontakt 4 is installed }
    declare const LIBRARY := 1  { Kontakt factory library folder }
    declare const PATCH := 2    { currently loaded patch folder }
    declare const FACTORY := 3  { Kontakt's factory content folder, for loading IRs etc. }
end on
```


Well, perhaps it's not always SHORTER to write these constants, but your script will definitely be more understandable if you use these!


----------



## Dynamitec (Jun 9, 2010)

Be careful with some of the constants. The value of some KSP constants have been known to be change from time to time. For example the FX_TYPE constant did change from K2 to K3, because of added insert FXs.

So rather than:
declare const DB := 1 

use:
declare const DB := $KNOB_UNIT_DB

It's much safer, you'll never know 

PS: Also stay away from get_folder, it's not necessary in K4 anymore and caused problems in K3 especially when you were developing for Kontakt and Kontakt Player.


----------



## EvilDragon (Jun 9, 2010)

Unfortunately that doesn't work. I tried to link it directly exactly like that, but it's not working.

It works when I type this directly into Kontakt's script editor:


```
on init
    declare const $DB := $KNOB_UNIT_DB
    declare ui_knob $k(0,127,1)
    set_knob_unit($k,$DB)
end on
```

But it doesn't compile at all in Nils' editor. The purpose of this include library is to be used in Nils' editor. And if it doesn't compile there...


----------



## Dynamitec (Jun 9, 2010)

on init
declare const $DB := $KNOB_UNIT_DB 
message($DB)
end on

That works fine in Kontakt. What's the problem?


----------



## Dynamitec (Jun 9, 2010)

Oh ok, I see...it's a problem in Nils editor.
Simply remove 'const' and it works fine.


----------



## EvilDragon (Jun 9, 2010)

Ack! Thanks!

Although that kinda defeats the purpose of having constants declared, and then used instead of variables. Constants are not variables, they're just numbers, and using them the code gets a bit more compact, no?


----------



## Dynamitec (Jun 9, 2010)

Not really, doesn't make a difference in term of code size (only if you use the Extend syntax check + Code optimization). 
Of course in the early days of computing this would have made a difference, but it doesn't matter in a KSP script at all.


----------



## gregjazz (Jun 9, 2010)

Well it DOES make a difference in terms of using SELECT/CASE.


----------



## chrisboy (Jun 9, 2010)

Cool Idea! Especially the KILL / WHOLE and the INSERT / SEND made me look into the manual each time...


```
{ change_pan(), change_tune() and change_vol() relative-bit values }
    declare const ABS := 0
    declare const REL := 0
```

There is a small mistake, it should be


```
{ change_pan(), change_tune() and change_vol() relative-bit values }
    declare const ABS := 0
    declare const REL := 1
```


----------



## Dynamitec (Jun 9, 2010)

gregjazz @ Wed Jun 09 said:


> Well it DOES make a difference in terms of using SELECT/CASE.



Well thats true of course


----------



## EvilDragon (Jun 9, 2010)

chrisboy @ 9.6.2010 said:


> There is a small mistake, it should be
> 
> 
> ```
> ...



Ah! Thanks for correction! I'd never find that one out


----------



## Dynamitec (Jun 9, 2010)

Hi Nils,

are you reading this thread?

Is there a reason, why it's not possible to compile this code with your editor, but it works fine in Kontakt?

on init
declare const $DB := $KNOB_UNIT_DB
message($DB)
end on 

Cheers,
Benjamin


----------



## Dynamitec (Jun 10, 2010)

Yeah They are all constants, so they have a value :D 

But let me repeat, *don't* use absolute values to declare the abbrivated constants. Never ever! They might change in future updates of Kontakt, which renders a script useless in that case. And it will be very hard to find the bug in that case.


----------



## EvilDragon (Jun 10, 2010)

Dynamitec @ 10.6.2010 said:


> Yeah, sure
> 
> But let me repeat, *don't* use absolute values to declare the constants. Never ever! They might change in future updates of Kontakt, which renders a script useless in that case. And it will be very hard to find the bug in that case.



That's why I made this script. I can run it on every new version of Kontakt to check and see the new absolute values, then change them in constants.txt

Voila, all scripts working again!


----------



## Dynamitec (Jun 10, 2010)

If you are planing to help out guys developing Kontakt Player instruments this won't be possible...since it's a complicated process to get the scripts updated. And if you develop instrument not just for fun, but for customers they have to work in different versions without updates or thing like that.


----------



## EvilDragon (Jun 10, 2010)

I'll have to get that kind of job first. 

For now, this eases up my normal coding a LOT 


Even better, it would've been cool if we could assign a string to a constant instead of a number, then Nils' editor could just replace our short writing with the full parameter name.


----------



## Dynamitec (Jun 10, 2010)

I give up...  Just wait for Nils to fix the constant declartion thing and all is good


----------



## EvilDragon (Jun 10, 2010)

Hehe 

What I mean is something like this:

declare const VOLUME := "$ENGINE_PAR_VOLUME" -> a string, not a number!

Then you could just write:

set_engine_par(VOLUME,value,group,-1,-1)

*Nils, what do you say?*


----------



## Dynamitec (Jun 10, 2010)

> Even better, it would've been cool if we could assign a string to a constant instead of a number, then Nils' editor could just replace our short writing with the full parameter name.



Yeah, would be cool if there would be an way to add abbriavations directly to the KScript editor (similar to the KSPUtil.txt)! For example: pgs_get_key_val or set_engine_par. First thing I did is write functions which replace those with faster to write function names.

But unfortunately it doesn't work for functions with a return value that way.


----------



## EvilDragon (Jun 10, 2010)

Yeah, how about:

set_ep()
set_cp()
get_ep()
get_cp()

Those are really often :D Perhaps Nils should add a possibility like this. I have a lot of ideas for his editor, but I dunno if he'd hear out, they could be a lot of work


----------



## Dynamitec (Jun 10, 2010)

> declare const VOLUME := "$ENGINE_PAR_VOLUME" -> a string, not a number!



I think that's a little awkward. The only thing you'll save that way is some lines in the on init callback.

I think if:
declare const VOLUME := $ENGINE_PAR_VOLUME 

would work in the editor, it should be enough (for now...since Nils is a busy man


----------



## Dynamitec (Jun 10, 2010)

> Those are really often Very Happy Perhaps Nils should add a possibility like this. I have a lot of ideas for his editor, but I dunno if he'd hear out, they could be a lot of work



Just tell him...you'll never know  Nils often asked the community here, how features should be implemented for example.


----------



## EvilDragon (Jun 10, 2010)

But wouldn't that assign the internal _value_ of $ENGINE_PAR_VOLUME instead of making it a string which would replace? How would Nils' editor know that it needs to make a string constant instead of number? That's why I added "", that's a clear unanimous way that says that something is a string, so it's easy to parse.

Since I'm going to make this into my constants.txt and import it into every script, then those would be declared as just string constants, meaning if I type:

set_engine_par(VOLUME,value,group,-1,-1)

that would compile as:

set_engine_par($ENGINE_PAR_VOLUME,value,group,-1,-1)


----------



## Dynamitec (Jun 10, 2010)

Yeah, I know what you mean. 

But:

declare const VOLUME := ENGINE_PAR_VOLUME

set_engine_par(VOLUME,value,group,-1,-1)

does exactly the same. But your feature request has one big benefit: it saves on init code lines (since they are limited, I think around 5000 lines is the allowed size of an on init callback now).

maybe Nils could implement some thing like this:

{#pragma replace VOLUME=ENGINE_PAR_VOLUME, TUNE=ENGINE_PAR_TUNE, PAN=ENGINE_PAR_PAN, set_ep=set_engine_par, get_ep=get_engine_parameter}

That way it would be possible to use shorter names, but the scripts would still run on every KScript editor, which would better than using something like I suggested above (an abbriavation.txt file similar to the KSPUtil.txt).

The problem is that he can't simply use a search and replace, since that could lead to side effects. So I think it might not be too easy to implement.


----------



## EvilDragon (Jun 10, 2010)

Dynamitec @ 10.6.2010 said:


> maybe Nils could implement some thing like this:
> 
> {#pragma replace VOLUME=ENGINE_PAR_VOLUME, TUNE=ENGINE_PAR_TUNE, PAN=ENGINE_PAR_PAN, set_ep=set_engine_par, get_ep=get_engine_parameter}
> 
> That way it would be possible to use shorter names, but the scripts would still run on every KScript editor, which would better than using something like I suggested above (an abbriavation.txt file similar to the KSPUtil.txt).



Excellent idea! I think it could be good to have this in external include file (abbreviation.txt with pragma definition is good, user can edit it when new functions are added). I like this. A LOT.


----------



## kotori (Jun 10, 2010)

Hi guys

When I can find some time I'll see if it would be possible to make it so that user-defined constants could be replaced by not only an integer but a built-in constant.

Personally I wonder if the best thing however, would not be to make it possible to write functions with return values instead. If I do this it may make sense to impose some limitations:

* Functions whose body consist of a single line could be used in any context.
* Functions with a body consisting of multiple lines could only be invoked like: "result := myfunction(par1, par2)" but not as in "message(myfunction(5))" or "result := myfunction(5) + 2". In other words, it would need to be the single thing on the right hand side of an assignment.

If I do this, then instead of declaring short name aliases for the constants one could declare simpler function names and write code like this:
volume = E.volume.get(-1, -1, -1)
E.volume.set(volume, -1, -1, -1)
_(where E stands for engine)_

I'm quite busy right now, but maybe some time in July I will get the time to have a look at this.

Cheers,
Nils


----------



## EvilDragon (Jun 10, 2010)

I kinda like the pragma and abbreviations.txt idea better... but I'm sure you'll make it possible in a way that's not too complex or limiting or something.

If you do it the way you described (with functions), would the user have to make all engine/control parameters into functions, or would you provide the basic abbreviations file?


----------



## kotori (Jun 10, 2010)

Dynamitec @ Thu Jun 10 said:


> But your feature request has one big benefit: it saves on init code lines (since they are limited, I think around 5000 lines is the allowed size of an on init callback now).


I think this limit is a Kontakt KSP parser stack size limitation that applies to all callbacks. However, if one uses the old if (1=1) trick to force the parser to do a reduction earlier than it would otherwise had done then one should be ok. It seems that NI is using right recursion in their parser rule for statement lists, which comes at the cost of increased stack usage.

Cheers,
Nils


----------



## EvilDragon (Jun 24, 2010)

Here's extension of above script. Let me know if I missed a variable or control/engine parameter!


----------

