# KScript Editor V1.24



## kotori (Sep 29, 2007)

Hey all fellow scripters,
I upgraded KScript Editor to V1.24 today. Screenshot.
:arrow: Download

_New:_
 Modifications to script modules no longer need to be saved before compiling the main script that depends on them. The unsaved code is used.
 Upon compile errors in open script modules the program will automatically switch to the corresponding tab and move the cursor to the problematic line (this was previously only done for errors in the main script).
 Integrated and searchable KSP Reference.
 Docking support for the Navigation panel and KSP reference (grap their title bar and drag and drop them somewhere else, or rip them off to create floating windows).
 More sensible default settings, eg. extra syntax checking and folding on, navigation panel and KSP reference visible by default.
 Support for Kontakt 3 (thanks to Benjamin)
I will repeat what I've said earlier about folding: it is rather demanding so users who work with quite large files are recommended to make an active decision about whether or not they want to keep this on (it can be deactivated in the Settings menu). However, the performance hit practically only affects the loading time and not the performance while editing.

There's a new View menu where you can decide what panels should be visible. You can there also choose to restore the default position and size of the two panels.

The KSP Reference should be pretty straight forward. Just type something in the search box to look it up. The documentation is stored in a file called "ksp_doc.txt" in the installation folder, so users who want to add or corrects things are welcome to do that.

Cheers,
Nils


----------



## Dynamitec (Sep 29, 2007)

You are my hero! Thank you SO MUCH, every new update is like a birthday party!


----------



## Tod (Sep 29, 2007)

Thanks a lot Nils and I echo what Benj says,

Got it installed and love it.. :D


----------



## Dynamitec (Sep 29, 2007)

Hi Nils,
the Kontakt 3 commands don't work at moment.

This is how they are supposed to work:

on init
_pgs_create_key(FIRST_KEY, 1) 
_pgs_create_key(NEXT_KEY, 128)
end on

on ui_control(...)
_pgs_set_key_val(FIRST_KEY, 0, 70) 
_pgs_set_key_val(NEXT_KEY, 0, 50) 
_pgs_set_key_val(NEXT_KEY, 127, 60) 
end on

If i write:
_pgs_create_key(FIRST_KEY, 1) 


Your editor says FIRST_KEY is not declared.


----------



## kotori (Sep 29, 2007)

Ah, I see. That wasn't directly evident from your earlier example. I thought these variables needed to be declared like normal variables. I assume that _pgs_create_key is similar to the 'declare' construct then, right?


----------



## Dynamitec (Sep 29, 2007)

Yes!  Sorry...should have made this clear.


----------



## kotori (Sep 29, 2007)

Benjamin, can the key names also be prefixed with $?


----------



## Dynamitec (Sep 29, 2007)

No, the are without prefix!


----------



## Nickie Fønshauge (Sep 29, 2007)

Nils, I am afraid the "Callbacks and functions" pane no longer works. On some (most) of my files it shows only an incomplete list of families and functions and none of the callbacks.

EDIT: I found the reason; It seems leading blanks are no longer allowed :?


----------



## Dynamitec (Sep 29, 2007)

Hi Nickie,
don't worry it will be fixed in KScript Editor 3! :mrgreen: 
Oh, i forgot it's Nils Editor we talking about... o

*edit* Really, if this new update of the editor is stable, it's another great step for us scripters! Time to visit PayPal soon! The build-in reference is soo useful!


----------



## Nickie Fønshauge (Sep 29, 2007)

Dynamitec @ 29th September 2007 said:


> Hi Nickie,
> don't worry it will be fixed in KScript Editor 3! :mrgreen:
> Oh, i forgot it's Nils Editor we talking about... o


Yikes, Benjamin, that would be some time after KScript Editor 2.99 >8o :mrgreen:

Btw Nils, a thing that has bugged me for a while is the fact, that the "Functions and callbacks" resets to the top of the list each time I change tab. It is a bit of a nuisance to have to scroll through it every time I jump to a tab, where the visible part of the main window corresponds to a non-visible part of the "Functions and callbacks" list due to the reset, and I want to jump to an adjacent, non-visible part of the file. Couldn't the list and the main window be synchronized, like in Windows Explorer?


----------



## Dynamitec (Sep 29, 2007)

But i'm sure it will be 64bit!


----------



## Nickie Fønshauge (Sep 29, 2007)

And min. 4 cores, please.


----------



## mmosc (Sep 29, 2007)

Nils,

Can't thank you enough for this. The compile errors going to the source file is great as is the KSP Reference


----------



## Nickie Fønshauge (Sep 29, 2007)

Dynamitec @ 29th September 2007 said:


> The build-in reference is soo useful!


Absolutely, especially when it is complete. Nils, you forgot "INTMOD_TYPE_ENVELOPE".


----------



## kotori (Sep 29, 2007)

I hope the problems above are fixed now. Please download V1.24.1.

Changes:
* Restored support for indented functions/callbacks to be included in the list.
* Added INTMOD_TYPE_ENVELOPE.
* Fixed key-id support (hopefully) for Kontakt 3


----------



## Nickie Fønshauge (Sep 29, 2007)

And "$INTMOD_TYPE_LFO"

Wow, that was a fast reaction :D


----------



## Big Bob (Sep 29, 2007)

Fast? I'll say! I just came online to discover that Nils just released a new editor update and already you guys beta tested it and, even more amazing, Nils fixed all the problems before I could even download it the first time :o .

I'll give it a test drive this afternoon but the new features sound great :D What a marvelous and indispensible tool this has become, Benjamin is right; time to visit Paypal again o=< .

Thanks a million Nils.

God Bless,

Bob


----------



## Dynamitec (Sep 29, 2007)

Hi Nils,
i forgot on command:

Here is another callback:

on _pgs_changed

Best,
Benjamin


----------



## Big Bob (Sep 29, 2007)

Hey Nils,

I just compiled a script with a syntax error (extra parenthesis) and the editor put up the usual dialog but it didn't highlight the offending line. The error was on the main script (not an import). Hopefully this will be easy to fix?


*Edit: After using the editor for a while, the new wonderful feature about jumping to the right script file when it is other than the main script seems to work just fine but, it looks like somehow the price was that the main script now doesn't :lol: .*

BTW Since you have your Editor updating hat on for a bit :wink: , I'd like to repeat a request for a new feature that I asked for a long time ago. When using the 'for' loop construct, it would really be nice if we had another variant of it that would iterate to the 2nd limit less one. For example:

for n := 3 to xyz - 1
{ do something }
end for

Could be written something like:

for n := 3 to< xyz
{ do something }
end for

This would be more than a cosmetic improvement. The way it is now, the compiled code is less efficient than writing it directly in K2-Ready code. As it is, your compiler will translate the first example into:

$n := 3
while ($n <= $xyz -1)
{ do something }
inc($n)
end while

Whereas it could be written as:

$n := 3
while ($n < $xyz)
{ do something }
inc($n)
end while

This construct with the xyz - 1 happens very frequently and it seems a shame that this subtraction has to be done at runtime (when it could so easily be done at compile time). While it may not amount to a 'hill of beans' overall, it nevertheless seems like something worth addressing if it isn't overly difficult to implement.

Just thought I'd take a shot at pitching this idea to you again 8) 

God Bless,

Bob


----------



## kotori (Sep 30, 2007)

Dynamitec @ Sat Sep 29 said:


> Hi Nils, i forgot one command:
> 
> Here is another callback:
> 
> on _pgs_changed



Does it take any parameter (like on ui_control)?

Btw. I fixed the problem with syntax errors not being highlighted in the main script. Download the 1.24.1 installation again to get it. As soon as I get an answer to the question above I will try to add that callback too and issue version 1.24.2.


----------



## Dynamitec (Sep 30, 2007)

Hi Nils,



> Does it take any parameter (like on ui_control)?



No, just the callback no parameters.

Best,
Benjamin


----------



## Dynamitec (Sep 30, 2007)

Hi Nils,
in the reference sometimes "sec" is shown but i think it should be micro seconds (or milli?), anywhy. But not seconds 

Example:

$DISTANCE_BAR_START
returns the time of a note on message in sec from the beginning....


----------



## Dynamitec (Sep 30, 2007)

Again a little problem:

I can't view a script as HTML when using ä, ö and ü or ß in the comments.

An error occured: 'ascii' codec can't encode character u'xfc in position xx: ordinal not in range (128)

Best,
Benjamin


----------



## Dynamitec (Sep 30, 2007)

And a little feature request:
It would be great if the functions in the "Callback and Functions" list would be dragable! It would be cool to sort them directly in the list (the source code is rewritten according to the new position of the function in the list).

Would be so cool!

And: double click let you change the name. And it's changed in the whole script whenever the function is called (like in Visual .NET).


----------



## Dynamitec (Sep 30, 2007)

And another small "bug":

i can't search replace long text lines. The replaced line is truncated at some point.

Best,
Benjamin


----------



## kotori (Sep 30, 2007)

Thanks for all the helpful feedback. I have now uploaded KScript Editor V1.24.2.

New:
* Fixes to the documentation (correct milliseconds unit and added "on _pgs_changed")
* Support for the Kontakt 3 __pgs_changed_ callback 
* Support for extended characters in comments in HTML export
* "for i := 0 to N-1" is automatically translated to "while i < N" instead of the earlier "while i <= N+1".

Benjamin, the long lines limitation seems to stem from the UI library I use, so I'm not sure if there's any easy way to fix it without redesigning the search/replace dialog box. I hope you can live with it for the time being. Your refactoring ideas are cool. I'll keep them in mind for a future version.


----------



## Nickie Fønshauge (Sep 30, 2007)

Another thing, that would be quite handy, is if double clicking an item in the KSP reference list inserts it at the cursor spot.


----------



## Nickie Fønshauge (Sep 30, 2007)

The parameter list in the KSP Reference info box doesn't wrap around like the explanatory text does. This makes it rather clumsy to read.


----------



## kotori (Sep 30, 2007)

Nickie Fønshauge @ Sun Sep 30 said:


> The parameter list in the KSP Reference info box doesn't wrap around like the explanatory text does. This makes it rather clumsy to read.


The tree UI control that I use to present the ksp reference doesn't support multiline items, but maybe you can make the reference panel wider, dock it to the bottom of the window, or hover the mouse over items that don't fit to see the complete text.


----------



## Big Bob (Sep 30, 2007)

> * "for i := 0 to N-1" is automatically translated to "while i < N" instead of the earlier "while i <= N+1".



Brilliant solution to the problem, thanks a million o-[][]-o 

I love some of the new features, especially the cursor to tab and line for errors not in the main script (and thanks for fixing the main script part of it).

I also appreciate the 'compile the edited code' for import scripts. Even with the '*' on each tab (when I forgot to resave an edit), I still fell into that pothole way too often :oops: 

The dockable windows is also really cool. All in all, a great editor just got 'greater' o=< .

God Bless,

Bob


----------



## Tod (Sep 30, 2007)

Hi Nils,

I'm loving it! :mrgreen: :mrgreen: 

This may be a dumb idea but I have to ask anyway. I just found out by accident yesterday that I can drag the mouse on the left side (with the numbers) and select whole lines.

Many times while experimenting I might declare two or more ui variables with the same name, just different elements (knob, value_edit, etc.) and exchange braces "{}" to try each one out. Or I might have two user functions I'm experimenting with that are the same but execute differently.

Would it be possible to select these things on the left side and then use a special keyboard command or Key-plus-LeftMouse to put them in and out of braces "{}". Maybe Ctrl-LeftMouse to {brace} them and Alt-LeftMouse to un-brace them. 

Just a thought.


----------



## mbncp (Sep 30, 2007)

Nickie Fønshauge @ Sun Sep 30 said:


> Another thing, that would be quite handy, is if double clicking an item in the KSP reference list inserts it at the cursor spot.


Call me lazy, but +1


----------



## kotori (Sep 30, 2007)

I fixed some minor things and uploaded a new installation file, replacing the current V1.24.2 so please download it again if you are interested in the changes.

Changes:
* Double-clicking a KSP Reference item inserts it into the code
* If you click an item in the Navigation panel the program tries to find the line closest to where the original declaration was seen. This makes it possible to navigate even when multiple items have the same name.
* Introduced some spaces to make word-wrapping work better for the ksp reference.


----------



## Nickie Fønshauge (Sep 30, 2007)

Nice. Thank you


----------



## mmosc (Oct 2, 2007)

Nils,

Thanks again for this wonderful tool, the new features are great time savers.

This may have been requested before but pre-compile directives like C ifdefs would be a life saver for me. Right now i'm doing this by hand using the search and replace so having the compiler perform this function would be a god send

Thanks again for this great tool

Mike


----------



## Big Bob (Oct 5, 2007)

Hi Nils,

Today I'm going to try to spend some time with K3's new KSP extensions. However, I notice one that wasn't on Benjamin's list that you may want to add to your editor. I'm sure we'll all be glad to have this one. :D 

set_control_help(<ctl>,<txt>)

This allows us to assign help text to panel controls. This text is displayed in the new 'Info' area whenever the user hovers the mouse over the control. 

I don't know if there are any other new commands (yet) because there is no KSP documentation provided with the initial K3 release. The KSP manual they ship with K3 is the old K2.1 manual (last updated in April of 06), they don't even include the K2.2 addendums.

To be continued...


Bob

*EDIT: Whoops! I just noticed that it is on Benjamin's list, sorry Benj. However, it doesn't seem to be implemented in the editor.*


----------



## kotori (Oct 6, 2007)

I uploaded a new KScript Editor version with a couple of small fixes. :arrow: Download.

Changes:
 Support and documentation for the set_control_help K3 function added.
 KSP reference documentation added for the set_table_steps_shown function.
 Fixed error checking bug for the _pgs_key_exists function.
Please note that _pgs declarations work differently than normal variable declarations. If a normal variable called "x" is declared in a module imported as "mymodule" its name in the compiled code will be $mymodule__x. If a key-id named x is declared inside the same imported module it's final name will remain "x".


----------



## kotori (Oct 6, 2007)

Big Bob @ Sat Oct 06 said:


> Thanks for the fixes, I'll check them out within the hour (hopefully)However, I notice that you don't mention the *_pgs_get_key_val *function, did you correct that one also? I guess I'll find out soon.


You're welcome. The _pgs_get_key_val function should work too. I just forgot to mention it. o

Cheers,
Nils


----------



## Big Bob (Oct 6, 2007)

Hi Nils,

Are you sure your upload was successful? I downloaded it about an hour ago and now I just ran a set of tests and it still has the same 3 problems. I'll try downloading again and then I'll retry but could you please check on it. Did you change the version number because the download I got was still V1.24.2?

Rejoice,

Bob


*EDIT*
Whoops! Maybe I got there too soon when I downloaded the first time because now I see the version number has been bumped to V1.24.3. So, I'll recheck everything.


----------



## Big Bob (Oct 6, 2007)

Hi Nils,

It all compiles OK now with V1.24.3, thanks a million for the corrections o-[][]-o . 

K3 still doesn't accept *on _pgs_changed*. I realize that this has nothing to do with your editor, but, since you have now joined the beta tester club, I thought I'd drop the question here. Do either you or Benjamin know what the problem with this new callback might be? I assume I have the syntax correct with:


```
on _pgs_changed
{callback code here}
end on
```

K3 highlights the on _pgs_changed line and says 'parse' error on the status line.

Any light you can shed on this would be much appreciated :? .

Thanks,

Bob


----------



## kotori (Oct 6, 2007)

Hi Bob,
Unfortunately I don't more than you about that. I would have expected that callback to have the form "on _pgs_changed(key-id)" but Benjamin said that there should be no parameter. Maybe you could try using "on pgs_changed", "on _pgs_changed(key-id)" or "on pgs_changed(key-id)" and see if any of them works.

Nils


----------



## Big Bob (Oct 6, 2007)

Good suggestion Nils, unfortunately nothing like that seems to satisfy K3 (although I don't see any difference between the last two you suggested, so maybe I missed some combination). I guess I'm stuck until someone figures this out or gets NI to explain it. They haven't been answering any of my K3 questions since I bought the thing.

Anyway, thanks for trying.

Bob


----------



## kotori (Oct 7, 2007)

Have you tried "on pgs_changed" or (without any underscore) or "on _pgs_change" or "on pgs_change"?


----------



## Big Bob (Oct 7, 2007)

Hi Nils,

Yes, I've tried every such combination I could come up with (and a few dozen more :lol: ). Unless you actually mean to put the *"on pgs_changed"* in quotes because I didn't try that :wink: .

Do you have (or are you going to be getting) the latest beta version of K3 that Benjamin seems to have? Maybe this is something they fixed after the public release and it will be forthcoming in an early update?

With this new callback working (assuming it works as I think it will) the *pgs* system will be a boon for cooperating scripts.* But, without the new callback, the value of the whole pgs system will be seriously compromised*. In fact it may be little better than some of the ad hoc schemes we've used in the past such as that employed by the ISCS.

So here we are again a day late and a dollar short :lol: 

Anyway, I'd appreciate anything you can find out about this callback, the slow compilation speed, and the Default Multi situation. Regarding the latter, I just noticed on page 23 of the K3 manual (about a third of the way down), it claims there is a *'Save as Default Multi' *command in the file Menu. However I can't find such a command. So is this something else that was left out of the public release but is coming later in an update?

Thanks Nils,

Bob


----------



## kotori (Oct 13, 2007)

Hi everyone,
:arrow: It's now possible to download http://nilsliberg.se/ksp/setup-kscript-editor-1.24.4.exe (Version 1.24.4 of KScript Editor).

_Changes:_
* Some minor adjustments to the KSP reference
* Code optimization - experimental (see below)

The code optimization evaluates all expressions that only include constants and literals and does the following:
 An if statement which is always true is replaced by it's body.
 An if statement which is always false is removed.
 A select statement with a constant operand is replaced by the first case clause that has a true condition.
 A while statement with a condition that is always false is removed.
 An empty if-statement is removed.
 Declarations of constant variables are removed and any occurance of those variables in the script are replaced by the value of the corresponding constant.
 The "Extra syntax checks" setting has to be on for the optimization to have any effect. Unfortunately it's quite slow at the moment and it's still an experimental feature. Btw. if you have any ideas about other optimizations one could perform please let me know.

Cheers,
Nils


----------



## Nickie Fønshauge (Oct 13, 2007)

kotori @ 13th October 2007 said:


> [*] An if statement which is always true is replaced by it's body.


Hi Nils,

You mean

if 1 = 1
<block>
end if

is replaced by

<block>?

That's not a good idea - remember "parser stack overflow"?


----------



## Nickie Fønshauge (Oct 13, 2007)

kotori @ 13th October 2007 said:


> Btw. if you have any ideas about other optimizations one could perform please let me know.


I once mentioned an "alias" feature, that would make it possible to declare a variable/family in one import module (or the mother script) and then address this by means of an "alias" declaration in another module. Well, maybe it is less of an optimization and more of a conveniance, that allows for fewer function parameters and thus enhances readability. But still, it would be nice, though.


----------



## kotori (Oct 13, 2007)

Good point Nickie! 
I removed part of that particular optimization to make it possible to use if 1=1 constructs. I uploaded a new installation file replacing the one above. Please download again (same url). If you use if and else the part that is false will still be removed during optimization.

By the way, if optimization is on a completely new code generation is used. Previously I just analysed the text using regular expression and special logic, but now I build a complete parse tree, modify that and then generate the output. This means that one cannot have 100% confidence in the correctness of the compiled code when optimization is on until we've had time to test this for a while (which is why it's marked experimental).

Cheers,
Nils


----------



## Big Bob (Oct 13, 2007)

> The code optimization evaluates all expressions that only include constants and literals and does the following:
> An if statement which is always true is replaced by it's body.
> 
> An if statement which is always false is removed.
> ...



Hi Nils,

That last one has me a little concerned. Are you saying that if I define a symbolic constant like: declare const X := 5, that your editor will chase down every occurence of X and replace it with a 'literal'?

I'm not sure of this but I think that symbolic constants are faster at runtime than literals. At least this is generally true and I would think even more so with running in interpretive mode.

Bob


----------



## kotori (Oct 13, 2007)

Big Bob @ Sat Oct 13 said:


> Hi Nils,
> 
> That last one has me a little concerned. Are you saying that if I define a symbolic constant like: declare const X := 5, that your editor will chase down every occurence of X and replace it with a 'literal'?
> 
> ...



Hi Bob
Why would a symbolic constant ever be faster than a literal? Why would it be faster in interpretive mode? 

Nils


----------



## Big Bob (Oct 13, 2007)

> Hi Bob
> Why would a symbolic constant ever be faster than a literal? Why would it be faster in interpretive mode?
> 
> Nils



Somehow I just knew that you were going to challenge my statement, and now I'm in trouble! :lol: 

Nils, my remembrance of this may be a little dated so I don't know how significant this is anymore. However, in the old, olden days, fetching a value from a pre-defined constant versus carrying it around with the instruction as a literal was generally more efficient (of course this depended somewhat on the size of the value in bytes relative to the instruction fetch size, etc). 

However, in a purely interpretive language, symbolic constants might be evaluated at compile time whereas literal constants might often be evaluated at runtime. In fact, I think the very first KSP guide use to say something about why they even provided symbolic or named constants. One of the reasons given was that the KSP handled constants more efficiently than literal strings representing numbers.

However, I notice that in the more recent docs about the KSP they say nothing about this anymore. Furthermore, compared to all the other things going on, this may not amount to a hill of beans as the expression goes. But coming from the era when processors were slow, memory was tight, and every little bit helped, I just naturally think that way.

God Bless,

Bob


----------



## kotori (Oct 13, 2007)

I'm still not quite sure I follow. How could anything be more "predefined" than a literal? We don't know the exact details of the KSP execution model but let's take the two most probably cases:

A. The entire script code is translated to byte code when one presses the Apply button. In this scenario a literal couldn't be less efficient because either one would have to lookup the value of a constant variable or constant variables would be replaced by their value upon compilation yielding the same performance for the two.

B. The script is not translated into byte code but each line is parsed and interpreted every time it's executed. Now, why would parsing a constant variable name and looking up it's value be faster than simply parsing a literal?

You almost seem to assume that constant variables are converted to some intermediate form for quick lookup whereas literals are parsed from text to integer each time. That scenario is highly unlikely in my view, but I'm not sure I understood you correctly. I would guess that scripts are compiled to byte code so I think that literals yields equally good performance as symbolic constants except they literals are often shorter in number of characters. This is only an optimization in script code size as I see it. Btw. considering that accessing registers is typically some thousand times quicker than reading/writing RAM I can't see how a variable deference could have been faster even in the "olden days".

Anyway, if the general view is that this optimization is not needed I have no problem removing it from the list.

Cheers,
Nils


----------



## Nickie Fønshauge (Oct 13, 2007)

kotori @ 13th October 2007 said:


> Anyway, if the general view is that this optimization is not needed I have no problem removing it from the list.


No, no, please keep this optimization! And I am all with you in your doubts about Bob's concern (sorry Bob  ). I too find it hard to understand how literals could be slower than symbolic constants. If anything, I would imagine it is faster. But certainly not slower.


----------



## Dynamitec (Oct 13, 2007)

Hi Nils,

i also find your optimization idea very useful! But much more useful i would found those things we discussed recently  Those inline commands...loops etc. which are translated on compiling...do you never miss them? ~o) :mrgreen: 

My 2cents  

But you are the artist...and KScript Editor your masterpiece. Do what ever you think that should be done 0oD


----------



## Big Bob (Oct 13, 2007)

Hey Nils,

I didn't mean to rub you the wrong way :( In the past you use to enjoy hearing contrarian ideas more than you seem to lately :( . So I'm not really sure if I should take any more time to try to detail my position. I guess if you are convinced that I don't know what I'm talking about, there would be little point in me saying any more about it. If such is the case, you can just skip the rest of this post.

From your last post, I would conclude that you can't even think of a situation where a symbolic constant could be handled more efficiently than a literal. *But, I assure you such situations do exist. *To lend some credibility to that statement, let me suggest the following scenario for your *Type B Interpreter*.

The literal specified in the declaration statement of the symbolic constant only has to be evaluated once and then stored at some address as a binary number. Now, as the executable code is interpreted, each time the symbol is encountered a simple table fetch is all that is required to get the value. Wheras, if instead the literal is repeated throughout the code, the character string must be converted to its binary value for each such encounter. Converting a character string to a number involves arithmetic (including multiplication by the radix which in the old days meant executing a subroutine for each digit converted). With a primitive processor, converting from an ASCII string to the equivalent binary value was a much more processor intensive operation than using a lookup table to fetch the value from memory. Depending on the size of the number type, a literal could take hundreds of times longer to convert than the time to fetch the same size binary number from memory.

Now, I realize that a Type A Interpreter wouldn't suffer as much (if at all) from this problem. I also realize that modern processors all have hardware multiply and divide, not to mention pipelined instruction fetch, and all the other goodies. But, since you made it sound like there was no conceivable way that literals could be less efficient, I chose the above as a simple example to illustrate the opposite.

I wish I had kept my earlier KSP manual because I'm almost positive that NI was claiming that they handled symbolic constants more efficiently than literals but,
actually, I'm kind of sorry I brought this issue up because I seem to be ruffling feathers. So, just dismiss me as another old coot that doesn't know what he's talking about :lol: However, it might be nice if these proposed optimizations can be selectively disabled; maybe just to pacify some old 'war horses' like me :wink: 

God Bless,

Bob


----------



## kotori (Oct 14, 2007)

Hi Bob,
I only find the discussion interesting, so there's no need to worry at all. 

Going back to the argument, you say that a lookup could be hundreds of times faster than a string to integer conversion. I'm not so sure. In order to lookup a variable name you need to search the symbol table for a certain string. There are two primary ways to do this: do a binary search of an ordered list or use a hash table mapping from symbol names to values. I wrote a small test in C comparing the execution time of 10^7 hash table lookups vs. the same number of string to integer conversions. The time needed for the latter was 16% lower than for the lookups (the hash function used only shift and add/sub operators, this is worth pointing out since naive implementations sometimes use the costly modulo operator). I guess binary search would be roughly as costly as the hash table lookup for a ordinarily sized symbol table.

Cheers,
Nils


----------



## Dynamitec (Oct 14, 2007)

Hi everybody,

i just asked the Kontakt developers which way really is faster in Kontakt. Now i'm waiting for the answer and let you know 

I also discovered some strange things:

I wrote a benchmark similar to this pseudo code (CASE 1 one time with constants and one time with literals):

start := ENGINE_UPTIME

for i := 0 to 10000
for j := 0 to 1000
Do a lot of calculations with constants/ literals here
end for
wait(1)
end for

end := ENGINE_UPTIME
difference := end - start

and i comapred it to this (CASE 2)

start := ENGINE_UPTIME
wait(10000)
end := ENGINE_UPTIME
difference := end - start

Ok, so far. The difference i wrote to a label was the same in both cases, but: the first case took a lot longer?! Why is that so? I mean that the difference from end - start is the same but the needed time is longer.


----------



## Big Bob (Oct 14, 2007)

kotori @ Sun Oct 14 said:


> Hi Bob,
> I only find the discussion interesting, so there's no need to worry at all.
> 
> Going back to the argument, you say that a lookup could be hundreds of times faster than a string to integer conversion. I'm not so sure. In order to lookup a variable name you need to search the symbol table for a certain string. There are two primary ways to do this: do a binary search of an ordered list or use a hash table mapping from symbol names to values. I wrote a small test in C comparing the execution time of 10^7 hash table lookups vs. the same number of string to integer conversions. The time needed for the latter was 16% lower than for the lookups (the hash function used only shift and add/sub operators, this is worth pointing out since naive implementations sometimes use the costly modulo operator). I guess binary search would be roughly as costly as the hash table lookup for a ordinarily sized symbol table.
> ...



The apparent contradiction is that you are comparaing the two strategies using current technology. I am continually amazed by how fast things can be done today compared to the 'good ol' days'. Being aware of this, I tried to qualify my original statement by saying that my experience in these areas is getting rather dated and many of the tried and true practices of the 70s no longer hold water so to speak. But, since you seem to be convinced that what I was saying could not be true at any point in the history of computing, let me try to paint a clearer picture of what things used to be like in the 70s.

First, symbol table searches didn't take very long (relatively) because symbols were kept very short (typically 5-characters or less) and symbol tables were pre-sorted as they were built. Secondly, processors had no hardware multiply or divide instructions so multiplication had to be implemented with subroutines that executed slowly and even then only handled 8x8 bit multiplies. To convert an ASCII string to a 4-byte signed integer thus required multiple, concatenated mulitplies and multi-byte shifting through the 'keyhole' of one 8-bit accumulator. I can vividly remember that after fine-tuning some hand-optimized machine code for the Intel 8080, I was able to get the time down to several milliseconds. By today's standards that would be an eon! Believe me table searches weren't blazing fast either but they were much faster (as much as 50 to 200 times faster) than the aforementioned ASCII to binary conversion routine. 

Now with today's much faster processors, you might think that the relative speed of table lookup and ASCII to binary conversion might remain in the same proportion but that isn't true. The kind of primitive operations involved in table search (mostly address arithmetic (addition) and operand compares (subtraction) have not improved by the same factor that mulitplication of multi-byte values has. Todays processors have sped up multiplication much more so than they have sped up the more primitive processes. I realize, in the light of using todays technology, that some of the above is a little hard to believe but, I speak from real-life experience not from some theoretical set of ideas. As I've said many times, I am almost amazed with the speed of things today. Even the KSP, which obviously runs in some form of interpretive mode, is blazingly fast relative to what things were like in the 70s. However, if you prefer, you can just consider some of my input as humorous anecdotes :lol: 

Rejoice,

Bob


----------



## Big Bob (Oct 14, 2007)

> Ok, so far. The difference i wrote to a label was the same in both cases, but: the first case took a lot longer?! Why is that so? I mean that the difference from end - start is the same but the needed time is longer.



Hi Benjamin,

Whenever I try to run timing tests for the KSP, I also get a lot of peculiar results. I have some ideas of why this is so and I'll mention them for what it is worth.

The usual method of trying to measure execution time for something that is very fast is of course to put the thing in a loop and force it to execute a kagillion times. That way you get a measureable time instead of a blink. Then you divide your result by a kagillion and you have an approximation for the execution time (including the looping overhead time). One big problem with this in the KSP is that you can't loop more than 40 or 50 thousand times (I forget the exact limit) without a 'wait' statement or the KSP task-hogging watchdog will terminate the loop.

When you include a 'wait' in the loop the waters get muddied up. A call to 'wait' rarely produces an accurate and consistent amount of time and worse, sometimes it overlaps with the loop body execution time (when there are no other threads waiting for the processor).

Most operations that one would want to time are so fast that 40,000 of them don't add up to 1 ms, so how do you measure their execution time reliably? As soon as you include a 'wait' call in the loop, the measured time for umpteen loop passes seems to be about the time of umpteen 'waits'.

I was thinking of trying to measure the symbolic vs literal constant thing for the KSP but I know from past attempts at making timing measurements that measuring fast things is very hard. When I wrote the Math Library, I did some tests for how fast the KSP could compute a sin/cos pair and even that was a little tricky to get a handle on. Maybe later today I'll try to revisit some of the techniques I came up with then to see if some of them can be applied to the manifest vs literal constant thing. Perhaps by unfolding the 'inner loop body' (with a mile-long list of repeated calculations) so the KSP doesn't count it for more than one loop pass? Part of the problem is that the ENGINE_UPTIME unit is in msec, so you can't get any finer of a resolution.

I will be curious to hear what NI has to say about relative efficiency for symbolic vs literal constants (if the person that responds really knows, that is). I'm almost positive that the very first KSP guide said that symbolic constants were handled more efficiently. But, I notice also that there no longer seems to be any mention of that now. So, either they no longer thought it important or maybe it never was true, etc. 

However, considering the speed of CPUs these days and the fact that the gap between table search and number conversion has clearly closed (and maybe even reversed, especially as symbol table names get longer and longer), it has probably become a mute point. I notice that most discussions of symbolic vs literal constants seem to center on the documentation and maintenence advantages of symbolic constants rather than making any mention of performance differences.

But, please let me know if you discover any evidence one way or the other.

God Bless,

Bob


God Bless,

Bob


----------



## Big Bob (Oct 15, 2007)

Hi All,

I finally have some timing test results comparing the efficiency of symbolic versus literal constants. While not as precise as I would have liked, I think the data is nevertheless generally representative of the real situation.

The bottom-line summary is that it's pretty close to a 'dead heat' with no clear cut edge for either symbolic or literal handling. So my concerns of a possible performance hit, if one were to replace all symbolic constants with literals, would appear not to be an issue as far as the KSP is concerned. Of course for readability and maintenence one would still probably want to use symbolics at the originating source-code level. But, performance wise, apparently it will not matter whether the KR source output of the editor replaces all symbolics with literals.

Since it may be useful in the future for other timing tests, I'll briefly described how I obtained the test results. The script I used for the literal test looked like this:

*on init*
``*declare* ui_button Test
``*declare* ui_button Clear
``*declare* ui_label Info (2,6)
``*declare* *const* X := 123456789
``*declare* *const* Y := 978645312
``*declare* time1
``*declare* time2
``*declare* tally
``*declare* id
``*declare* n
``message('')
*end on*

*on ui_control* (Clear)
``Clear := 0
``set_text(Info,'')
*end on*

*on ui_control* (Test)
``Test := 0
``n := 40000
``id := play_note(60,127,0,0)
``wait(100)
``*while* n > 0
````tally := tally + 123456789 + 123456789 + 978645312 + 978645312 + 123456789 + 978645312
```````````_{ A total of 128 tally lines like this are coded in the loop body }_
````tally := tally + 123456789 + 123456789 + 978645312 + 978645312 + 123456789 + 978645312
````dec(n)
``*end while*
``note_off(id)
``play_note(61,127,0,1000000)
*end on*

I set the K2 options to output the script-generated notes and then connected K2 to MIDI OX's MIDI analyzer. The loop body of the script contained a total of 128 lines just like the two shown above. The first play_note followed by a 100usec pause, allows K2 to send a note-on event to MIDI OX, just before entering the loop body. Because the loop body, repeated 40,000 times then 'hogs' the CPU for around 1.4secs, K2 doesn't actually sound the C3. However, when the loop finally exits, the C#3 sounds for about one second and the note-on is also detected by MIDI-OX's analyzer. By taking the difference between the two time stamps for the C3 and C#3 note-on events, we have a reasonably accurate measure of the time required by K2 to execute the 40000x128 code lines.

I then replaced the 128 lines in the loop body with the following:


```
tally := tally + X + X + Y + Y + X + Y
```

Finally, I replaced the 128 lines again with:


```
tally := tally + X12345678 + X12345678 + Y12345678 + Y12345678 + X12345678 + Y12345678
```

For each of these 3 loop bodies I ran the test 4 times and averaged the measured times. The first loop body was intended to test the time taken to convert a nine-digit ASCII string to a 32-bit signed integer. The 2nd test was to try to measure the time it would take to fetch the pre-determined value of a symbolic constant with a short name. The 3rd test was to measure the time to fetch the value of a symbolic constant with a nine-character name.

The test results were as follows:

9-digit literals 1383 ms
Short symbolics 1376 ms
Long symbolics 1397 ms

The differences are not significant enough to count one way or the other. In all cases the total time was near 1.4 seconds. Perhaps the symbolic case may slow down a little if I were to use a larger script so that there would be a much bigger symbol table to have to search. If so, and assuming that the 'literal' case time probably wouldn't increase, literals might begin to show some advantage.

On the other hand, I don't know how 'optimizing' the KSP interpreter is. It could be that it notices that I have only two different literal strings and it may only convert them once. In that case, replacing the loop body with 6x128 different 9-digit numbers could make quite a difference.

Also because there are only two symbolic constants and two different literal values used, the KSP could well be clever enough to throw their values into a pair of registers and just keep adding and assigning them. If some one wants to take the time to use a lot more symbolic constants and a lot more 9-digit literals, the total execution time could climb considerably. So, I think we have to take the test results being presented here with a fair amount of reservation.

However, at least under these somewhat limited conditions, the KSP still appears to be amazingly fast. Consider that in 1.4 seconds, there are over 5 million code lines being exectued and each line contains 6 additions. Each operand for those additions has to be either fetched or converted (of course we don't know if each one needs to be dealt with individually or if this is done fewer times because of optimizations that may be used). But, if nothing else, the KSP is performing nearly 31 million additions in 1.4 seconds which is about 45 nanoseconds per fetch/convert and add.

Rejoice,

Bob

BTW You may notice there is some unused stuff like time1 and time2. This was left over from when I was trying to use ENGINE_UPTIME to measure the execution time.


----------



## Big Bob (Oct 18, 2007)

Hi Nils,

I think your new code optimization feature is going to provide some very useful functions for configurable Library modules 8) . I don't know if you thought about using it in this way or not but, you may recall a while back we discussed the possibility of adding some kind of conditional compilation capability to your editor? The idea was to allow us to write Library modules with multiple options that could be selected by changing a few compile-time constants. The CC capability provided by NI's pre-processor has the disadvantage of leaving all the unused source code lines in the KR source (thereby clogging up their editor).

I think that your latest additions to the editor will provide just the capability I was wishing for when doing the Math Library. As one example, I provided two SinCos routines. One was shorter but slower and the other faster but longer. I named the faster routine SinCos and the shorter one I named XSinCos. However, for the user to select the shorter routine, the module has to be edited and the SinCos routine replaced by the body of the XSinCos routine. But, with your new optimization stuff, the Library could now be changed to allow the writer of the host script to choose the fast or short version by simply setting the value of a symbolic constant.

In fact, the more I think about it, the more ways I can think of to use this new facility to make Library modules more flexible and friendly. So, in spite of my temporary concern about the relative efficiency of symbolic vs literal constants :oops: , I think this new feature is going to be another wonderful improvement to an already terrific editor o=< . 

God Bless,

Bob

PS Let me know when this new stuff is promoted from 'experimental' to 'solid' and I'll update the Math Library to utilize it.


----------



## polypx (Oct 19, 2007)

Hi Nils,

On a more prosaic note, is there any reason why the Mac version won't accept entry from the ten key pad?

cheers
Dan


----------



## kotori (Oct 19, 2007)

polypx @ Fri Oct 19 said:


> Hi Nils,
> 
> On a more prosaic note, is there any reason why the Mac version won't accept entry from the ten key pad?
> 
> ...



Hi Dan,
Strange - I have no idea really. In fact I have never used the Mac version. Could it be related to the numlock key?

cheers,
Nils


----------



## Big Bob (Oct 19, 2007)

Hi Nils,


> I guess I didn't understand that you were referring to computer architectures without efficient multiplication and division routines. No doubt the difference would be greater if the cost of multiplication would be greater.



Yes, it's a whole different world that thankfully doesn't seem to be very pertinent anymore. Now if only I could 'unlearn' a lot of those old 'tried and true' principles that still seem to stick in my brain :lol: 



> The new stuff will be promoted to 'solid' once I get some reports that people notice no differences between having the optimizations on or off.



One thing I have noticed is that when code is optimized, the resulting code is not compacted, at least insofar as removal of indentation space. I usually run in semi-compacted mode (ie compacted output but not compressed names) so I haven't checked on the effect with names compressed yet. You might want to look into this.



> The SinCos vs. XSinCos selection is actually precisely the kind of thing I thought about when I introduced these updates, although I might have been thinking more of the case where you pass the value as parameter rather than define it as a constant.



By passing a value as a parameter, do you mean something like adding a 4th parameter such as using SinCos(ang,sin,cos,mode) where mode is a compile-time literal specified by the host script when the routine is called? 

If so, of course that would also work but I was thinking more along the lines of a 'global' library mode switch that might affect several routines at once. For example, suppose that the library uses a symbol like* LibraryMode *as a case statement index for several of the library routines (like SinCos, Log, etc). Each such routine might have several variations that make speed/precision or speed/size tradeoffs, etc. The host script then need only define *LibraryMode* as a symbolic constant (which then configures each affected library routine). The host script would not have to edit the calls to SinCos, etc. Only the value of LibraryMode would need to be changed to recompile with increased precision or speed or whatever.

However, maybe you are talking about something totally different than the above and I just didn't pick up on it. :oops: 



> I'm still thinking of enabling the compiler to discard false USE_CODE_IF sections because the compilation would probably go faster if one can remove code in an earlier compilation phase.



Yes indeed, that would also be quite useful. However, I think what you have already provided will go a long way toward providing what was needed along the lines of conditional compilation.

Have a Lovely Day my Friend,

Bob


----------



## Dynamitec (Oct 19, 2007)

> The "Extra syntax checks" setting has to be on for the optimization to have any effect.



Hi Nils,
could you grey out "optimization" if "Extra syntax checks" isn't active? Would be consistent with "compact output" and "compact variables".

Best,
Benjamin


----------



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

Hi Nils,

With the latest build (1.24.4) there is a wee bug with arrays declared in import modules. When they are referenced in the same module as they were declared, the Import module name isn't prefixed to the array name, unless the array is referenced as "%<arrayò6   eož6   eoŸ6   eo 6   eo¡6   eo¢6   eo£6   eo¤6   eo¥6   eo¦6   eo§6   eo¨6   eo©6   eoª7   eo«7   eo¬7   eo­7   eo®7   eo¯7   eo°7   eo±7   eo²7   eo³7   eo´8   eoµ8   eo¶8   eo·


----------



## Big Bob (Nov 5, 2007)

Hi Nils,

Maybe you could take a look at how *pgs keys *are analyzed in the extended syntax checking mode of your editor? There are situations such as declaring a key in one script and referencing it in another (without any declaration) that are accepted by the KSP but rejected by your editor. 

Part of the problem is that it's not clear what K3 allows and doesn't allow becuase their error checking is so primitive. For example, it's not clear whether multiply-defined keys are harmful in any way.

One would think that maybe the safest way to declare a pgs key in a series of scripts would be something like:


```
if not _pgs_key_exists(ABC)
  _pgs_create_key(ABC,10)
end if
```

However, right now, your editor will flag the 'ABC' in the *if clause *if extended syntax checking is turned on. I can work around this by turning off the extended syntax checking but then the new conditional compilation stuff doesn't work and I'm trying to use that :cry: .

Maybe you could somehow relax the extended tests for pgs keys?

Also, if you have anyone's ear at NI, perhaps you could find out what we might need to know about how such things as multiple definitions of keys can be expected to work. For example, what happens if two scripts create a key with the same name? What if one of them declares the key to be longer than the other? etc, etc,

Needless to say that the documentation for the pgs stuff is a bit on the skimpy side and full of obvious errors :roll: 

But in the meantime, maybe you could come up with a quick fix for the extended syntax checking problem?

God Bless,

Bob


----------



## kotori (Nov 5, 2007)

Hi Bob,
I've uploaded a new version which should ignore the first argument of any function starting with "_pgs".

Cheers,
Nils


----------



## Big Bob (Nov 5, 2007)

I think that did the job 8) 

Thanks Nils :mrgreen: 

Bob


----------



## kotori (Nov 5, 2007)

I added another fix - the compact mode is now respected when the experimental code optimization is on. Please download the installation file again (sorry - thought I would be able to fix this before anyone downloaded it).


----------



## Dynamitec (Nov 6, 2007)

Hi Nils!

Thank you! But i have a problem with the KSP Reference (deleted the old folder => reinstalled => doesn't work either). The reference is total messed up. :cry: 

Cheers,
Benjamin


----------



## kotori (Nov 6, 2007)

Hi Benjamin,
Thanks for letting me know. That problem must have been there in the earlier version too though, because I didn't change the reference docs. Anyway, the problem was because of some tab characters in the reference document (one needs to use spaces only for indentation). Fixed now. I replaced the latest installation file, so please download it again.

Cheers,
Nils


----------



## Nickie Fønshauge (Nov 6, 2007)

kotori @ 6th November 2007 said:


> That problem must have been there in the earlier version too though,


It was. I thought it was deliberately "messed up" (=shuffled around)


----------



## Big Bob (Nov 6, 2007)

kotori @ Mon Nov 05 said:


> I added another fix - the compact mode is now respected when the experimental code optimization is on. Please download the installation file again (sorry - thought I would be able to fix this before anyone downloaded it).



Hi Nils,

Thanks for addressing this issue but, unfortunately there is a bit of a problem with it. If you compile the attached SLS source with the 'experimental' or CC mode enabled, it produces at least one error when loaded into K2 (I didn't pursue it any farther). Whereas, if the CC mode is turned off it compiles and loads into K2 OK. Also the prior version 1.24.4 will compile and load this OK with or without the CC mode engaged (however the compiled code will of course not be condensed in CC mode).

I hope this is a minor problem because it would really be super to get the CC mode working with code compaction for larger scripts.

God Bless,

Bob

EDIT: It just occured to me that I may be using confusing terminology. When I have been saying CC mode (by which I mean the Conditional Compilation mode) I am referring to your new 'experimental code optimization' option. Since I see this as the means to effect conditional compilation of library scripts, I have been calling it the CC mode.


----------



## mmosc (Nov 6, 2007)

Bob,

Same problem here

In the meantime with the previous version you can past the CC compiled code in a new window in the editor then compile that with CC turned off. that will get you a compacted CC script.


----------



## kotori (Nov 6, 2007)

Oops - made a stupid mistake in the experimental optimization code related to compacting the code :oops:
Fixed now. Please redownload and run the 1.24.5 installation file.


----------



## kotori (Nov 7, 2007)

I fixed a pair of serious bugs in the experimental code optimization:
* operator precedence not respected for _and_ / _or _/ _not_.
* expressions with multiple operands that evaluated to negative values gave strange results

Please download version 1.24.6 if you plan to use the code optimization. Those who don't need this feature will not need to upgrade.


----------



## Big Bob (Nov 7, 2007)

mmosc @ Tue Nov 06 said:


> Bob,
> 
> Same problem here
> 
> In the meantime with the previous version you can past the CC compiled code in a new window in the editor then compile that with CC turned off. that will get you a compacted CC script.



Good workaround, thanks for the suggestion. I'll mentally 'file it' for future reference :wink: However, V1.24.6 seems to be OK now.


----------



## Big Bob (Nov 7, 2007)

kotori @ Wed Nov 07 said:


> I fixed a pair of serious bugs in the experimental code optimization:
> * operator precedence not respected for _and_ / _or _/ _not_.
> * expressions with multiple operands that evaluated to negative values gave strange results
> 
> Please download version 1.24.6 if you plan to use the code optimization. Those who don't need this feature will not need to upgrade.



Thanks Nils,

All appears to be working now at least superficially. I'll try now to log some serious test time.

God Bless,

Bob


----------



## Big Bob (Nov 7, 2007)

Hi Nils,

Sorry to report that there is still a problem with the 'experimental optimization' or CC feature. Try compiling and running the Legato script (that I posted in this thread) with the CC option off, then repeat with the CC option on. The Legato playing gets all messed up with clicks, pops, and dropouts (for the CC version but not without it). 

Evidentally, the optimization changes the program logic in such a way that the compiled code no longer executes the same way? Please note that the SLS doesn't intentionally 'utilize' any of the CC features but just serves as a sizeable test script.

Before I try to pin point it better, I thought I had better just report the problem. Since the legato script is now pushing 3000 lines of code (in compact code form), it may be slow going. Maybe you can spot something in the area where you made recent changes.

God Bless,

Bob


----------



## mmosc (Nov 7, 2007)

Big Bob @ Wed Nov 07 said:


> Hi Nils,
> 
> Sorry to report that there is still a problem with the 'experimental optimization' or CC feature. Try compiling and running the Legato script (that I posted in this thread) with the CC option off, then repeat with the CC option on. The Legato playing gets all messed up with clicks, pops, and dropouts (for the CC version but not without it).
> 
> ...



Bob,

Does this only happen with the V1.24.6 version or did it also occur with the V1.24.4 version?


----------



## Big Bob (Nov 7, 2007)

Good question Mike, is it the optimization or the compressed optimization?

I'll check it out and report back.

Bob

EDIT: Nils, the same problem exists with V1.24.4 so I guess it's the 'optimization' rather than the compression of the optimization introduced with V1.24.6. Obviously, something about the optimization alters the runtime logic of the code in some way.


----------



## mmosc (Nov 7, 2007)

Thanks Bob, 

Nils

I compiled my 5000 line script with & without optimization with V1.24.4 and compared the output with WinDiff. The optimized logic was ok, however I don't use families or for loops.


----------



## Big Bob (Nov 8, 2007)

Hi Nils,

I'm still trying to pinpoint what is different about the 'optimized' version of the SLS but maybe this will give you a clue. I've noticed that when downward legato intervals are played, if the interval is one semitone, both notes will play (but one will click). For example, playing C4 then B3 (overlapping), B3 will sound with a click at the start. However, if you play an interval bigger than one semitone the 2nd note will not sound at all. For example, playing B3,A3 the A3 won't sound.

On the other hand, playing up intervals seems to work for any interval but there is still clicking. Needless to say, the non-optimized version of the same script works fine and exhibits none of these problems.

Since you mentioned finding at least one problem with improper evaluation of negative numbers perhaps there are more?

Meanwhile, as time and health permit, I'll try to pursue this symptom by walking through the SLS logic and comparing 'optimized' vs non-optimized KR code. Please let me know if you can't repro this problem for some reason because it happens very solidly here and is highly repeatable.

God Bless,

Bob


----------



## kotori (Nov 9, 2007)

Hi Bob,
Optimization consists of simplifying expressions and removing unused code branches. I have verified that there's nothing wrong with the latter, so there must be something wrong with how the expressions are evaluated. The problem is consistently repeatable on my computer as well.

I attach a list of all simplifications performed by the script. I have skimmed through it but although I didn't see anything apparently wrong I might have missed something. This is the new operator precedence order (from lowest to highest precedence and those with the same precedence on the same line):
:=
&
or
and
not
=, #, <, >, <=, >=
.and., .or.
.not.
+, -
*, /, mod
- (unary)
.
Can anyone spot anything wrong? The operator precedence controls how expressions are parenthesised when the parse tree is translated back to code.

Nils


----------



## kotori (Nov 9, 2007)

I found and fixed the problem. I advice everyone who wants to use the optimization (still experimental though) to 
:arrow: download version 1.24.7.

The problem was an error in the translation of expressions involving unary minus to code which caused necessary parenthesis to be left out in some cases. It was actually not a problem related to the optimizations themselves but rather related to how the AST is translated back into code.

Cheers,
Nils


----------



## Big Bob (Nov 9, 2007)

Thanks a million Nils, I'm sure glad you nailed this one o-[][]-o 

Just out of curiosity, can you point me to a line number in the SLS (after compilation) that was affected? When I got up this morning I was going to continue tracking down the negative interval problem (but not looking forward to it :lol: ). I was so glad when I read your 'I found it' post o=< .

Again thanks for a quick resolution. I'll continue using the CC code under fire and let you know if anything else crops up but it seems to be pretty close to 'solid' now. (I wish K2/K3 was as solid).

God Bless,

Bob


----------



## kotori (Nov 9, 2007)

Hi Bob,
I believe the problematic line was this: _NewTune := -(bend_step*bend_ticks + 500)/1000_

Btw. if we after some further testing find this code optimization to be stable it might make it possible for me to reorganize the compilation and perhaps cut the compilation time down by more than 50%. Currently the code is more or less compiled twice when optimization or extra syntax checks is on. The latter compilation phase is not yet capable of translating the extended syntax into standard ksp syntax so it needs the help of the first one, but if I were to add that the older first phase could be skipped. It would take some time to implement it though.

Cheers,
Nils


----------



## Big Bob (Nov 9, 2007)

> I believe the problematic line was this: NewTune := -(bend_step*bend_ticks + 500)/1000



Ah yes! That would account for the way things were behaving. Again, I'm glad you nailed it from your end, saved me a lot of work chasing it symptomtically :D .



> Btw. if we after some further testing find this code optimization to be stable it might make it possible for me to reorganize the compilation and perhaps cut the compilation time down by more than 50%. Currently the code is more or less compiled twice when optimization or extra syntax checks is on. The latter compilation phase is not yet capable of translating the extended syntax into standard ksp syntax so it needs the help of the first one, but if I were to add that the older first phase could be skipped. It would take some time to implement it though.



The most important issue for me is a high confidence level that optimized compilations will behave identically with those made without optimization. If it's a lot of work to speed things up or, if making the changes might result in reducing confidence level (until further extensive testing), the gain may not be worth the cost. I guess what I'm saying is while speeding up the compilation process would be nice, the way it works now is quite acceptable for me.

On the other hand, if you want to 'clean things up' this would probably be a good time for me because I'm working on a new Library module that will take advantage of the new CC features. So, I expect to give everything a thorough 'shakedown' cruise in the upcoming weeks (health permitting). :wink: 

God Bless,

Bob

BTW My medical 'reboot' is scheduled for Nov 28 so I've got a little time to get used to the idea again. :shock:


----------



## Big Bob (Nov 10, 2007)

Hi Nils,

I just discovered that there is a problem with hexadecimal input values above 7FFFFFFF. Your editor converts a number like FFFFFFFF to its positive decimal equivalent (4294967295) whereas for Kontakt's benefit we need to convert numbers above 7FFFFFFF to their negative equivalent (when viewed as a 2's complement number). Thus FFFFFFFF should be converted to -1 and not 4294967295.

So, if hex number input exceeds 7FFFFFFF, convert it as now but then subtract 4294967296 to get the negative number that Kontakt wants.

The example I bumped into was an input of 0xFFFFFFF0 which your editor converted to 4294967280. This actually needs to be -16 for Kontakt's benefit.

I think this problem has probably been with us for a long time but maybe no one has used a hex number above 7FFFFFFF before now.

God Bless,

Bob


----------



## kotori (Nov 11, 2007)

Hi Bob,

Thanks for the error report. Fixed now. Please redownload the V1.24.7 installation.
It seems that in KSP the following will unintuitively present a pair of different numbers: message(2147483648 & ", " & 2147483647+1).

If you compile the same code with code optimization activated you will get a pair of identical numbers. With optimization mode on any large number will be converted to 32-bit in the same way an overflow in a mathematical expression is converted to 32-bit (the expression to the right in the example above). When the optimization is off hex numbers (but not decimal numbers) wò²   f}¥²   f}¦²   f}§²   f}¨²   f}©²   f}ª²   f}«²   f


----------



## Nickie Fønshauge (Nov 11, 2007)

Hi Nils,

There is a problem with the syntax checker. It doesn't like the Danish letter "ø" in strings.


----------



## Big Bob (Nov 11, 2007)

kotori @ Sun Nov 11 said:


> Hi Bob,
> 
> Thanks for the error report. Fixed now. Please redownload the V1.24.7 installation.
> It seems that in KSP the following will unintuitively present a pair of different numbers: message(2147483648 & ", " & 2147483647+1).
> ...



Hi Nils,

The updated V1.24.7 Editor produces all sorts of error messages. Try compiling the following with the first V1.24.7 and then with the current version.

*on init*
``*declare* *const* SubTag := 0xA0
``*declare* *const* ThisSlot := 3
``*declare* ui_button Test
``*declare* Tag
*end on*

*on ui_control* (Test)
``Test := 0
``Tag := SubTag + ThisSlot
``TestHex
*end on*


*function* TestHex
``*if* Tag .*and*. 0xFFFFFFF0 = SubTag
````message('Mask OK')
``*else*
````message('Mask Not OK')
``*end if*
*end function*

*function* CallHandler(fn)
``_{ Not Yet }_
*end function*



I have also now discovered that K2 and K3 handle positive literals (greater than 7FFFFFFF) differently :x For example, with K2, *message(4294967280) *displays as -16 which is the 2's complement equivalent. In K3, evidentally each literal is 'clamped' to 2,147,483,647 before combining with other values in an expression and so *message(4294967280) * displays as 2147483647.


----------



## kotori (Nov 11, 2007)

:arrow: New version: V1.24.8

Bob, I had some bad luck and misplaced a parenthesis and then mistakingly tested using my already installed version of the editor instead of the modified one. Fixed now. Sorry for the inconvenience. 



Nickie Fønshauge @ Sun Nov 11 said:


> There is a problem with the syntax checker. It doesn't like the Danish letter "ø" in strings.


Thanks for letting me know. The syntax check mode didn't fully support extended characters. Fixed now.



Dynamitec @ Sat Oct 20 said:


> could you grey out "optimization" if "Extra syntax checks" isn't active? Would be consistent with "compact output" and "compact variables".


Took the opportunity of adding this in this version.


----------



## Big Bob (Nov 11, 2007)

Looks like that did the job :D 

Thanks Nils

Bob


----------



## dezzo (Nov 14, 2007)

Hi,

I´m new here. Just got started learning KSP ! 
The KScript Editor runs verry slow here on my intel macbook (OSX 10.5 ! )
When do you release a Version for Intel/Leo ?

Greetings,

D


----------



## kotori (Nov 15, 2007)

Bob, I updated the code optimization so that true if statements are replaced with the body of the statement as long as the condition is not 1=1. Please redownload and install V1.24.8.



dezzo @ Thu Nov 15 said:


> Hi,
> 
> I´m new here. Just got started learning KSP !
> The KScript Editor runs verry slow here on my intel macbook (OSX 10.5 ! )
> When do you release a Version for Intel/Leo ?


Hi dezzo,
As a starting step you could try to deactivate Antialiasing and maybe also "Folding and Extended Syntax Highlighting" in the Settings menu and see if that does the trick. Please let me know if you still find it slow then. 

Greetings,
Nils


----------



## Big Bob (Nov 15, 2007)

> Bob, I updated the code optimization so that true if statements are replaced with the body of the statement as long as the condition is not 1=1. Please redownload and install V1.24.8.



Terrific! Thanks a million Nils for the super fast service o=< 

I'm sure it will be much easier to avoid 1=1 than it has been to do without the *if-else *construct entirely. Thanks again my friend :D .

God Bless,

Bob


----------



## dezzo (Nov 15, 2007)

Hi Nils,

thx , it works better now ( deactivated Antialiasing ) . 
I can definitely say that it runs much faster on the PPC ( G5 2x 2.0 GHz/ no intel ).
It´s like a delay which occours when typing in all the letters .

D


----------



## Big Bob (Nov 17, 2007)

Hi Nils,

I just ran into kind of a strange KScript Editor problem. Try compiling the following:

*on init*
``on_init_LibNames
*end on*

*function* on_init_LibNames
```````````_{ Common Library Subroutines and their Call formats }_
``_{ -1 }_ *declare* *const*```ATFade := -1``_{ Call(ATFade,lip2(cv,rng),lop(atn)) }_
``_{ -2 }_ *declare* *const*``FSinCos := -2``_{ Call(FSinCos,lip(ang),lop2(sin,cos)) }_
``_{ -3 }_ *declare* *const* FTangent := -3``_{ Call(FTangent,lip(ang),lop(tan)) }_
``_{ -4 }_ *declare* *const*```Get_db := -4``_{ Call(Get_db,lip(r),lop(Atn)) }_
``_{ -5 }_ *declare* *const*```````Ln := -5``_{ Call(Ln,lip(X),lop(lnx)) }_
``_{ -6 }_ *declare* *const*`````Log2 := -6``_{ Call(Log2,lip(X),lop(lgx)) }_
``_{ -7 }_ *declare* *const*````Log10 := -7``_{ Call(Log10,lip(X),lop(logx)) }_
``_{ -8 }_ *declare* *const*```SinCos := -8``_{ Call(SinCos,lip(ang),lop2(sin,cos)) }_
``_{ -9 }_ *declare* *const*``Tangent := -9``_{ Call(Tangent,lip(ang),lop(tan)) }_
````_{ Other Library Constants }_
``*declare* *const* Ang90 := 1000
``*declare* *const* Muted := -100000
*end function* _{ on_init_LibNames }_

However, the same thing without the leading comments on the declare lines compiles fine:

*on init*
``on_init_LibNames
*end on*

*function* on_init_LibNames
```````````_{ Common Library Subroutines and their Call formats }_
``*declare* *const*```ATFade := -1``_{ Call(ATFade,lip2(cv,rng),lop(atn)) }_
``*declare* *const*``FSinCos := -2``_{ Call(FSinCos,lip(ang),lop2(sin,cos)) }_
``*declare* *const* FTangent := -3``_{ Call(FTangent,lip(ang),lop(tan)) }_
``*declare* *const*```Get_db := -4``_{ Call(Get_db,lip(r),lop(Atn)) }_
``*declare* *const*```````Ln := -5``_{ Call(Ln,lip(X),lop(lnx)) }_
``*declare* *const*`````Log2 := -6``_{ Call(Log2,lip(X),lop(lgx)) }_
``*declare* *const*````Log10 := -7``_{ Call(Log10,lip(X),lop(logx)) }_
``*declare* *const*```SinCos := -8``_{ Call(SinCos,lip(ang),lop2(sin,cos)) }_
``*declare* *const*``Tangent := -9``_{ Call(Tangent,lip(ang),lop(tan)) }_
````_{ Other Library Constants }_
``*declare* *const* Ang90 := 1000
``*declare* *const* Muted := -100000
*end function* _{ on_init_LibNames }_

Evidentally we cannot begin a declarative line with a comment? It may have always been this way but apparently I've never ran into before now :o . Would this be something easy to fix?

God Bless,

Bob


----------



## kotori (Nov 18, 2007)

Hi Bob,
Yes, it has been like that for a long time. I don't see any important benefits in adding support for internal or leading comments on declaration lines so I think I'll keep it as is. The reason is that the compiler currently uses regular expressions to recognize the syntax and the code gets less clear if I allow comments in unusual places. This wouldn't be a problem if I could just discard all comments, but the current compiler strives to keep them in the final output.

/Nils


----------



## Big Bob (Nov 18, 2007)

Hi Nils,

I agree that there are really very few situations where leading comments are useful (this may well have been the first time I tried to use something like this). And, it's not a big problem to avoid them but I just thought I'd ask in case it was something easy to change. 

BTW: The new SMS Common Library module I'm putting together uses a lot of your new code optimization stuff (conditional compilation) to great advantage. It's really going to make library construction a whole lot friendlier, thanks for adding this stuff o=< . 

God Bless,

Bob


----------



## Big Bob (Nov 21, 2007)

Hi Nils,

This may be a better example to illustrate the problem I'm having with the conditional compilation feature of the editor.

_{--------------------------- Example #1 -------------------------}_
*on init*
``*declare* X
``*declare* Y
*end on*

*on note*
``Foo_V10
*end on*

*function* Foo_V10
``*declare* A
``*declare* B
``X := 1+Y
*end function*

*function* Foo_V20
``*declare* E
``*declare* F
``X := 3+Y
*end function*
_{-------------------------- Compilation #1 ----------------------}_
*on init*
*declare* $X````_{ Note that local vars E and F are not declared }_
*declare* $Y````_{ Because the code doesn't reference Foo_V20 }_
*declare* $_A
*declare* $_B
*end on*

*on note*
$X := 1+$Y````_{ Of course only Foo_V10 is expanded in the NCB }_
*end on*
_{-------------------------- Example #2 --------------------------}_
*on init*
``*declare* X
``*declare* Y
*end on*

*on note*
``Foo(10)
*end on*

*function* Foo_V10
``*declare* A
``*declare* B
``X := 1+Y
*end function*

*function* Foo_V20
``*declare* E
``*declare* F
``X := 3+Y
*end function*

*function* Foo(V)
``*if* V = 10
````Foo_V10
``*else*
````Foo_V20
``*end if*
*end function*
_{-------------------------- Compilation #2 ----------------------}_
*on init*
*declare* $X
*declare* $Y
*declare* $_E``_{ Note that local vars E and F are now declared }_
*declare* $_F``_{ Even though Foo_V20 is not invoked }_
*declare* $_A
*declare* $_B
*end on*

*on note*
$X := 1+$Y``_{Only Foo_V10 is expanded in the NCB, same as Example #1 }_
*end on*
_{--------------------------- Example #3 ------------------------}_
*on init*
``*declare* X
``*declare* Y
``Foo(10)
*end on*

*function* Foo_V10
``*declare* A
``*declare* B
``X := 1+Y
*end function*

*function* Foo_V20
``*declare* E
``*declare* F
``X := 3+Y
*end function*

*function* Foo(V)
``*if* V = 10
````Foo_V10
``*else*
````Foo_V20
``*end if*
*end function*
_{-------------------------- Compilation #3 ----------------------}_
*on init*
*declare* $X```_{ Note that local vars E and F are not declared }_
*declare* $Y```_{ When Foo(10) is invoked from ICB rather than NCB }_
*declare* $_A
*declare* $_B
$X := 1+$Y
*end on*

Is there a way to remove declaratives made in functions that are eliminated by the conditional compilation? Since these declares are not needed, it represents wasted code space, no?

God Bless,

Bob


----------



## Big Bob (Nov 25, 2007)

Hi Nils,

Since you haven't commented yet, I'm bumping this up in case you didn't notice my last two posts.

Thanks,

Bob


----------



## kotori (Nov 25, 2007)

Thanks for the reminder Bob. I thought I'd just go ahead and fix it and then respond, but then I didn't get time. Have been busy working on a trumpet script actually.  
I'll try to fix it as soon as I get time though.

Cheers,
Nils


----------



## Big Bob (Nov 25, 2007)

Thanks for the feedback Nils. No hurry because the 28th (my big Heart Reboot day :( ) is fast approaching and I'll have to get emotionally prepared for that pretty soon now :lol: . I just wanted to make sure you saw my posts.

God Bless,

Bob


----------



## kotori (Dec 2, 2007)

Hi everyone,
Thought I'd bump this thread and add the info that I uploaded version 1.24.9 of the editor that fixes a couple of problems with K3 functions and variables not being recognized properly. 

Cheers,
Nils


----------



## Big Bob (Dec 3, 2007)

Hi Nils,

Does this update do anything about the conditional compilation, local var declaration stuff? I haven't gotten around to installing and testing it yet but if it doesn't correct the CC stuff, maybe I'll wait until I'm feeling better.

God Bless,

Bob


----------



## kotori (Dec 3, 2007)

Big Bob @ Mon Dec 03 said:


> Hi Nils,
> 
> Does this update do anything about the conditional compilation, local var declaration stuff? I haven't gotten around to installing and testing it yet but if it doesn't correct the CC stuff, maybe I'll wait until I'm feeling better.
> 
> ...



Hi Bob,
No that's not implemented yet.

/Nils


----------



## Big Bob (Dec 7, 2007)

kotori @ Mon Dec 03 said:


> Big Bob @ Mon Dec 03 said:
> 
> 
> > Hi Nils,
> ...



Hi Nils,

Since I seem to be getting more energy each day, I'm planning resumption of my project that relies on the CC features of your editor. Do you have any idea when we might expect the 'declare' problems to be corrected? My work-arounds are a little messy so if I knew that a fix was imminent, I'd probably do things in a different order. I'm not trying to pressure you though so, if you have no idea when you might get to this, I'll continue using my work-arounds 

God Bless you my friend,

Bob


----------



## kotori (Dec 8, 2007)

I uploaded KScript Editor V1.25

Changes:
When the optimization mode is on declarations of variables that are only used in code blocks that never execute are removed.


----------



## Big Bob (Dec 8, 2007)

Fantastic o=<

I was hoping you were going to say that this fix was coming soon but I never expected it immediately :o . What a lovely 'post-reboot' present :D 

Thanks a million my friend,

God Bless,

Bob


----------



## kotori (Dec 18, 2007)

Hello everyone,

I noticed that a demo video of the trumpet I've been writing scripts for lately and that I mentioned above has been released. So if anyone wonders what I've been up to this is it. o=< 
I have implemented the major part of the script, namely sound shaping/modulation based on Giorgio Tommasini's research and specifications. The portamento code was written by Josef Natterer, and Giorgio also implemented some parts of the code himself and was overall actively involved in the script implementation.

Feel free to check it out. I'll refer any comments or questions about the instrument itself to the thread above.

Cheers,
Nils


----------



## Dynamitec (Dec 18, 2007)

Impressive! I'm really wondering how much you now know about Giorgio Tommasini's research


----------



## kotori (Dec 19, 2007)

Dynamitec @ Wed Dec 19 said:


> Impressive! I'm really wondering how much you now know about Giorgio Tommasini's research


I don't know how the harmonic alignment is done, but naturally I've gained some insights in the physical behaviour of the trumpet thanks to Giorgio's analysis.


----------



## Dynamitec (Dec 19, 2007)

I wonder if this harmonic alignment will ever be a mystery 

But anyway: great work, Nils!

Cheers,
Benjamin


----------



## gregjazz (Dec 21, 2007)

Quick question. First of all, I'm starting using KScript (and KSP in general), and it's very awesome! Very convenient, and the interface feels really good.

What's the fastest way to delete all the text within the Kontakt script editor in order to paste the compiled text from KScript? I'm sure there's a faster way to do it than how I'm currently doing it.


----------



## Nickie Fønshauge (Dec 21, 2007)

gregjazz @ 21st December 2007 said:


> Quick question. First of all, I'm starting using KScript (and KSP in general), and it's very awesome! Very convenient, and the interface feels really good.
> 
> What's the fastest way to delete all the text within the Kontakt script editor in order to paste the compiled text from KScript? I'm sure there's a faster way to do it than how I'm currently doing it.


CTRL+A plus CTRL+V. I don't think there is a faster way.


----------



## gregjazz (Dec 21, 2007)

Ahah, CTRL+A, forgot about that one. I was selecting all the text by hand, which was the time-taker. Thanks Nickie!


----------



## Big Bob (Dec 27, 2007)

Hi Nils,

Since you haven'ty responded, I'm wondering if you missed my previous post to this thread?

God Bless,

Bob


----------



## kotori (Dec 27, 2007)

Big Bob @ Fri Dec 28 said:


> Hi Nils,
> Since you haven'ty responded, I'm wondering if you missed my previous post to this thread?
> 
> God Bless,
> Bob


Hi Bob,
I just read it now. I'm away from home until New Year so I'm not following the forum threads as closely as I use to. There's obviously something wrong going on there. I'll try to fix it as soon as possible when return. In the meanwhile I guess it might be in order to recommend using the optimization mode with care.

Cheers,
Nils



gregjazz @ Fri Dec 21 said:


> Ahah, CTRL+A, forgot about that one. I was selecting all the text by hand, which was the time-taker. Thanks Nickie!



Hi Greg, Good to see that you find my editor useful. I see that Nickie already provided you with an answer, but I just thought I'd note that some stuff like this is also covered by my script tutorial.


----------



## kotori (Jan 4, 2008)

I uploaded V1.25.1 of the script editor. 

Changes:
* _Fixed a bug in the optional code optimization which caused if-statements with an empty else clause to be completely removed from the compiled code._


----------



## Big Bob (Jan 4, 2008)

Hi Nils,

Welcome back, thanks for the fix, and Happy New Year o=< .

Bob


----------



## gregjazz (Jan 4, 2008)

kotori @ Thu Dec 27 said:


> Hi Greg, Good to see that you find my editor useful. I see that Nickie already provided you with an answer, but I just thought I'd note that some stuff like this is also covered by my script tutorial.



Ahah, although I've already read your tutorial, it appears that I skipped over that part.

Thanks for all the work you've put into this community; your tutorials, the editor, etc.

Right now I'm just trying to wrap my brain around the quirks of how Kontakt handles callbacks, etc.


----------



## gregjazz (Jan 5, 2008)

Quick question. If I copy text in the KScript editor that uses the ` character, it gets replaced with a blank space. Not a big issue at all, just wondering if this is true, or if it's a weird windows issue.


----------



## kotori (Jan 6, 2008)

gregjazz @ Sun Jan 06 said:


> Quick question. If I copy text in the KScript editor that uses the ` character, it gets replaced with a blank space. Not a big issue at all, just wondering if this is true, or if it's a weird windows issue.



The editor has an option in the Edit menu called "Copy as BBCode" which makes it possible to post script snippets with syntax highlighting on forums. In order to make that work I converted spaces to ` characters (a character visually close to whitespace that I assumed was not being used very often) and set the forground color to white. To make it possible for people to copy and paste such syntax highlighted code back into the editor I automatically replace ` with space.

I suppose I could make the translation optional, but I'm not sure it's worth it. If this is a problem to you, a workaround might be to paste code using another text editor and then open the file in the KScript Editor.


----------



## Big Bob (Jan 8, 2008)

Hi Nils,

If it's not too difficult to implement, I think that some kind of 'macro' expression expander could be very useful for making KS source code even more readable. As an example:


```
macro Old
  1 - np.New
end macro
```

This would then allow one to write


```
if np.parent[Old] = 1
    { Do Something }
  end if
```

Instead of:

```
if np.parent[1 - New] = 1
    { Do Something }
  end if
```

Needless to say the foregoing is only a trivial example but, I think it illustrates the idea of what I'm shooting for. What do you think of this general idea?

God Bless,

Bob


----------



## Dynamitec (Jan 9, 2008)

Hi everyone!

I vote for the macro expression expander, too! And Nils...some inline / pre-compile / macro functions would be sooo cool  8) 

Something OT:

If you are interested in my latest KSP work, take a look at the vir2.com website (http://www.vir2.com): vir2 syntAX, vir2 Elite Orchestral Percussion and vir2 BASiS are powered by my scripting work. Altough the interface may look simple on the first look (it's supposed to be that way!), there is very much scripting work going on in the background!

I want to say thank you to Nils for his great Editor (i visit PayPal again soon! I'll promise!) and Big Bob for his Math Library which is one of the most important additions to KSP 

Best,
Benjamin


----------



## Dynamitec (Jan 12, 2008)

Hi Nils,

on my new script the code optimizing produces very strange results. I do a formant correct pitchbending for example. Without optimization it sounds correct, with optimization it jumps from on note to the next. I can't localize the problem right now (deadline), but as far as i found out your optimizer removes to much brackets.

Eg: ((x/100)*100)/100

is x/100*100/100 for example.

which is of course correct, but could it be that, it produces roundoff errors?

Cheers,
Benjamin


----------



## kotori (Jan 12, 2008)

Hi Benjamin,

I believe ((x/100)*100)/100 is always equal to x/100*100/100 assuming rounding is done in either both cases or neither of them. The same should apply to overflows. I would guess that the error is something else. When you find time again, please let me know and I may be able to provide some assistance in finding the error. I realize that showing me the source code may not be an option, but I could provide you with some tools and ideas about how to proceed.

In the meantime it might be in order to advise agaiòû   l(.û   l(/û   l(0û   l(1û   l(2û   l(3û   l(4û   l(5û   l(6û   l(7û   l(8û   l(9û   lû   l(;û   l(<û   l(=û   l(>û   l(?û   l(@û   l(Aû   l(Bû   l(Cû   l(Dû   l


----------



## Big Bob (Jan 12, 2008)

> So: great feature Nils! Thanks a lot again!



I'll sure second that!! It not only will be super when this feature changes from 'experimental' to 'rock solid', but, I'm abaolutely counting on it :!: It not only shrinks the compiled size of large scripts but it makes library construction so much more adaptable.

My newest Interscript Operating System for K3 uses so many of the new optimization features that I would hate to think of the mess I would be in if this feature wasn't available :cry: .

I'm glad to see that Benjamin caught another small glitch and it's probably yet different from the one that you just mentioned Nils. I haven't personally run into any more problems since the last ones that I reported and I've been using your editor a lot lately and always with the code optimization feature turned on. But, I tend to be mostly working on the same 'expanding' stuff so we need broader testing coverage. However, you must be getting very close to having this thing pretty solid.

Is anyone else excercising this feature? If not you should because it's a great addition to the KScript Editor and Nils needs more of us 'Monkeys banging on our keyboards' trying to find bugs :lol: 

God Bless,

Bob


----------



## Dynamitec (Jan 13, 2008)

Hi Nils,
could it be that you changed something else? My persistent variables aren't transfered correctly between a optimized and unoptimized script. Yesterday i had no problems (or did i do something wrong yesterday?)

Any idea?
Benjamin


----------



## gmet (Jan 13, 2008)

Nils,

I have a script with the following line:

declare ui_button $Random2

but with optimize code it removes this line from the script.

Justin


----------



## Thonex (Jan 13, 2008)

Big Bob @ Sat Jan 12 said:


> Is anyone else excercising this feature? If not you should because it's a great addition to the KScript Editor and Nils needs more of us 'Monkeys banging on our keyboards' trying to find bugs :lol:



No... but I will if it will "help the cause". :D 

It's just that some of Nils's features seem like they may be over my head... >8o ...then again... that's what I thought about functions and now I can't think about not using them. o-[][]-o 

I've sort of been swamped... is there a thread that details this feature?

Thanks for all your great work Nils. 

T


----------



## Big Bob (Jan 13, 2008)

> I've sort of been swamped... is there a thread that details this feature?


Hi Andrew,

Thanks for your willingness to get involved. You are in the thread where this new feature is discussed. I think it starts around the 14th post on page 2, Unfortunately, there are a lot of other topics interspersed so you will just have to start at 2-14 and skim forward selectively :lol: 

God Bless,

Bob



> Previously I used the first type of condition in all three cases, but since all binary operators are left associative I think this should work better. I also think that any integer overflows that happen in nonoptimized code should now also happen in optimized code, *which is probably a good thing*.



A very good thing, I think :wink:


----------



## kotori (Jan 13, 2008)

Justin M @ Sun Jan 13 said:


> declare ui_button $Random2
> but with optimize code it removes this line from the script.



Hi Justin, did you use $Random2 anywhere else in the code? Varibles that are declared but never used are automatically removed when optimization is on.



Dynamitec @ Sun Jan 13 said:


> Hi Nils,
> could it be that you changed something else? My persistent variables aren't transfered correctly between a optimized and unoptimized script. Yesterday i had no problems (or did i do something wrong yesterday?)
> 
> Any idea?
> Benjamin



I haven't really changed anything that should affect that in this latest update. Do you think you can find a minimal example illustrating the problem? Btw. make_persistent($x) marks $x as used so in theory persistent variables should never be removed.



Thonex @ Sun Jan 13 said:


> I've sort of been swamped... is there a thread that details this feature?


In short the code optimizer replaces any expressions that it can with a calculated value (eg. 4*4*x is replaced by 16*x), it removes if/while/select clauses that it determines will never be executed anyway (eg. if 5=7 ... will be removed), and it then does an extra check for unused variables and removes their declarations.

Nils


----------



## Thonex (Jan 13, 2008)

kotori @ Mon Jan 14 said:


> In short the code optimizer replaces any expressions that it can with a calculated value (eg. 4*4*x is replaced by 16*x), it removes if/while/select clauses that it determines will never be executed anyway (eg. if 5=7 ... will be removed), and it then does an extra check for unused variables and removes their declarations.
> 
> Nils



Brilliant!!! Thanks Nils.

I'll download the latest/greatest editor this week and I'm sure your optimizer will "catch" some of my variables that never got used :lol: 

Thanks again for all your doing Nils... time to visit that Pay Pal Donation again.

Cheers,

T


----------



## gmet (Jan 14, 2008)

kotori @ 14th January 2008 said:


> Justin M @ Sun Jan 13 said:
> 
> 
> > declare ui_button $Random2
> ...



Thanks for the reply Nils, yes I do use it elsewhere in the code as when I come to apply it in Kontakt I get the message that the variable has not been declared (because it has been removed). Here is a short version of the bit of the script:


> *on init*
> ``*declare* ui_button $Random2
> ``$random2 := $Off
> ``make_persistent($random2)
> ...



Justin


----------



## kotori (Jan 14, 2008)

Hi Justin,
By accident I had made the code optimizer case sensitive. Since you declared the variable as $Random2 and consistently used it in the form of $random2 the uses were not properly detected. I have fixed this now and uploaded a new version. It's not impossible that the problem Benjamin spoke about - but I haven't been able to reproduce - will make me issue another update soon, so those who don't use the optimizer much might want to hold off upgrading at this point.

Nils


----------



## Dynamitec (Jan 14, 2008)

Hi Nils,

no, no! False alarm! Since i did turn of code compacting to find the bug in the optimizer i simple forgot to turn it on again! So it was my fault! It's working great now!

Thanks!
Benjamin


----------



## Dynamitec (Jan 14, 2008)

I found a very little "bug": on ui_update isn't highlighted correctly...


----------



## kotori (Jan 14, 2008)

Dynamitec @ Mon Jan 14 said:


> Hi Nils,
> 
> no, no! False alarm! Since i did turn of code compacting to find the bug in the optimizer i simple forgot to turn it on again! So it was my fault! It's working great now!



Ok, great. The earlier link wasn't very prominent so if anyone missed it, please upgrade to :arrow: *version 1.25.3 of KScript Editor*.

Benjamin, "on ui_update" is properly highlighted on my computer. If you have customized your styles.ini file you may have to add it to the keywords section of this file.

Cheers,
Nils


----------



## gmet (Jan 14, 2008)

Thanks Nils - that fixed it! No other problems when compiling my other scripts - but mine are no where near as complexed as Bobs and Benjamins!!

Justin


----------



## Big Bob (Jan 29, 2008)

Hi Nils,

Just in case you are looking for something to do :lol: 

The KScript Editor won't take the following if Extra syntax checking is on.

*on init*
``*declare* *const* $NoteMark := $MARK_26``_{ Mark for new notes prior to zero crossing sync }_
``*declare* *const* $SyncMark := $MARK_27``_{ Mark for all synchronized notes }_
``*declare* *const* $SyncID := by_marks($SyncMark)
``*declare* *const* $NoSyncID := by_marks($NoteMark)
*end on*

However, the above can be pasted directly into the KSP and it will take it.

If I change the code to the following functional equivalent, then the editor (and afterward K2) will take it.

*on init*
``*declare* *const* $NoteMark := $MARK_26``_{ Mark for new notes prior to zero crossing sync }_
``*declare* *const* $SyncMark := $MARK_27``_{ Mark for all synchronized notes }_
``*declare* *const* $SyncID := $SyncMark .*or*. 0x80000000
``*declare* *const* $NoSyncID := $NoteMark .*or*. 0x80000000
*end on*

Evidentally, you haven't included the by_marks operation yet?

Have a great day my friend.

God Bless,

Bob


----------



## kotori (Feb 4, 2008)

*Version 1.25.4* is now available (and has been for some days actually). Not too much new but Big Bob uses the new feature so if you plan on compiling SIPS you will need the latest version.

_Changes_
* It is now possible to use by_marks in constant expressions (eg. in assignments to variables on the line of declaration)

_In other news_
KScript Editor gets its first music magazine coverage in the Electronic Musician article "Master Class: Scripting in Kontakt 3" (available online).
http://www.scarbee.com/products/black_bass/ (Scarbee Black Bass), which I wrote the script for, is reviewed in the same edition of EM. I have not yet read it myself, but a forum user kindly summarized it: 
*The Black Bass received the EM Hot Pick award and the overall Value rating was a 5! :D
The article said, "Black Bass is one of the most realistic, expressive, and easy-to-use sampled instruments I have ever played. 
If you are a Kontakt user looking for an authentic and fun-to-use virtual bass. I highly recommed that you give it a try."*


----------



## Thonex (Feb 4, 2008)

kotori @ Mon Feb 04 said:


> *Version 1.25.4* is now available (and has been for some days actually). Not too much new but Big Bob uses the new feature so if you plan on compiling SIPS you will need the latest version.
> 
> _Changes_
> * It is now possible to use by_marks in constant expressions (eg. in assignments to variables on the line of declaration)
> ...



Awesome!!!!

And congratulations for the great Black Bass review!!!! :D o-[][]-o o=< 

Thanks for all you do for this community Nils!!


Cheers,

T


----------



## mmosc (Feb 4, 2008)

Nils,

When is the version that actually writes the scripts for us comming out? :mrgreen: 

I'm completing the second generation of scripts for the Garritan libraries that I don't think would have been possible or at least not managable without your editor

Thanks again for a great tool.


----------



## gmet (Feb 5, 2008)

Thanks again Nils & congratulations at finally getting some public recognition for all your work.

Justin


----------



## kotori (Feb 5, 2008)

Andrew, Mike and Justin, thanks a lot! :D


----------



## Nickie Fønshauge (Feb 5, 2008)

Congratulations with the plug, Nils. It's well deserved. I still think NI ought to give you the same kind of recognition, considering what your editor has done to promote K2/3. An official purchase wouldn't be unreasonable


----------



## Tod (Feb 5, 2008)

Yes Nils, Congratulations!! It's hard to imagine working on scripts without your editor.

Thankyou so much. :D 

Tod


----------



## Mike Greene (Feb 5, 2008)

Tod @ Tue Feb 05 said:


> It's hard to imagine working on scripts without your editor.


That's for sure!

Nils' editor obviously saves lots of time and headache in the straight ahead _writing_ of scripts. But I also think that his editor keeps me from making as many mistakes as I would make if I couldn't define functions, etc. Being able to define functions, the built in color coding and auto-indents, and all those niceties make the scripts so much easier to read that I'm less prone to make mistakes . . . and even when inevitable mistakes are made, troubleshooting is soooo much easier.

I'm sure this editor has saved me several _days_ (no exaggeration!) of work altogether in making my vocal library, as well as my Latin library. Those are very long and complicated scripts and Nils' "function" feature alone makes them at least manageable. Thank you Nils!

In Electronic Musician, Len Sasso indeed gives a major plug to Nils in paragraph 5 or 6 of his excellent article, which coincidentally, I was reading just last night! He also gives a nice plug for this forum, which I have to concur is a fabulous resource. I have gotten lots of great help here, so thanks to all here who are always so helpful! o-[][]-o


----------



## kotori (Feb 5, 2008)

Hey Tod and Mike, thanks! :D 
I too was happy to find the link to this forum in the article. I hope it will help more people find this nice place.

The Black Bass review in its entirety and a short audio clip (sadly no example of slides though - which is one of the strong points of this library) made by the reviewer has now been made avilable online on the EM web page in case anyone is interested.


----------



## frankvg (Feb 6, 2008)

kotori @ Mon Feb 04 said:


> KScript Editor gets its first music magazine coverage in the Electronic Musician article "Master Class: Scripting in Kontakt 3" (available online).
> http://www.scarbee.com/products/black_bass/ (Scarbee Black Bass), which I wrote the script for, is reviewed in the same edition of EM.


Congrats, dear Nils! Well earned praise! :D


----------



## kotori (Feb 7, 2008)

Frank, hi my friend. Thanks.  
In case there are any OSX users here you all have Frank to thank for the availability of the editor for that platform. Never could have done it myself.



Dynamitec @ Thu Feb 07 said:


> Hi Nils! Congratulations for the review!
> 
> I found a small bug in the extended syntax checking:
> 
> ...



Hi Benjamin, are you sure that this line is the problem? It compiles fine here. Could it be the previous line?


----------



## Big Bob (Mar 7, 2008)

Hi Nils,

Evidentally your code optimizer doesn't handle the unary .not. operator properly?
For example:

*on init*
``*declare* *const* Bit6 := 0x40
``*declare* *const* NBit6 := .*not*. 0x40
``*declare* X
``*declare* Y
``*declare* Z
``Y := 0xFF
``X := Y .*and*. Bit6
``Z := Y .*and*. NBit6
``message(NBit6)
*end on*

The above works properly with Code Optimization off but not with it on.

God Bless,

Bob


----------



## kotori (Mar 7, 2008)

Hi Bob!

Good catch! It's fixed now. Please download the *new version*.

The problem was that the .not. operator internally in the compiler promoted some integers to long integers which caused expressions using .not. to not be simplified. This meant that constant declarations were removed without the compiler being able to substitute the value of the constant properly at the places where the constant was used, which in turn caused Kontakt to complain about missing variables.

I'm sorry I haven't had more time to work on new features lately. I've been thinking about rewriting the compiler on which the error checking and optimization is based to use a simpler and more coherent AST node structure. That could make it easier to cache parsed code fragments in such a way that only changed parts of the code need to be reparsed when the user hits F5. It's a pretty big task though, so I'm not yet sure if I'll find time to do it. We'll see.

Btw. Now there are a couple of more http://www.samplemodeling.com/en/demos.php (audio demos) of http://www.samplemodeling.com/en/products.php (The Trumpet) that I've been working on lately (the scripts that is, not the demo ).

Cheers,
Nils


----------



## Thonex (Mar 7, 2008)

kotori @ Fri Mar 07 said:


> Btw. Now there are a couple of more http://www.samplemodeling.com/en/demos.php (audio demos) of http://www.samplemodeling.com/en/products.php (The Trumpet) that I've been working on lately (the scripts that is, not the demo ).
> 
> Cheers,
> Nils



I saw that video a quite a while ago... so you must have been a busy bee for quite a while :wink: 

I think you and Tommasini are a lethal combination :lol: 

This is all very exciting stuff!!!!

Cheers,

T

P.S. as always... thanks so much for your editor updates and all you are contributing to this site!!!


----------



## Big Bob (Mar 9, 2008)

Hi Nils,

I just found another problem with the KScript Editor. This may have been with us since you added the hexadecimal input option. When we use the 'import as' directive, it looks like the machinery sees hex numbers as though they were variable names. For example:

_{------------------------------ Main Test Script ----------------------------------}_
*import* "Library.txt" *as* km

*on init*
``*declare* X
``*declare* alx
``
``X := 17
``km.CheckItOut(X,alx)
``message(alx)
*end on*

_{------------------------------------- Library Script Form 1 ------------------------}_
*function* CheckItOut(X,alx)
``*if* X > 214875
````alx := 255
``*else*
````alx := 0
``*end if*
*end function*

_{-------------------- Compilation with Form 1 Library Script-----------------}_
*on init*
*declare* $X
*declare* $alx
$X := 17
*if* ($X>214875)
$alx := 255
*else*
$alx := 0
*end if*
message($alx)
*end on*
_{------------------------------- Library Script Form 2 --------------------------------}_
*function* CheckItOut(X,alx)
``*if* X > 214875
````alx := 0xFF
``*else*
````alx := 0
``*end if*
*end function*
_{------------------------ The Hex Form will not compile -------------------------------}_



When Form 2 of the Library module is used, the editor stops with an error dialog saying: ' km__0xFF not declared'

The reason I say that this may be an old problem is that I haven't had any occasion before now to use the 'import as' directive for a long time. The editor flags this error with or without extended syntax checking enabled but, if I drop the 'import as' and just use 'import' it compiles fine or if I move the Library function into the main script everything is cool.

Knowing how busy you are, I hope this is easy to fix.

Have a beautiful day my Friend,

God Bless,

Bob


----------



## kotori (Mar 9, 2008)

Hi Bob,

Thanks for the bug report. Fortunately this was very easy to fix - I just made the hex to decimal translation the absolutely first compilation phase. It surprises me that nobody has reported this earlier (myself included). Anyway, now it works. Everyone who uses both the "import as" and hexadecimal numbers is recommended to *download the upgrade*.

I wish you a beautiful day too Bob!

_Version 1.25.6 (released 2008-03-10)
Fixed bug: hex numbers in modules that were imported using "import 'X.txt' as X" were incorrectly prefixed by X__ as if they had been variables._

Cheers,
Nils


----------



## Big Bob (Mar 10, 2008)

Hi Nils,

That did the job o-[][]-o . Thanks a million for the fast fix :D .

God Bless,

Bob


----------



## Thonex (Mar 11, 2008)

kotori @ Tue Mar 11 said:


> Now the latest KScript Editor version (1.25.6) is available as a universal binary for Mac OSX. :arrow: Download.



Thanks Nils!!!! And thanks Frank van Gompel!!!! :D 

As always... we are indebted to you. o-[][]-o 

Cheers,

T


----------



## kotori (Mar 11, 2008)

Thonex @ Wed Mar 12 said:


> Thanks Nils!!!! And thanks Frank van Gompel!!!! :D
> As always... we are indebted to you. o-[][]-o
> 
> Cheers,
> T



Actually I packaged it myself this time. I needed a laptop for work, so I got myself a new MacBook. I started programming on an Apple II machine and switched to PC at the time of the Power Macintoshes, so it's good to be back in the game, although it feels like a thing or two have changed during this time. :D 

Frank: I hope you'll still drop by to say hello on Skype some time. It's always so nice to talk to you. Thanks so much for all the help.

Cheers,
Nils


----------



## Thonex (Mar 11, 2008)

kotori @ Tue Mar 11 said:


> Thonex @ Wed Mar 12 said:
> 
> 
> > Thanks Nils!!!! And thanks Frank van Gompel!!!! :D
> ...



Well.... then double "Thank you" to you Nils... and still "thank you" to Frank van Gompel for all his hard work in the past!! 

BTW... congrats on crossing over to the MacBook. THey are so much fun.. aren't they?

Cheers my friend.

T


----------

