# KScript Editor V1.3



## kotori (Mar 14, 2009)

Hello my friends,

I have released a new version of KScript Editor - for editing/compiling Kontakt scripts. *Download it here* 
_Edit: *OSX version is now available too.*_

Actually I finished it nearly a month ago and Benjamin has been test-running it, but I haven't found the time to update the web page and explain the new features until now. You may need to uninstall any previously installed version before installing this one. 

_News:_

* Better error reporting - worked around a bug in the parser which in some cases can lead to the location of an error not being properly reported.

* Support for macros, an example:

``*macro* declare_knob(#var#, min, max, text)
````*declare* ui_knob #var#(min, max, 1)
````set_text(#var#, text)
``*end macro*

``declare_knob(time, 'Time')
``declare_knob(frequency, 'Freq')

Macros are somewhat similar to functions, but they have no concept of local variables so it's possible to use parameters in declare statements (like in the example above), support partial replacements of names (knob#no# may expand into knob1 if the _no_ parameter is set to 1). Furthermore, macros may contain top-level constructs like ui callbacks and if they do they can be invoked at the top level, i.e. outside of function and callback bodies.

@Big Bob and others: I haven't forgotten about one-line macros that can expand anywhere inside expressions and be used like simple functions with return values, but they aren't included in this version (mostly since Benjamin seemed to have greater use for the multi-line macros). Hopefully I'll be able to provide that too in the future.

Cheers,
Nils


----------



## Thonex (Mar 14, 2009)

Nils,

This is simply fantastic news. o-[][]-o o-[][]-o o-[][]-o o=< o=< o=< 

I can't see what any serious KSP scripter would use instead of your KSP Editor!!!

Thanks again for your generous contributions to this scripting community!!! =o 


Cheers,

Andrew K


----------



## germancomponist (Mar 14, 2009)

Hi Nils,

great news!






I tried to download but the link doesn`t work... .

Best,

Gunther


----------



## kotori (Mar 14, 2009)

Thanks for the encouragement guys! :D 



germancomponist @ Sat Mar 14 said:


> I tried to download but the link doesn`t work...


Has been fixed now. Thanks!


----------



## Big Bob (Mar 14, 2009)

Whoopie o-[][]-o 

I can't wait to download and start playing with it. Thanks a million NIls for a wonderful tool that just gets better and better. Like Benjamin says, I just don't know what we'd do without the KScript Editor (Cry a lot I guess :cry: ).

God Bless,

Bob

EDIT: After trying a few things, I'm kind of hoping you can give us a set of rules of what can and can't be done. Or, at least some more examples of what can be done.
For example, I was hoping it would work for something like this:
*on init*
``BigArray(First)
``BigArray(Last)
*end on*

macro BigArray(#var#)
``*family* #var#`````````
````*declare* FM0[512]
````*declare* FM1[512]
````*declare* FM2[512]
````*declare* FM3[512]
``*end* *family*``
*end* macro

But, this doesn't compile anything so I guess the #var# paramerter can only be used in K2/K3 declaratives and not KScript declaratives such as *family*? I got a feeling this is going to be a very powerful new addition once I understand what it can all do. :lol:


----------



## Dynamitec (Mar 14, 2009)

Thanks again for your outstanding work Nils!
Did you receive my Email? I sent you one a while ago, but got no answer yet!

Cheers and thanks again!
Benjamin


----------



## kotori (Mar 15, 2009)

Günther brought up in a mail that it would be nice to have a way to exclude parts of the code òÜ   ˜|DÜ   ˜|EÜ   ˜|FÜ   ˜|GÜ   ˜|HÜ   ˜|IÜ   ˜|JÜ   ˜|KÜ   ˜|LÜ   ˜|MÜ   ˜|NÜ   ˜|OÜ   ˜|PÜ   ˜|QÜ   ˜|RÜ   ˜|SÜ   ˜|TÜ   ˜|UÜ   ˜|VÜ   ˜|WÜ   ˜|XÜ   ˜|YÜ   ˜|ZÜ   ˜|[Ü   ˜|\Ü   ˜|]Ü   ˜|^Ü   ˜|_Ü   ˜|`Ü   ˜|aÜ   ˜|bÜ   ˜|cÜ   ˜|dÜ   ˜|eÜ   ˜|fÜ   ˜|gÜ   ˜|hÜ   ˜|iÜ   ˜|jÜ   ˜|kÜ   ˜|lÜ   ˜|mÜ   ˜|nÜ   ˜|oÜ   ˜|pÜ   ˜|qÜ   ˜|rÜ   ˜|sÜ   ˜|tÜ   ˜|uÜ   ˜|vÜ   ˜|wÜ   ˜|xÜ   ˜|yÜ   ˜|zÜ   ˜|{Ü   ˜||Ü   ˜|}Ü   ˜|~Ü   ˜|Ü   ˜|€Ü   ˜|Ü   ˜|‚Ü   ˜|ƒÜ   ˜|„Ü   ˜|…Ü   ˜|†Ü   ˜|‡Ü   ˜|ˆÜ   ˜|‰Ü   ˜|ŠÜ   ˜|‹Ü   ˜|ŒÜ   ˜|Ü   ˜|ŽÜ   ˜|Ü   ˜|Ü   ˜|‘Ü   ˜|’Ü   ˜|“Ü   ˜|”Ü   ˜|•Ü   ˜|–Ü   ˜|—Ü   ˜|˜Ü   ˜|™Ü   ˜|šÜ   ˜|›Ü   ˜|œÜ   ˜|Ü   ˜|žÜ   ˜|ŸÜ   ˜| Ü   ˜|¡Ü   ˜|¢Ü   ˜|£Ü   ˜|¤Ü   ˜|¥Ü   ˜|¦Ü   ˜|§Ü   ˜|¨Ü   ˜|©Ü   ˜|ªÜ   ˜|«Ü   ˜|¬Ü   ˜|­Ü   ˜|®Ü   ˜|¯Ü   ˜|°Ü   ˜|±Ü   ˜|²Ü   ˜|³              òÜ   ˜|µÜ   ˜|¶Ü   ˜|·Ü   ˜|¸Ü   ˜|¹Ü   ˜|ºÜ   ˜|»Ü   ˜|¼Ü   ˜|½Ü   ˜|¾Ü   ˜|¿Ü   ˜|ÀÜ   ˜|ÁÜ   ˜|ÂÜ   ˜|ÃÜ   ˜|ÄÜ   ˜|ÅÜ   ˜|ÆÜ   ˜|ÇÜ   ˜|ÈÜ   ˜|ÉÜ   ˜|ÊÜ   ˜|ËÜ   ˜|ÌÜ   ˜|ÍÜ   ˜|ÎÜ   ˜|ÏÜ   ˜|ÐÜ


----------



## Big Bob (Mar 15, 2009)

Hi Nils,



> I am not sure I see the problem. Can you elaborate?



Sorry, the problem was that I had the 'Optimize Compiled Code' turned on (which I always do). I guess when this option is on, only 'referenced' declaritives are actually compiled. And, for my little test, I didn't write any code referencing the arrays :oops: 

I always keep the 'Optimize Compiled Code' on because the Math Library (and a lot of other stuff I use), utilize the pseudo conditional compilation features of this option. The reason I mention this is that I noticed your new post this morning about conditional compilation. I'll study that post ASAP (but my Sundays are usually pretty busy).

BTW: I notice that the 'Optimize Compiled Code' is still labeled as *experimental*, don't you think its pretty solid by now? :lol: At least I hope so because I write so many things that depend on it heavily, such as the Math Library (which would generate much more bloated code without this option enabled).

You have a lovely Sunday my friend,

God Bless,

Bob


----------



## Big Bob (Mar 15, 2009)

kotori @ Sun Mar 15 said:


> Günther brought up in a mail that it would be nice to have a way to exclude parts of the code like you can do with USE_CODE_IF. I had not thought about this, but the changes made to the code in order to facilitate the implementation of the macro feature now actually makes it much easier to implement support for USE_CODE_IF. Since this is probably the only standard-KSP feature missing it would make sense to add support for it.
> 
> I wonder about two things:
> 1) I suppose it would be logical to strip code based on USE_CODE_IF conditions before handling and inlining macros, right?
> 2) Should the conditions be affected or unaffected by namespaces? In other words, if you write SET_CONDITION(eq_support) in the script module M and *import* "M.txt" *as* M in another script, should the condition then be referenced as eq_support or m.eq_support? Maybe the former would be more useful since imported scripts would then be able to use conditions set in the main scripts from which they were imported.



Hi Nils,

I haven't had time to fully digest the above yet but, it occurs to me that I stopped using the KSP's USE_CODE_IF after you added the Optimize option to the KScript Editor. The problem, as I recall, was that the unused code still remains in the KR source code whereas when one uses your Optimize feature, none of the unused code is included in the KR source (a highly desireable feature, especially since K2/K3 has trouble with large text files).

Why would we need to include USE_CODE_IF? Is there something we could do with it that we can't do with your Optimize feature, I mean as far as conditional compilation is concerned? As I said in my prior post, I need to spend a little time studying the above because I may not be fully understanding the need.

God Bless,

Bob


----------



## kotori (Mar 15, 2009)

The advantages of supporting USE_CODE_IF are:
 The compiler can remove the code not used (the code optimizer option can do this too, but it is the last step of compilation. In case large pieces of code are discarded then removing it in the first compilation step could speed up the compilation)
 All scripts written using purely standard KSP syntax would compile.

I wonder if there are any cases where one would want the compiler not to discard code inside USE_CODE_IF with false conditions. I suppose one could want this for testing, but to me it doesn't seem very important.


----------



## Big Bob (Mar 15, 2009)

kotori @ Sun Mar 15 said:


> The advantages of supporting USE_CODE_IF are:
> The compiler can remove the code not used (the code optimizer option can do this too, but it is the last step of compilation. In case large pieces of code are discarded then removing it in the first compilation step could speed up the compilation)
> All scripts written using purely standard KSP syntax would compile.
> 
> I wonder if there are any cases where one would want the compiler not to discard code inside USE_CODE_IF with false conditions. I suppose one could want this for testing, but to me it doesn't seem very important.



Hi Nils,

I think that providing support for USE_CODE_IF will provide a second way to effect conditional compilations and if the KSE actually removes the code from the KR source, it will be just as useful (if not more so) than what we have now. And, your second point about proper handling of pure KSP code is certainly valid. 

It seems though that I remember that under some conditions the Kontakt pre-processor directives didn't always work properly. But, that may have been corrected and/or it may not affect what you are planning to do.

As to wanting to overide the discarding of code for test purposes, couldn't one just comment out the USE_CODE_IF for testing? EDIT: Or perhaps you meant to also pass the USE_CODE_IF through to Kontakt to see if it would handle the conditional compilation properly?

Finally, as to the 'namespace' treatment when using 'import as', I can think of arguments on both sides of the fence. Might it beòÜQ   ˜ŠÜQ   ˜Š‘ÜQ   ˜Š’ÜQ   ˜Š“ÜQ   ˜Š”ÜQ   ˜Š•ÜQ   ˜Š–ÜQ   ˜Š—ÜQ   ˜Š˜ÜQ   ˜Š™ÜQ   ˜ŠšÜQ   ˜Š›ÜQ   ˜ŠœÜQ   ˜ŠÜQ   ˜ŠžÜQ   ˜ŠŸÜQ   ˜Š ÜQ   ˜Š¡ÜQ   ˜Š¢ÜR   ˜Š£ÜR   ˜Š¤ÜR   ˜Š¥ÜR   ˜Š¦ÜR   ˜Š§ÜR   ˜Š¨ÜR   ˜Š©ÜR   ˜ŠªÜR   ˜Š«ÜR   ˜Š¬ÜR   ˜Š­ÜR   ˜Š®ÜS   ˜Š¯ÜS   ˜Š°ÜS   ˜Š±


----------



## Dynamitec (Mar 16, 2009)

> I'm anxious to try more experiments with the new Macro facility. I have the feeling that it will provide solutions for a lot of my 'wishlist' stuff.


Same here! I've been playing with this macro stuff for a while now and it definitely makes live much easier in a lo of cases. 

@Nils: i think your USE_CODE_IF idea to speed up compilation time is great! Because compilation time can be really long with the optimization turned on.

PS: It's really time for me to visit PayPal again :D A small reminder for all of us that there is a donate button on http://nilsliberg.se/ksp. I think it's just fair to give Nils a little bit back for the time he is spending on this great editor! o-[][]-o


----------



## Big Bob (Mar 16, 2009)

> PS: It's really time for me to visit PayPal again A small reminder for all of us that there is a donate button on http://nilsliberg.se/ksp. I think it's just fair to give Nils a little bit back for the time he is spending on this great editor!



I'll second that motion :D

EDIT: I guess I should mention that I had to fight a little to get to the Pay Pal button :lol: Using the link in Benjamins\'s post seemed to pull up a page announcing something called a Django page. To me Django was the famous 'Hot Club' guitar player :roll: But, I found another entry point that seemed to work OK.


----------



## Big Bob (Mar 16, 2009)

Hey Nils,

I have a question about the syntax highlighting. I wanted to darken the green used for comments so I edited the *styles.in*i file in an effort to accomplish that but it didn't seem to have any effect. Is there more to it than changing the *syles.ini *file?

Bob


----------



## kotori (Mar 16, 2009)

Now V1.3 of the editor is available for OSX too. :arrow: *Download*
I also updated the extended syntax documentation to cover macros.

Big Bob, previously it only worked with the "Folding and extended syntax highlighting" option on. I have now uploaded a new PC version (same version number since I was too lazy to change it) which uses the styles.ini file even when this mode is off.


----------



## Big Bob (Mar 16, 2009)

Hey Nils,

Thanks a million for the update to enable the styles.ini. My old eyes are getting worse and I needed a darker color to be able to read comments more easily.

God Bless,

Bob


----------



## Dynamitec (Mar 27, 2009)

Hi Nils,
I found an small issue:

_{The following code...}_

*on init*
``*declare* Array[128]
``*for* Array[1] := 0 *to* 100
```
``*end for*
*end on*

_{...should be translated into this KSP code (which works):}_

*on init*
``*declare* %Array[128]
``%Array[1] := 0
``*while* (%Array[1] <= 100)
````inc(%Array[1])
``*end while* 
*end on*

_{But I can't compile this example above in the editor }_

Cheers,
Benjamin


----------



## Big Bob (Mar 27, 2009)

I also tried this with V125.6 and it doesn't compile either. Maybe this has been with us a while and just never showed up because we don't often use an array element as a loop variable?

Maranatha,

Bob


----------



## Dynamitec (Mar 27, 2009)

Yes, I think this never compiled in any version of the editor. I found this problem today when I converted a algorithm from PHP to KSP a friend of mine wrote.


----------



## Dynamitec (Mar 27, 2009)

Another issue I have with the newest version of the editor: if I open a file it doesn't jump to the new file. I think this worked different in older versions.


----------



## Big Bob (Mar 27, 2009)

Yes indeed. I thought there was something different about the way the latest version worked in this regard and, your right Benjamin. The prior versions used to move the focus to the newly loaded file whereas V1.3 stays with the current tab.

NIls, was this perhaps an intentional new feature or just an accident? :lol: 

God Bless,

Bob


----------



## Dynamitec (Mar 27, 2009)

Hi Nils,

Thanks for the quick fix. But something is broke now. I can't compile a script which worked with 1.3 now.

I get a syntax error:

Syntax Error
for $_Queue__i3 := 0 to 127

I'm going to search what the problem might be.

Cheers,
Benjamin

Edit: The problem is that all other "for" loops can't be compiled anymore. >8o 

This won't work:

on init
declare i

for i := 1 to 124
end for 
end on


----------



## kotori (Mar 27, 2009)

Oops, how sloppy of me. Forgot the '?' in the regular expression to make the for loop variable subscript optional - even though I remember thinking I must not forget that. :oops: 
I have fixed it now and replaced the previous installation file with this one (same url as before but a new file). Please redownload it.


----------



## Dynamitec (Mar 27, 2009)

Hi Nils,
thanks for the quick fix! I'm testing it later!
Cheers,
Benjamin


----------



## Big Bob (Mar 27, 2009)

Yes indeed, thanks a million Nils. I'll also test some more later, but initially everything seems OK now.

Just out of curiosity, does V1.3 use the registry or a win ini file or some such animal? The reason I ask is that I installed V1.3.1 but left V1.3.0 installed as well. Then, when I opened V1.3.1 for the first time, I expected to have to set all my options but was startled to see everything exactly the way I set it for V1.3.0. This has never happened before so something must be different? If I had removed V1.3.0 first would that have then caused V1.3.1 to install with default options?

Actually, for my purposes, it's better this way. I usually keep several recent versions of the KScript Editor installed in case a problem is found later and it's then often convenient to revert to an earlier version for comparison. In the past whenever I have installed a new version, it always comes up the first time with a set of defaults and those differ somewhat from my preferences. This is the first time a new version came up with everything as I set it for the prior version. Just curious how you have worked this magic? 8) 

God Bless,

Bob


----------



## kotori (Mar 27, 2009)

Hi Bob,

Yes, I moved the settings file to another place than the installation folder to make it possible to save settings in the OSX version while keeping a small size on the installation thanks to the folder being read-only. On PC the file is now saved in the folder: C:\Documents and Settings\<Username>\Application Data\KScript Editor\

Cheers,
Nils


----------



## Big Bob (Mar 27, 2009)

Ah so! Excellent idea, I like it. 8) 

God Bless,

Bob

BTW The new macro facility has already proved quite useful even for the few little scripts I've been working on. I'm sure it will be quite useful for cleaning up the KS source for larger projects.


----------

