# Script Editor V1.21 - release candidate



## kotori (Feb 18, 2007)

Hi everyone,
I made some updates to the script editor. Feel free to try the http://nilsliberg.se/ksp/setup-kscript-editor-1.21RC1.exe (V1.21 release candidate) and let me know what you think.

Changes:
New menu item in the Script menu: Recompile last script. If you compile your main script once, you can then press F6 while editing modules which it imports (you'll have to save changes to the modules before compiling though). This is meant to make it easier to compile while editing modules.
New option in the Settings menu: Extra syntax checks. This pipes the output of the normal compiler into my new compiler which does a more thorough analysis of the code. This will increase the compilation time, but it will detect more errors. The compiled code is not affected.
The new syntax check cannot yet handle initializations in declarations that start with "(" since it confuses these with array literals. So it cannot yet handle things like this: *declare* x := (y+1)*5
It also doesn't handle USE_CODE_IF... preprocessor directives yet. Since it hasn't been subject to a lot of testing yet I hope to get some feedback about areas where it incorrectly report errors. With some adjustments I hope that the syntax check will give better error reporting. Here's one example of it doing a better job than even the built-in checking in K2. K2 would point you to the message line whereas my syntax checker correctly points you the first line:
*on init*
``*declare* *const* $y := find_group("name")
``*declare* $x := $y
``message("")
*end on*


----------



## kotori (Feb 18, 2007)

I fixed a minor problem and reuploaded the installation (same link as above).

Some more information about the syntax checker: It will recognize all syntax errors which deviates from this http://nilsliberg.se/ksp/grammar.html (grammar). Furthermore, it will try to determine the type of all expressions and detect unvalid types in assignment, if, select and while statements. It will also evaluate expressions which have to be constant (array sizes, constant initializations, UI control parameters) to make sure they are.


----------



## Dynamitec (Feb 18, 2007)

Hi Nils,

sorry, but i have to say: nothing seems to work here. 
There is no "successfully compiled the script" message and nothing in the clipboard.
Even with very small scripts :(


----------



## Dynamitec (Feb 18, 2007)

Nevermind! It works now. But you have to delete the old directoy first, before installing the new release! :D

Thanks for the extended syntax checks! This is surely a time-safer! =o


----------



## Dynamitec (Feb 18, 2007)

Found a bug:

Expected expression of integer type, got string. at line xxxx.
_get_folder($GET_FOLDER_PATCH_DIR) & "\sample\IR\body_1.wav"

Used that way:

_load_ir_sample(_get_folder($GET_FOLDER_PATCH_DIR) & "\sample\IR\body_1.wav", 0,0 )

there should be a string expected, not a integer => _get_folder()


----------



## kotori (Feb 18, 2007)

Thanks Benjamin. It's fixed now. Please download the new installation file (same link as before).
The script looks at the functions in the ksp_util.txt file and tries to interpret the parameter names as types, but I had forgotten to include a "file name" -> string mapping which is needed for _load_ir_sample. Please let me know if you find anything else.

Cheers,
Nils


----------



## Dynamitec (Feb 18, 2007)

Thanks Nils! If only NI would be as fast as you in releasing new updates and fixing bugs!


----------



## Dynamitec (Feb 18, 2007)

So - the almost 15000 lines (compiled) here are compiled without any problems. And i use almost everything that is possible to use in KSP. The only thing i don't like with the new extended synatx checking is, that it now takes about 15 seconds to compile the whole script. On the other hand: since the syntax is checked and i don't have to trace error messages in a very slow kontakt editor, this is still fine!

Thanks Nils!!!


----------



## kotori (Feb 18, 2007)

Thanks for that feedback Benjamin. I'm glad to hear that it's working. I wonder, how long does it take to compile the whole script with syntax checking disabled?


----------



## Dynamitec (Feb 18, 2007)

A little more than half as long...or 2/3...something like that.


----------



## Nickie Fønshauge (Feb 20, 2007)

Nils, I get a "Syntax error at line 218: )".
Line 218 is:

``````*declare* !text[2]

And I cannot get it to highlight ".and.", ".or." & ".not.", when I add these to ksp_util.txt. It works with plain "and", "or" & "not". Shouldn't it work with ".and.", ".or." & ".not." too?

Maybe you could add

local
global
and
or
not
.and.
.or.
.not.
mod
polyphonic
ui_knob
ui_button
ui_menu
ui_value_edit
ui_label
ui_table

to ksp_util.txt, so I don't have to add them each time I update the editor?


----------



## kotori (Feb 20, 2007)

Nickie Fønshauge @ Tue Feb 20 said:


> Nils, I get a "Syntax error at line 218: )".
> Line 218 is:
> 
> ``````*declare* !text[2]
> ...



That syntax error is strange, because I don't get any error when I compile this alone:
*on init*
````*declare* !text[2] 
*end on*
Do you get that? If not, could you please post the contents of line 217.

About the bitwise operators: I think the Scintilla component which my editor is built on only handles words without any special characters so syntax highlighting them is difficult.

Cheers,
Nils


----------



## Nickie Fønshauge (Feb 20, 2007)

Line 217 is 


``````Lock.value := ON

ON is a constant. I know this line is correct; K2.2 has eaten it.

I don't know about ".and.". I noticed it was hightlighted in Bob's XFadeDemo with v1.20. And I didn't add anything to ksp_util.txt there. But the highlighting is gone in v1.21.


----------



## Nickie Fønshauge (Feb 20, 2007)

When I compile your example, I don't get the error. This snippet is accepted:

*on init* 
````*declare* *const* ON := 1
````*family* Lock
``````*if* 1 = 1
``````*declare* ui_button value _{Locks GUI parameters}_
``````Lock.value := ON
``````*declare* !text[2]
``````*end if*
````*end* *family*_{Lock}_
*end on*

Line 217 is 

``````Lock.value := ON

I know this line is correct; K2.2 has eaten it.

I don't know about ".and.". I noticed it was hightlighted in Bob's XFadeDemo with v1.20. And I didn't add anything to ksp_util.txt there. But the highlighting is gone in v1.21.


----------



## kotori (Feb 20, 2007)

Hi again Nickie,
Could you try to first compile the code without the syntax check, paste the compiled code in a new window and then syntax check that and see if you can determine the error from that. Would it be possible for you to send the script to me so I can check it? You could compile it using "compact compiler output" (without syntax checking) and mail me that in case the source code is confidential.



Nickie Fønshauge @ Tue Feb 20 said:


> I don't know about ".and.". I noticed it was hightlighted in Bob's XFadeDemo with v1.20. And I didn't add anything to ksp_util.txt there. But the highlighting is gone in v1.21.


In the editor? Please note that .and. will be highlighted in BBCode and html by default since I'm able to use my own code there.

Nils


----------



## Nickie Fønshauge (Feb 20, 2007)

kotori @ 20th February 2007 said:


> Please note that .and. will be highlighted in BBCode and html by default since I'm able to use my own code there.


That's it then. I saw it in a printout from my browser.


----------



## Nickie Fønshauge (Feb 20, 2007)

I did as you requested, and I didn't even get to the previously offending line. Now I get the same kind of error message from 

````````*declare* *const* $Instrument__Groups__Sustain__TYPES := 1
````````*declare* %Instrument__Groups__Sustain__first[$Instrument__Groups__Sustain__TYPES] := (0)

Instrument is an import module, and Groups__Sustain__first (Groups.Sustain.first) a hierarchi of families.

The script is on its way to your yahoo account.


----------



## kotori (Feb 20, 2007)

Nickie Fønshauge @ Tue Feb 20 said:


> I did as you requested, and I didn't even get to the previously offending line. Now I get the same kind of error message from
> ````````*declare* %Instrument__Groups__Sustain__first[$Instrument__Groups__Sustain__TYPES] := (0)



Ah, so this is the (incorrectly reported) error.
As I wrote above the syntax checking still has some problems with telling array initialization and parenthesized expressions apart. I thought a single value would always be identified as an array initializer, but maybe there's something I didn't take into consideration. The strange thing is that both of the following lines generate errors because of their use of parenthesis:
``*declare* x`````:= (1)
``*declare* %y[1] := (1)``

I'll look into it.

Cheers,
Nils


----------



## kotori (Feb 20, 2007)

I fixed the problem with array initializations and also added a new setting: it's now possible to direct the compiler to not insert any comments on function invocations. Please download the new installation file using the link in the first thread above (same URL as before).

Thanks Nickie for sending the script. It was very helpful because it helped me correct a couple of other problems before anyone noticed. I guess your script must be more powerful than Benjamin's since it's the only one of the two which brought the compiler to its knees. :wink: 

Cheers,
Nils


----------



## Nickie Fønshauge (Feb 20, 2007)

kotori @ 20th February 2007 said:


> I guess your script must be more powerful than Benjamin's since it's the only one of the two which brought the compiler to its knees. :wink:


Or just more messy


----------



## Dynamitec (Feb 20, 2007)

o=< Hehe... ^^

I never said that my script is powerful *g* I only said it's large...

Just kidding: i really try to keep things simple..


----------



## lanter (Feb 25, 2007)

Hi Nils,

A small, unimportant, but still somewhat annoying impractical bug still in 1.21.
When selecting an integer by double clicking that always selects an adjacent "[", "(" or "," as well, where it should select only the integer (even the K2 editor does that correctly...  )
Like: $array[0], double clicking the 0 will select either [0 or 0]

Like I said, nothing big but it can lead to accidently deleting a [ etc while copy/pasting, resulting in corrupt code.

Great editor BTW 8)


----------



## kotori (Feb 26, 2007)

lanter @ Sun Feb 25 said:


> Hi Nils,
> 
> A small, unimportant, but still somewhat annoying impractical bug still in 1.21.
> When selecting an integer by double clicking that always selects an adjacent "[", "(" or "," as well, where it should select only the integer (even the K2 editor does that correctly...  )
> Like: $array[0], double clicking the 0 will select either [0 or 0]



Hi Jan,
Thanks for reporting this. The editor is built on the scintilla text editor component and it seems it behaves a bit strange in this regard. Unfortunately it's not very easy to change, and even less so if I want the porting to OSX to remain easy. However, understanding the thought behind it might make it easier to work with. I think when you double-click Scintilla first finds out the corresponding cursor position. This means that one cannot actually click on "0" - one will always click either to the left or right of it. Scintilla then extends the selection from this position in the same way as if you had pressed Ctrl+Left and Ctrl+Right to move to the left/right word end (at least this is my theory). So as long as you double-click in the middle of variable names and numbers and they are at least two characters long it will work. To me it seems that a better way for Scintilla to behave would be to check if the clicked caret position represents a word boundary and if so only extend the selection in one direction. Feel free to report the problem to the http://mailman.lyra.org/mailman/listinfo/scintilla-interest (Scintilla mailing) list if you like.

Cheers,
Nils


----------



## kotori (Feb 26, 2007)

I changed the version to V1.21 and updated the download link on the KScript Editor web page.

No changes except that this version is now based on version 2.5 of Python and the parsing library on which the syntax check relies has been updated (some performance improvements in the latest version). Taken together this will hopefully increase performance a little although I don't want to exaggerate its importance.


----------



## Nickie Fønshauge (Feb 26, 2007)

True, the present behaviour can be a bit annoying, when you want to select a single digit number. But, it also has its positive aspects. Selecting a number and its surrounding brackets is very easy: just double-click between the leftmost digit and the leftmost bracket and extend rightwards until the rightmost bracket is also selected. Or start to the right and work the other way. I have made use of this feature numerous times, so I am not so sure I want any changes.


----------



## Nickie Fønshauge (Feb 26, 2007)

Here we go again, Nils. Another "Syntax Error".


````*family* Lock
``````*if* 1 = 1
``````*declare* !text[2]
``````Lock.text[OFF] := "Unlocked"
``````Lock.text[ON] := "Locked"
``````*end if*

It doesn't like the "Lock.text[OFF]" LINE


----------



## Nickie Fønshauge (Feb 27, 2007)

Hi Nils, 

I don't invoke Log10 directly but rather Get_db, which in turn invokes Log10 and some other stuff. But you are right, there are some very_long_expressions passed as parameters. I got around it by editing the Log10 function: I put the offending boolean expression inside ().

I will try, what you suggested for the other problem, when I get home.

Take good care of yourself and get well soon. That is more important than anything else.


----------



## Nickie Fønshauge (Feb 27, 2007)

What do you know. Now all of a sudden I don't get any "Syntax Error". I wish I knew what I changed.  You know, it is great to get these cryptic error messages at an earlier stage, instead of having to wait for K2 to spit them out. :wink: :mrgreen:


----------



## Dynamitec (Feb 27, 2007)

Hi Nils,
i can't remember but did you compile it always this way:

*Example:*

on note
test
end on

function test
declare a := 1

message(a)
end function

*compiles to:*

on init
declare $_a := 1
end on

on note
$_a:= 1

message($_a)
end on

*While:*

on note
test
end on

function test
declare global a := 1

message(a)
end function

*leads to:*

on init
declare $a := 1
end on

on note

message($a)
end on

This makes sense of course! But i'm just curious if you really changed this. I could swear a part of my library worked and now i searched for a bug and found this behaviour...

:roll: 

But maybe i made some other mistakes...


----------



## kotori (Feb 27, 2007)

Hi Benjamin
It hasn't changed since V0.98 of the editor as far as I can tell. 

Btw. there's one slightly unintuitive case which I'd like everyone to be aware of. If you declare and initialize a local variable on the same line the variable will be assigned the value every time you call the function, BUT if you declare a local variable without assigning any value at the line of declaration the value zero will not be assigned every time you call the function. I could do that but I feel that too many unneeded assignments would then be performed which would make scripts longer than necessary and reduce performance. So to ensure a default value of zero for a local variable for every function invokation you need to explicitly assign zero to it.
In short: _a global variable is always guaranteed a default value of zero while a local variable doesn't have any default value in the context of a function (it's undefined unless something is assigned)._


----------



## Nickie Fønshauge (Feb 28, 2007)

You are right, Nils, that is not intuitive. But, thanks for the heads up. I wasn't aware of this.


----------



## kotori (Feb 28, 2007)

I'd just like to add that if anyone has ideas about how to improve how local variables are treated I'm open for suggestions. It's not hard to add a zero assignment to uninitialized local variables. I have just been trying to avoid
``*declare* i
``i := 5
inside functions being expanded to:
``i := 0
``i := 5

Some extra zero assignments would probably not hurt much if it weren't for the K2 slowdown for large scripts.


----------



## Dynamitec (Feb 28, 2007)

Hi Nils,

if you do it, please make it as a option! Because old scripts couldn't work anymore!


----------



## kotori (Feb 28, 2007)

Dynamitec @ Wed Feb 28 said:


> Hi Nils,
> 
> if you do it, please make it as a option! Because old scripts couldn't work anymore!



Of course. Please note that I have no personal desire to change the behaviour. I think the way it currently works is a reasonable compromise.


----------



## Dynamitec (Feb 28, 2007)

Personally i wouldn't change it


----------



## lanter (Feb 28, 2007)

Sorry to intrude :oops: 
I didn't know there is an option for local/global variables.
Only learned about the objectlike family thing from this post.
Where can I find a reference for the additions the script editor provides?

Thanks


----------



## kotori (Feb 28, 2007)

lanter @ Wed Feb 28 said:


> Sorry to intrude :oops:
> I didn't know there is an option for local/global variables.
> Only learned about the objectlike family thing from this post.
> Where can I find a reference for the additions the script editor provides?
> ...



Hi Jan,
You don't intrude at all. Don't worry. I'm very happy to see another scripter hang around here.  
Did you look at the image overview linked from the web page of the editor. What it doesn't show is the import feature which lets you build modules of reusable functions and import them from other scripts. Using them looks like this:
````import "mymodule.txt" as math
````
````*on note*
``````math.arctan2(x, y, result)
````*end on*
or without naming the module like this:
````import "mymodule.txt"
````
````*on note*
``````arctan2(x, y, result)
````*end on*

For functions with a name starting with 'on_init' declarations are implicitly global (accessible from other functions) for convenience. So if the math module need variables you can declare these inside a function called 'on_init' in the module and then use them within the other functions of your module. In this case I recommend you invoke this initialization function inside 'on init' in the main script like this:
````import "mymodule.txt" as math
````*on init*
``````math.on_init
````*end on*

I should compile an updated overview when I get time.

Cheers,
Nils


----------



## lanter (Feb 28, 2007)

Hi Nils,

Thanks for the info.
Your function option already proved to be so very usefull 8) 
To be able to import function libraries will be a great asset as well. I presume only what is actually used will be compiled into the output?

Cheers,
Jan


----------



## Dynamitec (Mar 7, 2007)

Hi Nils,

i don't know if this was already posted:

i have two functions:

ArticulationVibratoInfo
...
...
some others here
...
...
ArticulationVibrato

If i click on "ArticulationVibrato" in 
the Callbacks and Functions tab,
the editor jumps to "ArticulationVibratoInfo".


----------



## kotori (Mar 7, 2007)

Benjamin, that one has been posted earlier, but thanks anyway for the reminder. /Nils


----------



## Dynamitec (Mar 12, 2007)

Hi Nils,

i get some declare errors with extended syntax checking when i import modules.
But in Kontakt the script works well. Also the number of the error line seems to be never correct when using a lot of imports.

Best,
Benjamin


----------



## kotori (Mar 12, 2007)

Dynamitec @ Mon Mar 12 said:


> I get some declare errors with extended syntax checking when i import modules.
> But in Kontakt the script works well. Also the number of the error line seems to be never correct when using a lot of imports.



Please post more information about this if possible. What do you mean by declare errors? Variables reported undeclared? Any patterns?


----------



## Dynamitec (Mar 12, 2007)

Hi Nils,

no pattern... yes, there is a "variable undeclared" error.


----------



## Dynamitec (Mar 12, 2007)

Hi Hils,

Please check your email...


----------



## kotori (Mar 12, 2007)

The extra syntax check was a bit too strict about consistent lower-case/update-case usage which I have now changed. I also changed a mistake which caused a pair of files named parsetab and lextab to be emitted into folders with scripts that you compile. These files contain parser optimizations and should be output to the program folder and not the working directory. I've fixed this now. If the earlier version generated any such files you can safely delete them.

The new version is available from the web page.

Cheers,
Nils


----------



## Dynamitec (Mar 12, 2007)

That was fast! Thanks Nils! If only would fix bugs that fast! 8)


----------



## Nickie Fønshauge (Mar 12, 2007)

kotori @ 12th March 2007 said:


> What do you mean by declare errors? Variables reported undeclared? Any patterns?


This reminds me of an odd problem, I had the other day. When compiling with the Syntax check, the editor didn't report anything; no "the script has been successfully compiled" or error messages. The only way I could detect, that compilation had finished, was when the cursor started blinking again. Since the script had apparently been compiled, I tried to load it in K2.2.1, but got an error message about a constant, that was not declared, only the constant *was* declared (and referred to apparently successfully) earlier in the script! Like I said: odd.


----------



## kotori (Mar 12, 2007)

Nickie Fønshauge @ Mon Mar 12 said:


> This reminds me of an odd problem, I had the other day. When compiling with the Syntax check, the editor didn't report anything; no "the script has been successfully compiled" or error messages. The only way I could detect, that compilation had finished, was when the cursor started blinking again. Since the script had apparently been compiled, I tried to load it in K2.2.1, but got an error message about a constant, that was not declared, only the constant *was* declared (and referred to apparently successfully) earlier in the script! Like I said: odd.


I'm not really sure I understand what the problem was in K2. However, I am aware of this problem in the extra syntax check. This was actually the top thing on my list until Benjamin's error report pushed it down to second place. It's happens because when a syntax error is detected an error report is generated, but sometimes and for reasons which I have yet to find the line number on which to base the report is missing, which causes a secondary and currently unhandled error. Please note that the compiled code will probably not be placed on the clipboard unless you get the normal "Sucessfully compiled" message.


----------



## Nickie Fønshauge (Mar 12, 2007)

kotori @ 12th March 2007 said:


> Nickie Fønshauge @ Mon Mar 12 said:
> 
> 
> > Well, it did get placed on the clipboard in my case. That's why I figured, it might be OK afterall. But, apparently it wasn't.
> ...


No, I am not sure. I don't know.


----------

